It has now been a month since BitMover withdrew BitKeeper from use by people who didn’t have paid licenses. Ian Bicking has written a blog entry on the evils of distributed revision control, so this seems a good time to talk about the legacy of BitKeeper.
Early during the use of BK for Linux kernel development, Greg Hudson wrote a polemic entitled Why BitKeeper Isn’t Right For Free Software. He had two main points:
- BitKeeper had an inappropriate license for free software developers.
- BitKeeper’s development model is wrong, since it supports hierarchical development.
BK was developed before any of the free alternatives, so it’s not hard to say that it provided the inspiration for all of them, even if none has followed its implementation model.
In addition, BitKeeper implemented many features well from a user’s perspective. BK convinced many people of the value of distributed SCM tools, and made it easy to see what a good set of features would be.
Larry McVoy’s interactions on mailing lists also had an effect on the free SCM tools. He relentlessly drove home the point that building a professional SCM that handles all corner cases and is completely reliable is a difficult task. This may have dissuaded some people from paying attention to the problem, but his manner of delivering the message also worked against him; at least a few people started working on free distributed SCMs in response to his efforts to dissuade them.
Since BK was withdrawn, there has been a definite spike in development activity on the part of several free SCM tools. Mercurial and git/cogito didn’t even exist until BitMover announced the withdrawal of BitKeeper, and the Monotone developers had to scramble to address the needs of a suddenly larger audience.
So the legacy of BK is decidedly mixed. While it probably caused widespread interest in distributed SCM in the first place, its restricted availability temporarily slowed the development of free alternatives, but finally buoyed the lot of them.