couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt Milam <kurt.mi...@xioup.com>
Subject Re: Couchbase trademark issues
Date Thu, 15 Mar 2012 03:09:18 GMT
I'll pipe in as a relatively new CouchDB user, and someone who's spent a
reasonable amount of time in both #couchdb and #couchbase over the past few
weeks.

Couchbase/CouchDB is confusing for newcomers. It was (and frankly, still
is) confusing for me, and I have seen more than one person in #couchdb
expressing confusion and even worried about whether the CouchDB ecosystem
is stable enough to consider using Couch(x) for the data layer in serious
software projects.

I've been aware of CouchDB for at least a year now - the brand is
well-known in certain circles. I've been aware of NoSQL and MongoDB for
approximately just as long, but I'd never spent the time really looking
closely at NoSQL solutions until a couple of months ago.

At that time, I began seriously researching various NoSQL solutions for
upcoming and ongoing projects. Frankly, the CouchDB ecosystem is the most
confusing of all of the various NoSQL solutions I've researched - riak,
mongodb. redis, among others. The documentation is spread out, disjointed
and sometimes out of date. A number of articles and blog posts link to
couch.io addresses that no longer exist (note to couchbase listeners: your
move from couch.io to couchbase.com was, in my opinion, handled extremely
poorly, with multitudes of dead links and a seriously broken blog that was
obviously not migrated to the new system/domain with much care).

As I began to research NoSQL solutions more closely, I can say that CouchDB
was the brand with the most recognition for me, and was therefore one of
the first solutions that I researched. I was leaning toward using CouchDB
for a number of reasons - brand strength and a recommendation from another
developer whose opinion I respect. I can tell you that at least in my
experience, the decision to go with CouchDB over one of the other solutions
took much longer than it would have, if CouchBase hadn't confused the
issue, and if CouchDB's documentation had been in better order.

In the end, I went with CouchDB primarily for the master-master
replication, the various solutions for installing CouchDB on mobile
devices, and CouchApps. To be concise, CouchDB was the correct solution for
the projects we're currently working on, but it took a good deal of extra
research (due to the confusion caused by CouchBase and the scattered state
of CouchDB docs).

In case you hadn't noticed, I disagree 100% with Bob Dionne's and Jason
Smith's estimation, and I'd say that my assessment of the situation, as a
new convert to CouchDB, is probably much more relevant than the estimation
of two Couch(x) old hands.

Couchbase is confusing for those just starting to research CouchDB, full
stop.

Best Regards,

Kurt Milam


On Wed, Mar 14, 2012 at 10:49 AM, Nick North <north.n@gmail.com> wrote:

> As a fairly new CouchDb user, I have been confused about the relationship
> between CouchDb and Couchbase. For some while I was unsure whether the
> Couchbase site might have a more recent version of CouchDb than the CouchDb
> site did, especially as it talked about a forthcoming version 2, while
> CouchDb talked about version 1.1, and it contains API docs that are
> perfectly usable as CouchDb documentation.
>
> Jan Lehnardt's Looking for Apache CouchDb
> <http://www.couchbase.com/couchdb>page has done a lot to dispel that
> confusion though. I don't think there is
> any need for anyone to change product names, but the sort of information on
> that page helps a lot to make sure people go to the right place.
>
> Nick
>
> On 14 March 2012 09:35, Jason Smith <jhs@apache.org> wrote:
>
> > On Wed, Mar 14, 2012 at 9:29 AM, Bob Dionne
> > <dionne@dionne-associates.com> wrote:
> > > Jan,
> > >
> > > Here's my two cents as a couchdb committer.
> > >
> > > I don't think you (Couchbase) need to do anything. My observation is
> > that there has been more representation about end-user confusion than
> there
> > has been actual end-user confusion.
> >
> > Completely agree.
> >
>

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