BitKeeper and Linux: The end of the road?

BitKeeper, the proprietary source management tool used by Linus Torvalds and other Linux kernel hackers to apply patches to their versions of the kernel, is once again at the center of controversy. This time it looks as if the relationship between BitKeeper and the poster-child project for free software is going to come to an end as the result of irreconcilable differences. NewsForge has spoken with the three primary figures involved in the dispute — Larry McVoy, Linus Torvalds, and Andrew “Tridge” Tridgell — to learn what happened and whether or not it could have been avoided.

McVoy explains

We asked Larry McVoy to tell us what happened to cause him to end the relationship by giving Torvalds and the Linux kernel developers using BitKeeper three months to move to another tool for their source code management. He explained:

Back on February 23 I learned from Linus that Tridge was reverse engineering BK so that he could pull stuff out of BK trees without agreeing to the BK license. As you might expect, we were less than thrilled and began having talks with Linus, Tridge, as well as Stuart Cohen, the CEO of OSDL. These talks didn’t go anywhere. Tridge believes strongly enough in free software that he thinks anyone using non-free software is living in sin.

Linus worked very hard to get Tridge to stop. He and I spent a significant amount of time on this issue and Linus understands my position very well He summarized it nicely:

Larry is perfectly fine with somebody writing a free replacement. He’s
told me so, and I believe him, because I actually do believe that
he has a strong moral back-bone.

What Larry is _not_ fine with, is somebody writing a free replacement
by just reverse-engineering what _he_ did.

Larry has a very clear moral standpoint: “You can compete with me, but
you can’t do so by riding on my coat-tails. Solve the problems on your
own, and compete _honestly_. Don’t compete by looking at my solution.”

And that is what the BK license boils down to. It says: “Get off my
coat-tails, you free-loader”. And I can’t really argue against that.

This position seemed to be lost on Tridge.

Concurrently we were working with OSDL’s management. In this area
I pulled in calmer heads than mine and our VP of sales got involved.
He negotiates all of our enterprise level agreements, (his strength is
finding common ground) so you can imagine he’s a pretty reasonable guy.
He was unsuccessful in getting anywhere with OSDL’s CEO. Stuart’s
position was that this was not their problem and this is the sort of
activity you expect in the Open Source world. We did get a verbal
promise from OSDL that Tridge had discontinued his work and would not
begin again as long as we were trying to work things out. We believed
we had an uneasy truce, but it ends up Tridge was still working.

We ended up in a no win situation. OSDL didn’t appear to care and
we couldn’t trust what we were being told. With that we were fairly
confident that Tridge was going to release his code. That was a problem
for us for two reasons:

a) Corruption. BK is a complicated system, there are >10,000 replicas
of the BK database holding Linux floating around. If a problem starts
moving through those there is no way to fix them all by hand. This
happened once before, a user tweaked the ChangeSet file, and it
costs $35,000 plus a custom release to fix it.

If Tridge’s tool is out there we are now supporting our code and his
code. We couldn’t do that.

b) IP loss. If we sat back and did nothing about Tridge then we are
implicitly condoning reverse engineering.

Internally, we were looking at ways to best handle this. One option was
to have two versions of BK, one that we gave away and another that was
commercial only. This had been our course for some time and it wasn’t
working out. The difficulty with that solution is we couldn’t just stop
all work on the free version because of future compatibility issues.
Trying to maintain compatibility between a free product and commercial
version was grinding our development to a halt. Everyone was losing.
In order for this to work we had to continuing throwing resources at
the problem. We’re already up to about $500K/year for the free version
and continuing to ratchet that up wouldn’t be prudent.

At that point we started looking at what it would be like to discontinue
the free BK. Linus strongly encouraged us to do this once he came to
the conclusion that the costs of the free version to BitMover outweighed
the benefits to BitMover.

OSDL’s management was kept informed of what we were thinking and again
they seemed rather apathetic about it. Their position was that it was
BitMover’s problem and we needed to figure out how to fix it. That is
until we set the wheels in motion to discontinue the free product.
They did make motions very recently that we should work together on this,
but it was too little too late.

