In the days when the open-source model needed to prove itself to be taken seriously by businesses, a frequently touted benefit was that the availability of source code made security reviews possible. And through these reviews, defects could be caught and repaired quickly. This benefit is sometimes referred to as Linus's Law, even though it appears to be formulated by Eric Raymond in his seminal book The Cathedral and the Bazaar. Raymond's articulation is: "Given enough eyeballs, all bugs are shallow." Other sources attribute it directly to Linus Torvalds, formulated as: "Given a thousand eyes, all bugs are shallow."
This claim, which I'll get into in a moment, was important at the time because it directly attacked a pervasive, countervailing fear that providing the source code to software was a security risk because it enabled hackers to find ways to find exploits.
The claim of many reviews, however, was problematic from the get-go, mostly because of the inference that the uninitiated drew from it that there would in fact be thousands of eyes looking for bugs. Even in those early days, those of us in open source knew that was not going to happen. There would not be a thousand eyes scanning the source of the Apache Web server or of Subversion looking for defects or exploitable toeholds.
At best, if defects made their presence known, users could assist developers in tracking down the offending code and signaling the problem and, sometimes, the possible solution. That is, detectable bugs would indeed become shallower due to universal access to source code.
And this is pretty much how things have worked out in open source ever since. The vast bulk of the code is written by core committers. The galaxy of additional contributors (or in most projects, the constellation) generally provide bug reports, proposed patches, and occasionally code to a desired feature.
As Marc Fleury, who headed up the JBoss project, once expressed to me: "A principal value of open source to the project is the ability of having hundreds of testers and bug reports, often accompanied by diagnostic information."
Unfortunately, this important dynamic has been misunderstood by many people, who view open source as having claimed to provide better security because those "thousand eyes" would review the code. (And unfortunately, this claim is still occasionally made on behalf of open source.)
The disappointment that such review work does not happen has been given new life due to the two recent high-profile defects: the OpenSSL bug ("Heartbleed") and "shellshock" in bash.
While few critics directly attack the idea of open source anymore, they do assail these projects for not finding vulnerabilities and defects earlier. As I've discussed in an earlier editorial, this view asks the wrong question on projects where the developers are unpaid. As to the larger OSS community, however, the reasons for the delay are the same as they would be for all software, open or closed: No one found it, or no one tested it, or the defect was not sufficiently symptomatic to be manifest. These answers are unremarkable because they are the same, regardless of the development model.
The difficulty in castigating open source for not having fixed longstanding defects is that we have no real idea how the track record for OSS compares with closed source. While we can count defects fixed in some closed-source packages, based on the updates and data the vendors publish, we rarely have the benefit of knowing how long a given defect has remained unfixed.
It's a shame that recent high-visibility bugs cast a shadow on open source, whereas their equivalents in closed source software suffer no such effect. But in fact, part of the problem is one of expectations and it lies with a misunderstanding about what open source could deliver ("1000 eyes") versus what it would reasonably deliver (the eyes of a few core developers).