McVoy on BitKeeper, Linus, and Perens
Joe Barr writes "The story of how BitKeeper has come to be Linus Torvalds' (and many other kernel hackers) tool of choice in maintaining the Linux development tree is worthy of a book. Here's the Cliff Note's version of McVoy's contribution to Linux kernel development, BitKeeper, and countless hours of flaming on the role of open source and proprietary software."
What is a BitKeeper?
char bitsafe;
void SetBit(char bit)
{
if (bit != 0 && bit != 1)
FatalError("bit must be 0 or 1");
bitsafe = bit;
}
char GetBit()
{
return bitsafe;
}
McVoy seems very reasonable in this interview. He's a smart guy, and, like he says, a little insecure.
However, it would be best if someone came up with a Free alternative to BitKeeper as quickly as possible.
Proprietary source code management is a little too dangerous in my opinion. It gives the code owners unilateral power over your project, even if they don't choose to exercise it today, they might tomorrow. You might be forced someday to choose between accepting their new terms, or moving your project to a new system (which might take months of time).
It's pretty stupid to choose your software ONLY on technical merit (the "best tool for the job" mentality that engineers and technical folks have). Remember that the license and the business model of the company offering the software might have a material impact on YOUR business someday!
When your code is tied up inside of another company's product, it's best to stick with Free software if possible.
1) It doesn't matter what soource control system you use, you still own your own code. If the company making the source control product goes nuts, then you just have to abandon them.
2) The best tool for the job mentality comes from long experience with inadequate tools. All too often people come along saying "Here use the screwdriver. I know you need a hammer, but at least my screwdriver is ethically pure." Open Source tools are a good thing. They are not always the best fit.
3) Free software is NOT always the best option. Especially for large businesses which are concerned about the potential license taint and support issues. I love Free Software, but it's not always the right fit.
4) There are 2 free alternatives to bitkeeper: CVS and Subversion. Learn them, use them.
As most people will not read the article, and just go to the comments, I feel that I should point this out. This is an interview with the person behind BitKeeper. His opinions are (obviously), biased, and should be taken with a grain of salt.
Possibly because of that, he comes across as a reasonable individual, although there was one issue which stuck out in my mind. If he advocated that Sun open source SunOS, stating that it was a feasible option, why hasn't he done the same for BitKeeper?
-
Proprietary vs Open
-
Cost vs Free
-
Freedom vs Artificial Restrictions
-
'Best Tool for the Job vs Ideal Choice
-
Long Term Investment vs Rapid Development
And that's just scratching the surface. There are valid reasons for choosing one path or another. This article is enlightening in that we now have a face and series of reasons as to why McVoy chose to implement Bitkeeper as a company with a business plan that closely resembles common closed source companies.We also have some enlightenment as to how and why Linus chose to move to bitkeeper.
McVoy said, "Hey, Linus, let's work out the system for the 'best tool' to help you do your work." They came up with a rough specification, and McVoy has used that data specifically to create a profitable product, which (he claims) Linus started using spontaneously. The fact that it's almost exactly what Linus needs is by design from the start.
People who are up in arms about it being developed as proprietary software are complaining about the wrong thing. McVoy used his connections to gather information for a product which turned out to be a killer app in the area of source management. The fact that he's letting open source people use it for free is no more philanthropic than Microsoft donating software to universities at a reduced rate - it's another business decision.
What open source advocates ought to be up in arms about is, "Why don't we have an open source product that rivals bitkeeper in its scalability?" The answer is that we've long had tools that were 'good enough', and we've never had a project nearly as large and complex with so many developers and scalability issues as Linux itself has that has justified 3 years of its own development.
We've just added another crutch to the tired old horse that is source management, and said, "We'll get around to replacing the horse someday, but right now I only need feature X so I can complete feature Y on the real project - I'm not going to waste my time building tools."
As far as the constant 'best tool' vs 'ideal world' choice goes, the idea that one should use the best tool for the job regardless of ideology is the same argument that says, "It's ok that my t-shirt was made by a 12 year old in malaysia, who works for 12 hours a day and barely gets enough to eat for the pay." There are good reasons for voting with your money, and voting with your use and advocacy of obviously inferior and possibly more expensive (in time, materials, money, etc) tools and products.
However, a good tool can make one significantly more productive, especially if there's no learning curve associated with the use of that tool. I'd have no problem learning that, say, Red Hat uses MS Windows and Office inhouse for its sales force and secratarial staff. They probably don't, but if they did they'd have to give little or no training to new hires, increasing their immediate productivity.
The reverse is also true, in many circumstances though. Investing time and money in training those employees can have long term payoffs - such as increasing the number of people in the world who can use such systems. It took Linus quite some time to come back up to his normal slow speed when he started trying out bitkeeper - but reports indicate that the investment has paid off, and he is now much more able to handle the load at a faster rate.
Remember - this is just a scratch of the surface, and the fact is that these discussions are largely subjective and ideological. First be true to yourself. If you can't, in good conscience, use bitkeeper, then good for you. If you find you're more productive, and that's worth the ideological tradeoff, then congradulations on making that choice, knowing why you made that choice, and defending your choice as right for you. If you don't see it as a good tradeoff, then good for you for sticking to your guns - but don't gun down others because of your beliefs. They are not inferior - they simply have different values and priorities, and if you don't think they have the right to choose, then your closed mind is doing the worst damage to open source that can be done today.
-Adam
"potential license taint"? What are you talking about? There is no potential license taint with free software. It is distributed under certain terms, if you want to incorporate the software in your own, then you have to either accept those terms or license a proprietary version of said software, if possible. With proprietary software, the only option you have is the latter.
Stop spreading this bullshit FUD about license tainting; it's absolutely ridiculous.
You say you love free software, if so, then please understand what you are saying about it.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
For those of you keeping score, that's an overage of 48 TIMES the initial estimate. Even the NASA didn't do that bad with the ISS.
For years, open source users used RCS (and bastard son CVS). They have problems, but they were "good enough" for 'rms/gnu hello world'. But they were inadequate for a more serious project, like linux. Of course, corporations often used superior tools like Visual SafeSource, or perforce (which the *BSDs use under the free perforce license).
Then, along comes Larry McVoy, who builds a versioning system that doesn't have CVS's limitations, and offers it for free to open source projects. Check the numbers, you will see that Linux has improved while using BitKeeper. But instead of thanking LArry, the gnu/zealots piss their pants because linus didn't use CVS.
Fucking ingrates.
According to this report (repeated also on bugtraq), there is important security hole in Bitkeeper (found in November). Looking at the Bitkeeper pages I can't find any notification about the problem or the patch. In the Polish article the guy who found the vulnerability reports, that Larry McVoy just stopped replying to mails when they started discussing when the advisory should be published.
Leaving the but itself alone, the lack of information on their web pages and the lack of the patch after the advisory was published is - especially when talking about distributed internet application - very disguisting. The lack of information what has changed from version to version is disguisting too.
I backed bitkeeper in many discussions. No more.
The advisory is also available here
What the fuck are you talking about? Of course you have that choice! WTF?
With OSS, the equivalent choice is to not include that software in your own, but you can still use it, study it, look at it, etc. OSS software gives you equal + more choices than proprietary software -- integrating the software into your own according to OSS licensing terms/using it/integrating it and not distributing it(in which case you are not bound by any terms) OR getting a non-OSS/proprietary license from the authors of the software for you to use in your own proprietary product(if the authors are willing), whereas with proprietary software you cannot use it under any conditions without consent of the authors.
The extreme (let's screw ourselves because the tool/os/app we need is not 100% certifiably open source free-as-in-whatever) is problematic at best and stupid at worst.
Where the hell did I ever say that?
Get a fuckin` clue...
Sticking feathers up your butt does not make you a chicken - Tyler Durden
The proprietary product may not be around tomorrow, it's license may change, or they may hold your work for ransom, and you have no control.
This argument comes up quite a bit and I don't understand it.
If I buy an indefinite licence of fookeeper and use it to control my source, how can I be stopped from using my own repository? If the fookeeper authors deprecate it and stop me from buying more licences, I can use my old licence to extract revision history from fookeeper and feed it into my new revision control software.
If I buy a year's licence for fookeeper and decide not to renew it, I have plenty of notice to extract revision history from it and feed it into my new software before it stops working.
If I'm a good developer and back up my working copy daily then I'll always have a recent snapshot of my source anyway.
How could the software not be around tomorrow? How could they 'hold my work for ransom'? Why don't I have control?
Ta.
If you buy a bitkeeper licence, then presumably you're fine. This debate is about the no-cost licence.
That licence gives lm the right to change the licence in the future and to revoke your licence. He has demonstrated publicly that he is very willing to do this to people who annoy him. The licence is essentially the "don't piss off larry" licence.
lm insists that since he's allowing people to use it at no charge, he is able to impose whatever conditions he wants. That may or may not be morally or legally fair. All I'm suggesting is that it's a bad idea to take him up on the offer.
I have plenty of notice to extract revision history from it and feed it into my new software before it stops working.
No, you may not. For example, with no warning, Larry announced that people who have sent patches to arch, cvs, or subversion are not allowed to use bk. If you're part-way through a project that depends on it, you're screwed.
Even if you don't fit into this category, then I think you ought to be concerned that you might be next.
Suppose RMS was always changing the GPL to ban Microsoft, or Amazon, or whoever he dislikes this week. Even though I'm not at Microsoft, it would make me pretty worried about the potential future changes.
If I'm a good developer and back up my working copy daily then I'll always have a recent snapshot of my source anyway.
Sure, but merely having your working copy is a poor compensation for losing your change history. If that was all you wanted, and you made backups every day, you wouldn't need a CM system at all.
If you want a proprietary system, look at BK: it's good technology, although not as novel as lm says it is. However, if you want to do free software, I think it's a pretty poor idea.