Tempting though it is to try to delegate the problem to Kickstarter and its like, that's not done by throwing gifts at developers. The situation has prompted a variety of writers to claim Eric Raymond's dictum -- many eyes making all bugs shallow -- is false. I disagree with them; I think Raymond has a great point, but the utopianism that sees volunteer communities as the answer stops short of understanding why people volunteer and volunteer the "many eyes." Usually it's because someone is paying them to.
That's the problem we have to fix, both short-term and long-term. Short term, we need to get a team paid to audit OpenSSL again -- it was last done in 2002. That could be crowdfunded as the Truecrypt audit was, or it could be bankrolled by some of the corporations who care about open source -- a great opportunity to show their bona fides. This should be a one-off activity, in my view.
The question of the steps beyond this -- procedural details, review boards, committees, and certifications and so on -- has proved compelling to some. These will undoubtedly form part of a comprehensive solution and need medium-term attention. Since this work is so critical to so much of our infrastructure, we may well need to look back to the early days of the Internet and create some sort of independent, independently financed brain trust from which we can staff audits and reviews.
But I don't think we have to sweat these details long term. We can safely leave that to the demand created when we identify the reason for the lack of incentive. The reason is OpenSSL is good, available, and free, for sure. But there's a deeper issue: Using it has no consequences. In the inevitable case where a failure of code or concept is discovered, no one is blamed apart from the developers. Shouldn't the commercial entities using the code have done some due diligence? Isn't their lack of investment at least partly to blame? Software freedom delivers rights. What about responsibilities?
They should be employing developers to participate in this crucial project, so they have in-house skills in its close to half-million lines of code. We know who they are. Why haven't they invested? I believe that's the result of the ability of commercial software suppliers (of all kinds, proprietary and open source) to disclaim liability. Unlike pretty much any other kind of commercial venture, the deployers of software are able to disclaim all liability for harm caused by their code. Fix that, and the magic of market forces will fix everything else.
This is not to say the authors of the code should be personally liable. Open source projects don't exist to create code for nonparticipants; they exist as the locus of collaboration for developers. It's not reasonable to hold a project liable for its code quality (even if we should ask serious questions about code quality and governance). But the entities that deploy the code do have a responsibility. They need an incentive to pay developers, pay auditors, and promote quality and accountability. We'll only get that when we fix the liability issue.
This is not a new thought. For example, in a 2008 report the European Union Agency for Network and Information Security said:
Networked systems, however, can cause harm to others, and the Commission should start to tackle this. A good starting point would be to require vendors to certify that their products are secure by default.
We recommend that the EU develop and enforce standards for network connected equipment to be secure by default.
Why has this not happened? I suspect the explanation concerns corporate lobbying by large proprietary software companies. It's time for that to change, while we still have Heartbleed as a recent memory. Open source remains the best model for crypto (as well as most other software); we need to make sure software deployers realize that with great (software) freedom comes great responsibility.
This article, "Stop blaming open source for Heartbleed," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.