It hasn't been a good year for open source. Not for its generally golden reputation for software quality and security, anyway. But in a rush to lay blame for the Bash Shellshock vulnerability (and previously for Heartbleed) some, like Roger Grimes, want to dismantle some of the cardinal tenets of open source, like the suggestion that "given enough eyeballs, all bugs are shallow."
Sorry, but the criticism falls flat. Here's why.
Living Linus' Law
Ever since Eric Raymond captured "Linus' Law" in his seminal The Cathedral and the Bazaar, open-source advocates have blithely repeated the "eyeballs" mantra. Pointing to Shellshock and Heartbleed, Grimes declares the principle fallacious at best and destructive at worst.
Among other reasons for dismissing it, he intones:
"The 'many eyes' theory should have died a long time ago. Literally hundreds of open source bugs have been found years to decades after they were coded into popular open source software. The theory doesn't work because security code review is hard, mostly boring work. Those who do it well are probably being paid to do it for a living, and they don't have time to peruse every bit of open source code on the Internet."
He's profoundly right and spectacularly wrong, all in the same paragraph. He's right that most bugs escape notice prior to shipping code, which is true of open source or proprietary code. And he's also right that part of the reason is that no one has the time or inclination to do a full review of all the code out there to guarantee that it's bug-free.
But he's wrong in thinking that this somehow proves anything. The full version of Linus' Law goes like this:
"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone."
But that doesn't mean the problems will be resolved prior to release. It just means that given enough eyeballs, all bugs are shallow when people bother to look.
While this may seem like a trivial distinction, it's critically important.
You can't fix what you can't see
After all, most of the world's software is impervious to review. It's proprietary code locked up by vendors or by end users that choose not to open it to outside view.
Could a Shellshock happen to proprietary vendors? Of course. Heard of Patch Tuesday?
But in a proprietary world, as Simon Phipps explains, we are at the vendor's mercy in case of a security exploit, and the vendor can only hire so many "eyeballs":
"The big difference? We would likely never know they applied. Closed development by unknown teams hidden behind corporate PR would seek to hide the truth, as well as prevent anyone from properly analyzing the issue once it became known."
Today, most of the world's software infrastructure is being released as open source, as Cloudera's Mike Olson reminds us, which means we'll be able to discover and jointly tackle the Shellshocks and Heartbleeds of the world. This is a huge upgrade over a past spent waiting for Microsoft or other proprietary vendors to discover and fix problems on their own.
Better quality? Yes. But mostly, a better process
While open-source software does offer higher-quality software with fewer bugs (contrary to Grimes' contention), it's not perfect. Coverity's annual code quality report found "an average defect density of .59 for open source C/C++ projects... compared to an average defect density of .72 for proprietary C/C++ code developed for enterprise projects."
But that doesn't mean we should indulge "magical thinking," to quote Steven J. Vaughan-Nichols, and assume just because it's open source that it's inherently secure, better, or breeds unicorns. As he writes, "The open source method remains as good as ever when used correctly."
This brings us back to Linus' Law, which is just as valid as ever, and open source remains a better way to build and deploy software. Sometimes, however, we won't fully appreciate open source's benefits until all hell breaks loose, and we're only able to tackle the problem — together — because we have access to the source. That's far better than the alternative.
Matt is currently head of the developer ecosystem at Adobe. The views expressed are his own, not those of his employer.
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.