Why the Heartbleed Bug does not invalidate the spirit of open source
Tags: security, musings, software
The Heartbleed Bug got a lot of (well-deserved) media attention in the last few days. While some newspapers focus on the more technical aspects, a large German newspaper, the ZEIT, published an article about how the Heartbleed bug manifests an Inconvenient Truth of Open Source.
The article claims that the “promise of salvation” made by open source enthusiasts has become very questionable. This promises is the claim that open source software is always better than proprietary software. The author of said article then writes about the “hostile feelings” of the open source community towards private companies that attempt to finance their projects. The article concludes by underlining the need for making the open source development process more professional. In the author’s opinion, this requires more full-time developers, managers, and stable funding.
I do not concur with this article. First of all, Heartbleed is a very good example of how the open source community works in times of a crisis. A patch for the fix was created and rolled out for OpenSSL within two weeks after the initial discovery! Some companies were able to patch their systems even before this date (see this interesting article of the Sidney Morning Herald for a more detailed time-line). While I am not happy with this bug either, I salute all involved persons for their quick reaction.
Compare this with the behaviour of some companies when critical flaws are discovered. Just search for the infamous “goto fail” of Apple. Or some of the Java security vulnerabilities found by Adam Gowdiak.
The only disgraceful thing about Heartbleed is that almost everyone on this planet used OpenSSL but almost nobody contributed to it. Of course, a proper code contribution would require in-depth knowledge of cryptography and C programming, a combination which excludes many people. For example, I know some of the cryptographic algorithms, but not even remotely in a sufficient depth to contribute anything meaningful. However, there are certainly some companies whose employees have a profile that fits these requirements. And even if there are not any of them, they can still support OpenSSL financially. Having contributed to some open source projects on a regular basis, I am slightly ashamed that OpenSSL went under my radar for far too long. This is going to change.
Last, I want to propose a counterpoint the last idea in the article, namely that open source needs to become more professional. I strongly suspect that the author does not really know what degree of professionalism is already present in open source. It is not my place to speculate about whether the motivation for open source developers substantially differs from the motivation of employees. However, the practices of the open source world must not be as dismissed as easily. Often, methodologies & best practices (e.g. Scrum or Refactoring) arise in the open source community before seeping into larger companies.
Instead of seeing the problem in the lack of managers for open source projects, I tend to see the lack of contributors and/or funding—in the last point, I actually agree with the author. Maybe throwing more money at projects such as OpenSSL, some *BSDs, and Linux is a good idea for ensuring that open source software remains a viable alternative to proprietary software.