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."

Comments

interesting

[Anonymous Coward]

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.

A bit biased.

[wzm]

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?

Best tool for the job or Open Source uber alles?

[Brian Hatch]

The debate between using the best tool for the job, vs using the best Open Source equivalent is going to be around forever. Here are some of my completely random thoughts:

• When you choose an Open Source project and it has deficiencies, you can talk with the developers to explain what needs fleshing out. If you can code, then you can work on this yourself. In the end, you help create a better product that may be more appropiate for a wider audience. It may be painful in the process, however.

• When you are told you must have certain functionality that is not available in an Open Source product, make sure that the requirements are not artificial. When someone requires you have your document in some proprietary format, you can supply it in something open and they may never know the difference. Write your "Word Docs" in OpenOffice. Make your presentation in HTML and run it with a web browser. Question any requirements that seem to be based on the preconcieved notions of the requestor.

• When functionality of an Open Source product is close but below its proprietary equivalent, do remember that "usability" is a factor of what you can do now, and what you can do later. The Open Source product will be available in it's current incarnation freely forever. (And later versions will likely continue to be developed as well.) 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. You will likely find the product depricated forcing a costly upgrade at some point - that's the way the vendor continues to get income.

• When you simply must have a given set of functionality that is not available with Open Source software, and you do not have the ability to work with developers to achieve it, use the proprietary product reluctantly. Stay abreast of changes to the Open Source products available. Do your best to keep as much available outside the proprietary application so you can extract it and put it into something Open Source when available down the road.

Re:Overbudget and late

[The Bungi]

I wasn't keeping score, but you may want to contact Larry and offer your uber-geek madz coding skills. It's obvious you can develop something like BK in time and under budget every time - otherwise you wouldn't possibly think about criticizing them, let alone post your criticism.

Even the NASA didn't do that bad with the ISS.

Maybe "the NASA" has a good job for you. I hear they're looking for volunteers to man the next Voyager mission.

Remember to send postcards.

Re:surely you must be joking

[ChadN]

There are 2 free alternatives to bitkeeper: CVS and Subversion. Learn them, use them.

Actually, I just started using Arch, which has a learning curve, but which is Really Cool (tm).

Distributed repositories, so I can code on the road or at home, and not worry about getting too out of sync.

Re:Best tool for the job or Open Source uber alles

[Anonymous Conrad]

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.