True, and as long as he was still using it that was a valid argument of his. But it took him and a few others only a few weeks to code a replacement that everyone seems to be even happier with functionality-wise. So while it's clear that BK was a better fit than any of the other existing SCMs, I think I have to agree with the people on lkml who were saying it would have been better to put energies (or incentive) into developing a free alternative in the first place. Just think of all the developer time wasted on flame-wars ;-).

Aside: without knowing either of them personally, I think that particular quote was given to save Larry McVoy (who's a friend of Linus AFAIK) some face.

And the fact that Linus was happy with Bitkeeper doesn't change anything about the danger of keeping one's important data in a proprietary format which is only accessible through a proprietary product. Sure, one should always use the tool that best fits the job, but when part of the job description is "I want to be able to access my data any time in the future, regardless of what happens with a certain vendor/product", programs like Bitkeepet fail the spec.


Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

At some point the SCM vendor (decided|was forced) to declare he would no longer provide the system for free.

So, part of the story is "even if you're an open-source zealot, follow the rules!"

On the other hand, from lemons came lemonade. I'm strongly considering using Git on projects because of its nice distributed creativity model. (No, I can't seem to get SVK to work on my machines, and the rest of the stuff looks even further down the scale. Git compiles and installs trivially, except for the documentation stuff.)

Actually, that might not be entirely accurate, as it was Tridge, Samba author, who reverse engineered the data format of BitKeeper for interoperability.

He never agreed to the BitKeeper license in the first place.

Calling him a member of Linus' team is a bit of a strech, because by that measure thousands are members of that team.

I certainly don't believe that everything in the world should be open source, but imo most formats are an exception.

This wasn't a member of Linus's "team", but Andrew Trigell, the creator of Samba and rsync (who is also currently employed by OSDL, as is Linus, but AFAIK they don't actually work together).

That's why I put the "|" between "decided" and "was forced". IMO it is debatable how wrong it was of Tridge to try and access the BK data without going through the BK format. After all, the approach he used was exactly the same he used for creating Samba, and not too many people call him an unreasonable open-source zealot for that. There was no disassembly or illegal looking at forbidden data going on here, he was simply trying out stuff with telnet. Should reverse-engineering a network protocol be considered wrong? I don't think you'd get any court conviction on that and neither do I think it's morally wrong.

The Bitkeeper "free" license at the time also contained a number of questionable clauses, like basically forbidding anybody who used BK to even think about working on any other SCM. That's just ludicrous IMO. Regardless of that, Tridge wasn't bound by the license because he was not using BK in his reverse engineering, but I think it shows another example of what's wrong with Larry McVoy's mental model of the world.

So I think the fiasco was caused more by McVoy's attitude[1] than by any actions of Tridge's. The issue isn't clear-cut however, hence the "or" sign :-). I tried to make my reply short[2] because it's OT to this forum, and therefore I necessarily left details out. The same thing that applies to tilly's comment also applies here though: exactly why the situation blew up is irrelevant to the danger closed formats represent. McVoy's company could have gone out of business, or he could have been ousted and the new board decided to stop giving free lunches to the open source hippies, and the result would have been exactly the same.

[1] And before someone gets a wrong impression I'd also like to say that in contrast to this affair Larry McVoy has done more for free software than most people in the world (and certainly more than me), he's a fine software engineer and IMO noone should hold a grudge against him for all this. I just think he was wrong on a lot of points here and wish he had a good public-relations person to talk to before sending emails to some people.

[2] Since there does seem to be some interest in a fair and/or more detailed account of the story I'd be happy to write it down more extensively, please /msg me if you feel this would be of value either on PM or off.

Update:I've just realised that the stricken-out part is not true.


Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

Wow, I can see where this would have been a total meltdown. That's a very compelling reason not to use Perforce, so I have to agree - it's only free as in beer. I think I'll uninstall it myself, now... thanks for the info.

UPDATE:Someone asked me whether this comment had been sarcastic. Not at all. The debacle as described was a prime example of why it wouldn't be a good idea to use non-open source software for version control. Knowing this, I have changed my mind about using Perforce, and will indeed uninstall it.