- About Us
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, and 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.Torvalds' take on the situation
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.
After reading McVoy's response (he cc:ed 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 source code management (SCM) 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 (i.e. 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 SCMs, 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 SCMs 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 my only real regret. That said, we did get three very productive years out of it, and we not only learnt how SCMs 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.