Disbelieving the many eyes hypothesis

There is a view that because Open Source Software is subject to review by many eyes, all the bugs will be ironed out of it. This is a myth.

Writing code is hard. Writing secure code is harder: much harder. And before you get there, you need to think about design and architecture. When you’re writing code to implement security functionality, it’s often based on architectures and designs which have been pored over and examined in detail. They may even reflect standards which have gone through worldwide review processes and are generally considered perfect and unbreakable*.

However good those designs and architectures are, though, there’s something about putting things into actual software that’s, well, special. With the exception of software proven to be mathematically correct**, being able to write software which accurately implements the functionality you’re trying to realise is somewhere between a science and an art. This is no surprise to anyone who’s actually written any software, tried to debug software or divine software’s correctness by stepping through it. It’s not the key point of this post either, however.

Nobody*** actually believes that the software that comes out of this process is going to be perfect, but everybody agrees that software should be made as close to perfect and bug-free as possible. It is for this reason that code review is a core principle of software development. And luckily – in my view, at least – much of the code that we use these days in our day-to-day lives is Open Source, which means that anybody can look at it, and it’s available for tens or hundreds of thousands of eyes to review.

And herein lies the problem. There is a view that because Open Source Software is subject to review by many eyes, all the bugs will be ironed out of it. This is a myth. A dangerous myth. The problems with this view are at least twofold. The first is the “if you build it, they will come” fallacy. I remember when there was a list of all the websites in the world, and if you added your website to that list, people would visit it****. In the same way, the number of Open Source projects was (maybe) once so small that there was a good chance that people might look at and review your code. Those days are past – long past. Second, for many areas of security functionality – crypto primitives implementation is a good example – the number of suitably qualified eyes is low.

Don’t think that I am in any way suggesting that the problem is any lesser in proprietary code: quite the opposite. Not only are the designs and architectures in proprietary software often hidden from review, but you have fewer eyes available to look at the code, and the dangers of hierarchical pressure and groupthink are dramatically increased. “Proprietary code is more secure” is less myth, more fake news. I completely understand why companies like to keep their security software secret – and I’m afraid that the “it’s to protect our intellectual property” line is too often a platitude they tell themselves, when really, it’s just unsafe to release it. So for me, it’s Open Source all the way when we’re looking at security software.

So, what can we do? Well, companies and other organisations that care about security functionality can – and have, I believe a responsibility to – expend resources on checking and reviewing the code that implements that functionality. That is part of what Red Hat, the organisation for whom I work, is committed to doing. Alongside that, we, the Open Source community, can – and are – finding ways to support critical projects and improve the amount of review that goes into that code*****. And we should encourage academic organisations to train students in the black art of security software writing and review, not to mention highlighting the importance of Open Source Software.

We can do better – and we are doing better. Because what we need to realise is that the reason the “many eyes hypothesis” is a myth is not that many eyes won’t improve code – they will – but that we don’t have enough expert eyes looking. Yet.

* Yeah, really: “perfect and unbreakable”. Let’s just pretend that’s true for the purposes of this discussion.

** …and which still relies on the design and architecture actually to do what you want – or think you want – of course, so good luck.

*** nobody who’s actually written more than about 5 lines of code (or more than 6 characters of Perl)

6 thoughts on “Disbelieving the many eyes hypothesis”

I think you overlook where the “myth” comes from. There ason why Open Source software is *more* looked at and therefore tend to improve much faster than proprietary software, is that when people do use it, they will end having issues.

When you have issue you have 3 options:
– do nothing, live with the issue
– toss the software away and replace it
– debug it and fix “the dam’ thing”

I believe the third option si what most people undertake, at least at first, and they do it because FOSS makes it not only possible but also relatively easy given sources and packages and debuginfo are generally available.

So while you won’t get perfect software you’ll definitely get better software via this process.
Will all bugs be solved ? Nope, but the overall quality will be better.
Empyrical evidence of this was uncovered back a few years ago when Coverity started scanning open source software.
At the time static analysis was not very common, yet, right off the bat FOSS software, had, on average, less defects per line of code than proprietary software (according to coverity), and when coverity started reporting their runs to FOSS projects they also got record times for fixes that completely put any proprietary company to shame.

(Search for Coverity, DHS, 2006, Open Source to find references on the web, I
cannot find the original press releases/Coverity papers right now)

Simo – you’re quite right, of course, and I was careful to make the point that I strongly believe that Open Source software _is_ preferable to proprietary, closed source software in terms of security. I would choose Open Source over proprietary any day of the week. However, just the fact that it’s Open Source isn’t enough: we need to expend resources to ensure that enough attention – enough expert attention – is expended to reduce the number of bugs in our security-related code.