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.

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.