CNET logo Why You Can Trust CNET

Our expert, award-winning staff selects the products we cover and rigorously researches and tests our top picks. If you buy through our links, we may get a commission. Reviews ethics statement

Open source may have won, but not by *that* much

Keith Curtis spent 11 years in the bowels of Microsoft, and may have fallen too hard for his first love outside Redmond: open source.

Matt Asay Contributing Writer
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.
Matt Asay
3 min read

Though Keith Curtis (@keithccurtis), author of After the Software Wars, spent 11 years programming for Microsoft, once he bit into the open-source software apple, he bit hard. In Curtis' enthusiasm for open source, however, he sometimes confuses his beliefs and aspirations for what open-source software can achieve with the market as it actually is.

I can relate. I have that problem, too, at times.

Curtis makes a wide array of valid points, but sometimes they contradict each other. As just one example, he cites Stanford University research that reveals just .17 bugs per 1,000 lines of code in Linux to highlight Linux's reliability compared to Windows and other proprietary software, which tends to average 20 to 30 bugs per 1,000 lines of code.

This sounds great for Linux until Curtis points out that the median age of those bugs is ten months, roughly three times longer than the Linux kernel's release schedule. This wouldn't be such a problem if Curtis didn't point out the cause for bugs' longevity: developer whimsy.

The good news is that it is easier to fix bugs than to write code because writing code involves design, which in turn requires difficult decisions to be made....In the bugfixing phase of a software product cycle, most of the hard decisions have already been made, so it is mostly a matter of maknig small tweaks....

Fixing these bugs might be tedious, especially when the developer doesn't have access to the hardware he is trying to debug, but everything about hardware is tedious so they may as well just do it now.

Except that they don't. Bugs sit there, as Curtis documents, for an average of 10 months. Willing the developers to fix them faster is not a viable strategy.

Nor is castigating commercial open-source developers like IBM and Red Hat, both of which Curtis takes to task for not making the Linux desktop better. Curtis views the desktop as the key to winning on the server, a lesson learned from long experience at Microsoft, and is dismayed by IBM's (Linux desktop code "will not become functional until IBM understands free software can achieve world domination if they do their part!") and Red Hat's (Its "concentration on its for-profit Enterprise offerings has distracted it from creating a healthy community of interested geeks") apparent indifference.

Overlooked in Curtis' analysis is that IBM and Red Hat are minting hundreds of millions (billions, even) from their "wrong" open-source software strategies. They simply don't care about the traditional Linux 'desktop' as much as he does, which is understandable since no one has managed to monetize that desktop.,/p.

Hence, while Curtis' book is a useful guide for those looking for an exit from the proprietary software thicket, his too-ready willingness to believe open-source software is the answer to every software problem leads him into arguments that don't withstand much scrutiny:

I think proprietary software, if it becomes popular and long-lived, is destined to become a mess because it does everything by itself rather than leveraging free software components, and it doesn't receive the constant tending that a garden the size of a city would require.

Curtis and I agree that there are huge benefits that derive from open-source software, but it's hard to dismiss Microsoft's, Apple's, Google's, etc. outsized successes by saying, "30 years from now they'll really be in a pickle!" The rewards far outweigh the risks, in that decision calculus.

Open source is, or should be, a pragmatic tool, not an ideological screed. I believe Curtis views open source through a pragmatist's lens, but derives overly broad generalizations from his data. As noted before, I can relate. This is a problem that plagued me for years.

Curtis has written a good book, but will become an even more potent voice for open source once he marries the positives from years at Microsoft with the positives of years of open source outside it.

Follow me on Twitter @mjasay.