From Visual Developer Magazine #55, May/June 1999

Unconventional Wisdom

40,000 pairs of eyeballs can find a lot more bugs than 40, especially when those 40,000 debuggers do not have to be managed, paid, and badgered to produce results on a schedule.

He looks a little bleary, as though he's been staring at a terminal screen for thirty hours. His hair could use some combing, and his mustache sticks out in fourteen directions. He is obviously one of our tribe, and he has packed a double ballroom in a Scottsdale resort hotel with people who look a lot like him. He is pacing around the stage, microphone in hand, quoting John Locke and speaking in both anthropology and business school jargon, ultimately delivering a scorching three-hour rant that is at once cogent, hilarious and crusty with destiny. When it's over, the walls shake with applause, yelling, screaming, and foot stamping. I'm in the audience, watching history turn a corner. Software development will never be the same again.

He is Eric Raymond, an unlikely prophet with an unlikely message: That the software industry and the programmers working in it will be better off if some or even most software (and particularly operating systems and communications software) is available free of charge, including source code. I've known about what we now call open source software for some time, but considered it an eccentricity of programmer culture. Eric's mission these days is less to deliver his harangue to people like us (definitely the choir) than to make his case to Fortune 500 executives like those attending PC Forum in Phoenix the following day. There is both software engineering and business sense in the open source methodology, and Eric has both arguments down cold.

The arguments are complex, and I can't cook a three-hour rapid-fire presentation down to 500 words. The business argument in particular has a lot of moving parts, but much of it lies in a contention that software companies can make more money selling service and support for free software than they can selling the software as a boxed product. I know that this is true for large, complex products: We pay $1800 per year for phone support for QuickFill, the vertical market app that manages this magazine's circulation, and we do it gladly—and those support bills now amount to several times the initial cost of the software.

Much more interesting, to me at least, is Eric's contention that open source methods are the only way we can create and manage robust software at the level of complexity our industry now requires. For all its complexity—now perhaps ten million lines of code—Linux is clean. Linux's only serious competitor, Windows NT, is a mystery by comparison, and while far more robust than Win9x, it still crashes much more often than Linux.

The obvious reason is that debugging scales very well. 40,000 pairs of eyeballs can find a lot more bugs than 40, especially when those 40,000 debuggers do not have to be managed, paid, and badgered to produce results on a schedule. The Linux organization of one brilliant man at the center surrounded by a team of ten subsystem deputies seems to lie at some sort of sweet spot on the communication benefits-to-burden curve. Eleven guys seems to be about as many as you can fit around a table and get anything useful accomplished—even if the table is virtual and the distance between members world-spanning. The 40,000 volunteer debuggers communicate only with those ten deputies, and in general not with one another, so there is little wasted communication. The setup wasn't invented so much as discovered, and it works like purest magic.

Open source software development is almost entirely a Unix—and within Unix a Linux—phenomenon. Some Windows projects are beginning, and a few, like the Apache Web server, are already mature. Eric Raymond contends that proprietary, trade-secret software has become as complex as it can become without collapsing under the weight of its own bugs. Is it true? The constant slipping of Windows 2000's schedule suggests that it is. Bugs and crashes can be catalogued and their frequency measured. Sooner or later, we will know. And as Eric concluded his riveting presentation the other night, "Then we will win."