I've spent the last week considering the data and opinions concerning the Heartbleed bug that was found in the widely used OpenSSL cryptography library. OpenSSL is an open source project, so the occurrence of the bug has created an opportunity for many to decry the weakness of open source with shallow comments like: "The Heartbleed flaw, introduced in early 2012 in a minor adjustment to the OpenSSL protocol, highlights one of the failings of open source software development."
I disagree with this profoundly. As Eric Raymond points out:
[O]ne thing conspicuously missing from the downshouting against OpenSSL is any pointer to a closed-source implementation that is known to have a lower defect rate over time.
[ 5 no-bull facts you need to know about Heartbleed | Track trends in open source with InfoWorld's Technology: Open Source newsletter. ]
Fortunately the kneejerk attacks on open source have been few, with most opinions tempered by the observation that OpenSSL is widely used because it is broadly the right solution for most programmers needing a TLS library. But a more thoughtful article in Wired still lists a series of potential criticisms of open source which could equally apply to proprietary code in the same roles.
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. While commercial involvement is probably a key to reducing future risks, that does not equate to any preference for opaque proprietary behavior.
OpenSSL is probably the least-bad solution to the need for a crypto library. Recognizing that is not to deny problems in OpenSSL. As has been widely reported, the staffing levels of the OpenSSL project are woefully inadequate. One former project contributor explained to me that it's complicated and unrewarding programming, and most people capable of doing it are also capable of getting a great job somewhere else. It would be reasonable to suggest that this staffing issue is actually a business model problem. While the project is busily fundraising, the actual problem is more fundamental, as the creator of an open source PDF facility explains:
I've said it before and I'll say it again: Good engineers build great technology; great engineers also create a sustainable business model. Based on my 15 years of experience in open source, I know that it's almost impossible to create a sustainable business model based on the Apache Software License [used by OpenSSL].
The sparse OpenSSL community has led some to assert that it's the source of the problem, that what's needed is proven community governance and strong community. While I agree with that both for OpenSSL and as a general concept, I believe it is a consequence of solving the problem and not the means. There's no magic that will result in a team of smart crypto programmers suddenly appearing if there's no business case for whoever pays them.
Security experts acknowledge that open source is the best model for crypto. Many eyes do indeed make bugs shallow, just so long as you can get them to look. So how do we drive improvement in the best-available model for creating security-critical infrastructure? Making Light says:
OSS culture doesn't get called "socialistic," but it's self-organizing and anti-capitalist in its own way.
Open source is indeed not socialistic, but it's also not anti-capitalist, since it depends on many developers independently responding to their own source of motivation to meet their own needs, but maximizing the benefit -- lowering the cost and raising the innovation -- by collaborating with their peers. The best way to drive improvement is to make it more rewarding, both financially and reputationally.