C/C++ Users Journal April 2004
Free software is not a new phenomenon. In fact, up until about 1970 pretty much all packaged software was free. Vendors gave away compilers and operating systems to people who bought their multimillion dollar computers. Sure, banks and insurance companies paid serious money to get custom software written for them, but most smaller users swapped their own applications with nary a thought to the internal cost of developing them. The only profitable prepackaged software I can recall from that early era was a superior replacement for the sort utility shipped with the IBM mainframe operating systems.
Once IBM started charging separately for their software, a new industry was born. Sorting was not the only specialized niche where an aggressive little company could hold its own against the giants. By 1978, when we started Whitesmiths Ltd. to sell C compilers, packaged software companies were still a novelty, but they were at least an accepted alternative to the hardware vendors.
Our first product, a DEC PDP-11 C compiler, promptly went up against a free compiler available through the DEC users group. Our second, an Intel 8080 C compiler, faced the dirt-cheap BDS C from Leor Zolman. Our third competed against another giveaway. And so it went for each succeeding product. When it's time to build railroads, as the saying goes, people build railroads. When it's time to write certain software packages, some folks are willing to write them for free.
Somehow, Whitesmiths still survived and prospered for 10 years before we sold it. And somehow, my latest company, Dinkumware Ltd., has also survived and prospered for over eight years so far, even though once again our principal competition is free software. We like to say, only slightly tongue in cheek, that we compete on price, by selling to people who can't afford free software. Customers who understand the true costs of maintaining and enhancing critical software packages also understand the simple truths behind these glib slogans.
It is thus with some amusement that I've watched the latest surge of interest in free software. Please understand, I'm all for people giving away software if that's what they want to do. But I see no particular virtue in it, or no particular threat to those of us who choose to sell it for a living. The revolutionaries who want to bring down Microsoft should instead worry about the survival of their own little enterprises. Not because they will be attacked by the money grubbers but because free software projects so often die young, of natural causes.
The problem lies in what I call the Law of Essential Complexity. If a software package is too easy to write, most potential customers will just write their own. If it's too hard, nobody will write it. It will succeed and endure only if it's doable, but so hard to get right that most people would rather not try to do it.
The first consequence of this law is that it takes a long time for a bunch of volunteers to develop a package of sufficiently interesting complexity. Linus Torvalds mined a decade of accumulated contributions to Project GNU to make Linux an overnight sensation. GCC has also grown slowly, and not always steadily, to its present power as a multilanguage, multiplatform compiler. Similar remarks apply to glibc, libstdc++, STLport, and other library packages.
When the money folks discovered free software during the dot-com boom, it was like the Bronze Agers finding the ground strewn with copper nuggets. Now that those nuggets have been swept up, the supply of new freebies to exploit has demonstrably slowed. Companies face the prospect of digging deep shafts to get more high-quality ore. For some reason, they seem less willing to throw nice chunks back in the melting pot, like all those earlier volunteers did.
Another consequence of this law is that the quality of free software is not always monotone increasing. Yes, there are a thousand pairs of eyes reviewing every release. But only a handful of people understand the complexities of a package well enough to know a real bug when they see one, or how to fix it without causing further damage. Equally, it is not an advantage to have lots of cooks contributing to the soup. If a project doesn't have a few old timers who grok the complexities, contributions accrete but they don't get integrated. And once a project loses most of its critical stewards, it is doomed to a lingering death.
All these consequences apply to commercial software, too, of course. But there's an essential difference. If a company has a financial stake in keeping a software package alive and flourishing, it can throw money at the problem. That's not sufficient, but it's often necessary. Free software doesn't have that option, almost by definition.
P.J. Plauger
Senior Contributing Editor
pjp@plauger.com