Back in early 1999, your editor got a call from Larry McVoy. He was
worried that Linus Torvalds was on the verge of burning out as the kernel
project grew. The problems in those days were quite evident; Linus, it was
being said, did not scale. But, according to Larry,
a complete burnout was not inevitable. If Linus could be given the right
tools, many of his problems (and the frustrations of other kernel
developers) could be solved, and the system would run smoothly again. The
right tool, according to Larry, was a thing called BitKeeper; if some sort
of agreement could be made on licensing, Larry (along with his company, BitMover)
was willing to make
BitKeeper available for kernel development. In fact, Larry wanted to see
BitKeeper used for all
free software development; see this article
March 25, 1999 LWN Weekly Edition for a view of how things looked at
Three years later, the situation did not look any better. The 2.4 kernel
had taken almost a full year to stabilize after 2.4.0 came out. 2.5 had
begun, but the process was looking rocky at best. Patches were being
dropped, developers were complaining, and Linus was getting tired. After
convincing himself that the tool had reached a point where it could do what
he needed, Linus decided to give BitKeeper a try. There was no looking
Some of the development process issues could have been addressed by
adopting any source code management system. But BitKeeper brought
more than that; it established a model where there is no central
repository. Instead, each developer could maintain one or more fully
independent trees. When the time came, patches of interest could be
"pulled" from one tree to another while retaining the full revision
history. Rather than send patches in countless email messages - often
multiple times - developers could simply request a pull from their
BitKeeper trees. Meanwhile, the current development trees could be pulled
automatically into the -mm kernel, allowing patches to be tested by a wider
audience prior to merging into the mainline. BitKeeper enabled a work
method and patch flow which naturally supported the kernel's development
Once the developers and the tools got up to speed, kernel development took
off like never before. The rate at which patches were merged skyrocketed,
the developers were happy, and the whole system ran smoothly. The public
version of Linus's BitKeeper repository (and the repositories of many other
developers) made the development process more transparent than ever.
Anybody could look to see the up-to-the-minute state of the kernel and how
it got there. Larry was right: with the right tools, Linus really
The only problem was that BitKeeper is proprietary software. Instead, it
came (in binary-only form) with a license
which allowed free use, but which imposed some significant restrictions.
The free version of BitKeeper could only be used with open source projects;
users could be required to make their repositories available on demand.
The free version posted all changelog information on openlogging.org, and disabling the
logging was not allowed. Users were required to upgrade to new versions,
which could come with different licenses. And users were not only
prohibited from reverse engineering the software, but they were prohibited
from working on any sort of source code management system at all.
Larry wanted to have his cake and eat it too. He truly wanted to support
the development of free software - as long as that software didn't threaten
his own particular business niche. Supporting the kernel development cost
real money - and supporting the business which created BitKeeper cost even
more. Whenever BitMover felt that its business model was threatened, it
responded; often the BitKeeper licensing terms were changed in response to
perceived threats - to the point that the BitKeeper license became known in
some circles as the "don't piss off Larry license."
Well, somebody pissed off Larry one time too many. The final straw, it
seems, was a certain high-profile developer who refused to stop reverse
engineering work while simultaneously doing some work for OSDL. BitMover
is now withdrawing support for the free version of BitKeeper, and Linus has
ceased to use it. BitKeeper is no longer the source code management system
for the kernel. Proprietary software can be good stuff, but it always
carries this threat: you never really know if it will be there for you
tomorrow or not. BitMover has decided that it can no longer afford to make
BitKeeper available for the free software community.
BitMover has issued a
press release on this change:
BitMover looks forward to implementing our extensive roadmap and
delivering advanced SCM technology to a wider market. As part of
this focus, BitMover has replaced the free version of BitKeeper
with the recently released open source BitKeeper client. Those
developers who desire additional functionality may choose to
migrate to the more powerful commercial version of BitKeeper.
The open source client, incidentally, enables the extraction of the current
version from a repository, but does little else.
The PR also states that "Our relationship with the Open Source
community has been evolving and many of the key developers have already
migrated to the commercial version of BitKeeper." Linus has,
however, made it clear that he is not one
of those "key developers":
Right now, the only real thing that has happened is that I've
decided to not use BK mainly because I need to figure out the
alternatives, and rather than continuing "things as normal", I
decided to bite the bullet and just see what life without BK looks
like. So far it's a gray and bleak world ;)
What happens next is far from clear. The kernel developers will not go
back to the previous way of doing things - no source code management system
at all. Even the developers who can continue to use BitKeeper are unlikely
to continue doing so if Linus is unable to pull their patches.
So a replacement will have to be found. It is not clear that any
of the free alternatives is up to the task of handling a project as large
as the kernel. One of them may end up growing up in a hurry in order to
take the load. Thanks partly to the example and motivation provided by
BitKeeper, the free alternatives do look far more viable than they did
three years ago, when Linus first started using BitKeeper.
Larry has made it clear that
he blames the free software community for this turn of events:
I'm far from blameless but the majority of this problem is an open
source community problem. They simply don't want to play with
non-open source. At least some of them don't and they ruin it for
the rest of us. The problem here is one of policing. By
ignoring/tolerating the bad apples the community punishes itself.
If BitKeeper users were violating the license under which they received the
software, they have indeed done something wrong. Every time we release
code under a free license, we do so with the expectation that the terms of
that license will be respected. To treat somebody else's license with less
respect is hypocritical; if the license terms are not acceptable, do not
use the software. That said, one could note a couple of other things.
The notion that developers of proprietary software do not
engage in reverse engineering - that it's "an open source community
problem" - is debatable at best. And how, exactly, might the community be
expected to do this sort of "policing"?
The ironic result of all this is likely to be the accelerated development
of exactly what Larry claims to most fear: a free source code management
system that, while it lacks much of what makes BitKeeper great, is "good
enough" for a large portion of the user base. As the BitKeeper developers
found out, hosting the kernel project is an effective way to shake out
scalability and usability problems. Whichever system ends up hosting the
kernel can be expected to go through a period of rapid improvement.
BitMover did, in fact, get a few benefits from hosting the
kernel, even if, in the company's view, the benefits do not come close to
equaling the associated costs.
BitKeeper is a more scalable and robust system as
a result of the use it saw in that role. There were also substantial PR
benefits; see, for example, this 2004 press
release with nice quotes from David Miller and Linus Torvalds. There
can be no doubt that working with the kernel has brought a great deal of
visibility to BitKeeper, and that must have resulted in some new business.
The cynical among us might conclude (and some already have concluded) that
BitMover simply decided that it had obtained most of the benefits it was
going to get from hosting the kernel and decided to move on.
Whether or not that is the case, it cannot be doubted that Linux, too, has
benefited strongly from its association with BitKeeper. We would not have
a 2.6 kernel with anything near its level of capability, scalability, and
robustness without the role played by BitKeeper. One could easily argue
that the free source code management systems would not be as good as they
are had BitKeeper not come along. BitKeeper was a gift to the community
that was well worth accepting; now that it is gone, the best thing to do is
to say "thanks" (with sincerity!) and figure out what comes next.
to post comments)