couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harald Kisch <>
Subject Re: CouchDB Song
Date Sat, 19 Sep 2015 22:05:08 GMT
Hi Andy,

thank you for asking. The intention of my last email to the marketing
mailing list is simply the definition of CouchDB itself. I think since the
time, the video was published, CouchDB got a lot of attention. And from
this attention CouchDB simply profits until today. In my opinion, it was
all about Couchapps and it is all about Couchapps. I want the community to
remember J. Chris Anderson. He was the mayor Couchapps contributor. And I
also know about discussions between Jan and JChris about Mustache
Templates, Eventlies which are claimed that nobody understands how they
work and so on. But I also want to remember Mikael Rogers who build Futon
which replacement is called Fauxton. Where are these guys? Why did they
leave CouchDB?

It does'nt matter if someone thinks CouchDB and Couchapps are not one
thing. There are many business cases realized with couchapps. And they
won't be realized if there were many bugs or lack of functionality. It
simply works, yes it works for nearly a decade and nobody complains about

So there is a need for that because it is used by many users. If it will be
removed we will loose these users. Do we want to loose users?
For me it is very simple, if Couchapps will be removed in any version, I
will not use this version. I would go further with CouchDB 1.6.1, because
it works. I do not care about something that could be 10000% better in
future because I don't need it to be 10000% better right now. I currently
need it as it is right now! By the way, is Fauxton 10000% better than Futon?

For me Couchapps is a set of functionality, which really differs from other
databases. It is a unique feature many database vendors want to have and
CouchDB has it. For me it is very bad not to pronounce Couchapps to more
users althought it is not maintained right now. Sometimes I think there are
people in or outside the community who do not like Couchapps to survive.
Sometimes it seems to me that there are database vendors included in that
kind of destructive process.

At the moment I think I alone do not have the time, power and money to
fight against such destructive forces. I also still did not hear a strong
fact which is really a reason to remove Couchapps. So why do these forces
want to destroy something which is in use and loved by many people? People
who love that way to use CouchDB so much that they have decided to use it
for their daily business? Can that be, that there is a strong fact, which
is the reason to destroy the business of CouchDB users? If this is the
case, I do not want to work with them. So I am asking myself again: why
have JChris (Couchapps), Mikael Rogers (Futon) or Damien Katz (CouchDB
itself) been splitted apart from their real loved babies? If one of them or
Damien would come back to the community I think we would be powerful enough
to define Couchapps as a groupware feature, which can show the strange
business world how that gets done what they ever wanted before ("Everybody
talks about it - but nobody gets it done" - Damien Katz), with a simple
database architecture, a JavaScript Webserver and replication on top in the
core of CouchDB which is claimed as productive since version 0.11 and still
works today until now without a big issue/improvement.

-- Harald

On Sat, Sep 19, 2015 at 12:16 AM, Andy Wenk <> wrote:

> Harald,
> what is the message and intention of your E-Mail to this list?
> Thanks for a hint.
> Cheers
> Andy
> On 18 September 2015 at 10:07, Johs Ensby <> wrote:
> > Had forgotten this!
> > Absolutely lovely :D
> > johs
> >
> > > On 18. sep. 2015, at 09.03, Harald Kisch <>
> wrote:
> > >
> > > Respectfully, there have been very cool people on the project:
> > > <>
> > >
> > > Thanky you Giovanni for remembering.
> > >
> > > -- harald
> >
> >
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message