‘Cool it, Linus’ – Bruce Perens

April 16, 2005 | Operating Systems, Rants and Raves | By: Mark VandeWettering

Over on the Register, there is an article on the ongoing row between Linus Torvalds, Andrew Tridgell, author of the Samba software you’ll find as part of many operating system distributions, and Larry McVoy, CEO of Bitkeeper software, the proprietary revision control software which is used to help maintain order in the Linux kernel source tree.

It’s turning into quite a tiff, and Bruce Perens has weighed in and asking for cooler heads to prevail.

The problem is as far as I can tell, entirely Linus’ fault. He made what must be viewed as an incredibly short sighted decision: to use a propietary product as a key element in open source development. It’s a bad idea, for a number of reasons.

First of all, proprietary software is managed by commercial entities. They are allowed to sign NDAs, they can purchase and sublicense proprietary technology and they go out of business. When such a company goes out of business, there is no guarantee that the software which you are using will continue to be available. Putting the long term viability of your open source project at risk in this way is wreckless.

Secondly, if your goal is to promote open source software promote open source software by sleeping in the bed you’ve made. If the open source alternatives aren’t as good as the proprietary ones, then through your weight behind new or existing projects to improve by using them. Linus wrote:

“So I think open source tends to become technically better over time (but it does take time), but I don’t think it’s a moral imperative.” he writes.

The real issue is of course not whether it is a moral imperative, but rather do most people who would work on such a project view it as better to use and improve open source tools which can be made available to all, or to simply use the best tool available, despite it being against the principles which supposedly you began writing open source software to espouse?

Lastly, Linus simply didn’t take the feelings of a large subset of kernel developers into account. For projects which rely on volunteer labor, that’s just dumb.

I’ve used cvs for years, and spearheaded its use within a couple of different organizations. It’s got its flaws, but it is open, and available, and I’m willing to wait until other open source code revision systems have features which make it profitable for me to change. In my career I’ve used SCCS, RCS, CVS, Perforce and subversion, and will probably use some more before it’s all over. For my own personal work, work that I care about, I’ll choose open alternatives every single time.