The Worst Things In Life Are Free

I read with some amusement how the Linux community managed to shoot itself in the foot by trying to ‘reverse engineer’ the standard source control system, BitKeeper. The story goes that a certain Andrew Tridgell wanted to write an open source interface into BitKeeper. The CEO, Larry McVoy, of BitKeeper decided that this was a bit too open for his company to bear and pulled the plug on BitKeeper for Linux. The result: much grinding and gnashing of teeth, mostly silence from Mr Tridgell and some not very complementary comments from Mr Torvalds.

Now, apart from the ruckus in the Linux dovecote, what was even more interesting was the interview with Mr McVoy in Forbes Magazine. This really did pour some petrol on the blaze. Essentially (I’m summarizing here), McVoy says that few if any innovative software products have come out of the open source world – they are derivative. And as to the raison-d’ être of open software, the magical source code, McVoy says this: "Open source software is like handing you a doctor's bag and the architectural plans for a hospital and saying, 'Hey dude, if you have a heart attack, here are all the tools you need--and it's free… I'd rather pay someone to take care of me."

This really set me thinking. What good is having the source code for something like Linux? And why is the open-source world so derivative?

For source code, the traditional answer is that if you have a bug, you can fix it. Really? I have to let you into a little secret. If I find a bug in commercial or free software, I might, if I’m feeling generous, email the support group and wait for help. Much more likely, I figure a way round it. What I most emphatically do not do, is wade through hundreds of megabytes of source code, re-compile the kernel and feel pleased with myself for being so smart.

It’s true that there are all these Linux support forums out there who will help you. And I’m sure they do – if the question is of interest to anyone reading. But the thing about support (paid support) is that someone is funded to hack through the uninteresting stuff and get back to you. So what’s the difference between paid Red Hat support and paid Sun support? So long as I get the bug fixed, not a lot. The point is that the source code is useless to me as an individual – if I want something fixed in a hurry, I have to pay for it. I repeat, the source code is useless.

A further point made by the open source enthusiasts (lets call them Linuxites, for brevity) is that you aren’t locked into a particular software vendor. A typical argument I came across is that if your software vendor doesn’t like what you are doing it can walk away, just like McVoy did. I beg to differ here. In most software deals, there are minor details like ‘contracts’ which involve that arcane stuff ‘money’. The consequences of which are, if you walk off the job, you get ‘sued’. I really do wonder sometimes if Linuxites have any contact with commercial realities.

This fixation – paranoia is a better description – with the source code can be counterproductive. Let me give you an example. I was browsing around looking for a real-time operating system (RTOS). In fact, I was looking for one that was small, good and low cost.

Unsurprisingly, there’s a whole load of Linux ones. All of which seem completely indistinguishable at first sight apart from one characteristic: they are huge. The minimum seems to be a 2 to 4MB ROM image.

The first question that comes to mind is what on earth is a RTOS doing in 2 Megabytes? It’s not as if it has to do much more than schedule some interrupts and talk to a TCP/IP stack. 2 Kilobytes ROM is more like the footprint for that minimal set. Now it’s true that if you are doing more than the minimum, then the footprint will grow – and grow substantially. Maybe 4MB is what is needed to do anything these days, and memory isn’t expensive. But what I wanted was a ‘micro-kernel’ approach where you start off small and grow as required. I deeply dislike the ‘kitchen-sink’ approach to software engineering: it’s simply inelegant.

Linux real-time seems to have taken the direction of starting with the available source code – because it’s available – and then trying to make something real-time out of it. Unfortunately, Linux intrinsically isn’t real-time: it was never designed to be so. Still, what’s so wrong with that approach? If I’m not satisfied, the source code is there and I could take it and modify it as required. To my mind, that is exactly the wrong thing to do. To produce a really good anything, you need to start with a design and not an existing solution. But that’s hard. Much harder than taking the Linuxite route of “start with the source code”. A good, free, real-time operating system seems, as far as I can see, to be unavailable. You can have any two of the three: ‘free’, ‘real-time’ and ‘good’ - but not all of them.

My feeling is that, with few exceptions, somebody who is good at software – and I mean really good at software – isn’t going to develop free software. He (or she) is going to become fabulously rich by selling the product of his or her ingenuity. And this brings me to McVoy’s second point “ The open source guys can scrape together enough resources to reverse engineer stuff. That's easy. It's way cheaper to reverse engineer something than to create something new. But if the world goes to 100% open source, innovation goes to zero.” That describes real-time Linux to a tee: it’s derivative and has little innovation.

McVoy’s point is that innovation is expensive. I’d add an additional consideration: to innovate you also need someone exceptional. And exceptional people aren’t going to give away the source code so that some pirate in Uzbekistan can knock out cheap copies.

Sure, open source can be useful. But it’s mostly second rate. And it’s a dead end.

September 2005