“What’s the future of CouchDB? It’s Couchbase.” —Damien Katz

“The future of CouchDB is CouchDB.” —Noah Slater

First of all, don’t panic. The Apache CouchDB project is thriving. There are plenty of core contributors who are dedicated to the project. If you’re using CouchDB, you’re fine. If you’re considering using CouchDB, you’ll be fine. CouchDB has a bright future ahead of it. Couchbase has repeatedly said that they’re not the CouchDB company, so this shouldn’t be a surprise to anyone.

My interpretation of this announcement is that CouchDB is forking. Going forward, you’ll have two choices, either Apache CouchDB or Couchbase Server. The road map for Apache CouchDB will continue to be determined by community consensus. The road map for Couchbase Server will be determined by Couchbase, the company.

CouchDB has two futures: CouchDB and Couchbase Server. Traditionally, forking a project in this manner has been considered a Bad Thing. From The Jargon File entry for forked:

An open-source software project is said to have forked or be forked when the project group fissions into two or more parts pursuing separate lines of development (or, less commonly, when a third party unconnected to the project group begins its own line of development). Forking is considered a Bad Thing — not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs/XEmacs split, the fissionings of the 386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore.

In my humble opinion, forking should no longer be considered a Bad Thing. Distributed revision control systems, such as Git, have made it much easier to merge changes back-and-forth between forked projects. If an individual or organization wants to take a project in a different direction, great! It sounds like Couchbase Server will be designed to meet a set of needs that are not being met by CouchDB. If so, a fork is perfectly appropriate as now both sets of needs can be met.

I’d heard about distributed revision control tools before last year’s ZendCon. I thought it was a neat idea but didn’t really get what the advantage was over a centralized tool like Subversion. The folks from GitHub had a vendor booth so I thought I’d ask them why Git was better than Subversion. I forget exactly what they said (probably something about how branching and merging is so much easier in Git) but whatever it was it definitely made me consider trying Git.

The GitHub folks were wearing t-shirts that said, “fork you” and explained that on GitHub they encourage projects to fork. Typically in free/open source projects forking is considered a bad thing. It usually signifies some breakdown in the community when one project forks from another. However, with Git and GitHub it’s really easy to “clone” a project’s repository, hack away at some changes, and then “push” (or have “pulled”) your changes back to the repository you originally cloned. Git makes branching, cloning, pushing/pulling, and merging very easy and GitHub provides a place to host your repositories making this interaction with other people’s repositories very simple.

GitHub’s tagline is “social coding.” With distributed revision control each developer gets his or her own project repository. If your repository is public then anyone can come along and make a clone of it giving themselves their own copy of your project to work on. Assuming their clone is also public, you can track their changes and decide if you want to pull in work they’ve done. If you find yourself collaborating a lot with a particular person that you trust, you can give them the ability to push to your repository. With Git this actually scales to projects with lots of contributors. This may seem chaotic, pushing and pulling changes to and from decentralized repositories, but it’s actually a great way to encourage ad hoc collaboration.

If you want to learn more about Git you can read the Git Community Book, Pragmatic Version Control Using Git or the Pro Git Book. One last thing: if you’re currently a Subversion user then forget everything you know about how Subversion works. While a lot of the commands may be similar to Subversion and there’s a way to integrate with Subversion (git-svn), Git is fundamentally very different than Subversion. If you try and equate the two you’ll most likely end up confused!