We finalized our discussions with Linus last weekend and he began the
process of migrating off of BK. Linus is a very ethical guy, his feeling
was that we were getting a bad deal and he didn’t want to be part of that.
So off he went. We spent the next couple of days scrambling to figure
out how we were going to handle this, announcements, migrations, programs
moving forward, etc. We’re still working on the details moving forward
with some of these issues, but our hope is to make this as smooth as
could be expected for this sort of transition.

Torvalds’ take on the situation

After reading McVoy’s response (he CC’d Torvalds on the email he sent to us so that he would not misquote or take out of context anything he quoted from their correspondence), we asked Torvalds three questions.

NewsForge: What will you use to replace BitKeeper?

Torvalds: I don’t even know yet. I’m playing around with my own scripts and tools
right now, and talking to various open-source SCM (Source Code Management) people. In fact, I’m
trying to get as many people as are interested in the problem to just
explore the options.

NewsForge: How will this impact your workload short or long term?

Torvalds: Short-term we’ll merge patches. Right now the -mm tree should work like
usual, so people can go on developing. On the other hand, especially
people that used BK will just slow down, take a breather, and look around
at the alternatives.

And some people will just continue to use BK. It didn’t go away, and it’s
still the best SCM out there, it just got harder to merge with me (and
some of the people I work with). So you export BK changes by patches
instead, but some people largely worked like that _anyway_ before (ie they
used BK for its merge capabilities).

So we’ll definitely have a slowdown in the short run, but it’s not likely
to be a huge deal. The biggest worry is developer frustration about the
uncertainty, so I’m certainly trying to get to a decision, but on the
other hand I don’t want to hurry it _too_ much either.

(Ironically, many users and distributions are likely to actually not mind
slightly slower development for a while. One of the most common worries
for users is just the fact that 2.6.x has continued to be developed at a
very high rate thanks to just how smoothly it’s been working, so I bet
some people are both upset and gratified by this all 😉

In the long run, we’ll just have to see. I think in the _medium_ run the
problem is going to be just having to live with less capable tools, and
having to possibly teach old developers (me included) new tricks.

And I don’t mean the various syntactic differences between different
SCM’s, I mean new ways of working and adapting to new constraints (and
likely new freedoms too – BK had its own set of constraints simply due to
the model of development that _it_ imposed – every SCM tool to some degree
has a “world view”, and it takes time to get comfortable with that world
view…

NewsForge: Was this split inevitable, or could it have been avoided?

Torvalds: I think everybody saw the split as inevitable _eventually_. I don’t think
anybody believes that the open-source SCM’s wouldn’t grow up, and when
they would, there would have been obvious reasons to switch over
eventually.

But I think it could have been a lot less painful if it happened a year or
two down the road, and that’s really my only real regret. That said, we
did get three very productive years out of it, and we not only learnt how
SCM’s can work, we also taught a lot of people what to expect of a _good_
SCM, so anybody who claims that it was a waste of time to go with BK
obviously doesn’t have his head screwed on right. BK did good.

Tridge offers his side

There is no doubt Tridge is being cast as the villain in this piece. Here’s what he
had to tell us when we asked him for his side of the tale:

I expect that in the future I will be able to give a more detailed
response, but for now I can only tell you the following:

– In late February I wrote a tool that is interoperable with
BitKeeper. The aim was to provide export to other source code
management tools and provide a useful tool to the community.

– I did not use BitKeeper at all in writing this tool and thus was
never subject to the BitKeeper license. I developed the tool in a
completely ethical and legal manner.

At the end

In spite of the end of the relationship, McVoy and Torvalds seem to have lost no respect for each other’s integrity or professionalism. Torvalds still admires BitKeeper, and still feels it to be the best tool for the job. Whether this outcome was inevitable or not, it’s a little bit sad to see this marriage of proprietary and free software come to an unhappy end. Not to mention, a little unsettling due to the uncertain handling of patches in the future.