<i>I love CouchDB, but I love the CouchDB community even more. I think we made the important decision to cultivate community right from the start. One of the key components in getting that right turns out to be the concept of a community gatekeeper, or steward. Someone to guide things back in the right direction when they get off-track. Someone to set an example. On the very few occasions someone has threatened the atmosphere on the lists and in the IRC channel, it has been nice to see people defend it with passion and with humility. When those people see how things work here, and how committed we are to keeping the grass green and not letting the project become mired by useless arguments and petty aggression, they either adjust or they leave.</i><p>Perhaps rather than producing wisdom, crowds encourage demagogy, regurgitation of home truths, and petty agression/pedantry unless they are encouraged to channel their energy in other directions. The contention is that they are never self-regulating (even if you give them the tools to do so), but require intervention and moderation to remain cohesive, productive communities.<p>Some interesting lessons in here for communities like HN/SO/Reddit/SD etc. which rely on crowd moderation and technical measures to try to guide a community. When dealing with a large enough community, that can break down as enough new members arrive to subsume the older culture completely in a small amount of time, and any technical measure you think of can be subverted by those willing to put in the time to do so. I think reddit's approach here of splitting the community up into smaller niche groups is really interesting, but IMO they arrived at it too late to save their community overall.
FWIW, this was written in July of 2010 (2+ years ago) -- CouchDB is in a very different place now than it was then.<p>Reading the mailing lists of CouchDB, Redis, MongoDB and Cassandra are _very_ different experiences.<p>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).<p>Tangentially, MongoDB/Redis/Cassandra mailing lists are <i>NOTHING</i> but "How do I..." questions, deployment questions, feature development questions, patch submissions, etc. (more-so Cassandra and MongoDB lists).<p>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)<p>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)<p>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