couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Inspiring comment about CouchDB on Hacker News
Date Tue, 09 Oct 2012 09:50:05 GMT
My old CouchDB retrospective ended up on the front page of HN, again...

I thought I would quote this, by Riyad Kalla, because I find it very

FWIW, this was written in July of 2010 (2+ years ago) -- CouchDB is in a
> very different place now than it was then.

Reading the mailing lists of CouchDB, Redis, MongoDB and Cassandra are
> _very_ different experiences.

CouchDB's list reads like 10 or so of the same people discussing very high
> level efforts like documentation and Windows builds, developing the DB at a
> glacial pace -- including merging in changes from all the spin-off CouchDB
> efforts that all seem to be defunct now (e.g. BigCouch and the sharding
> code).

Tangentially, MongoDB/Redis/Cassandra mailing lists are NOTHING but "How do
> I..." questions, deployment questions, feature development questions, patch
> submissions, etc. (more-so Cassandra and MongoDB lists).

CouchDB to me has found this life that feels very academic to me which I
> think is a good thing in the long-term for the project. The principles are
> in no rush to get to features and have the motto "slow and consistent wins
> the race". I would be surprised at all if a few years go by and then
> CouchDB gets rediscovered suddenly as the panacea to everything (something
> akin to how Jetty suddenly became hot business in the Java server world
> after being mostly ignored for 10 years)

With the money behind Cassandra and Mongo it is probably not much of a
> surprise that there are much more new deployments going on and Redis has
> found a place somewhere between the two with what I would say is a
> Linus-like steward at the helm (props to Salvatorefor being everything that
> is right with open-source)

I wouldn't build a commercial product on CouchDB tomorrow, but I am eagerly
> waiting to see where it goes in the next year. It is wonderfully designed,
> but I'd like to see some of the nagging "table stakes" issues like
> replication failures fixed before caring about Feature XYZ and release 2.0

Here's to the future! We have a lot of work to do.



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