Does the Heartbleed bug refute Linus&#8217;s Law?
<p>The Heartbleed bug <a href="http://www.washingtonpost.com/business/technology/heartbleed-bug-puts-the-chaotic-nature-of-the-internet-under-the-magnifying-glass/2014/04/09/00f7064c-c00b-11e3-bcec-b71ee10e9bc3_story.html">made the Washington Post</a>.  And that means it&#8217;s time for the reminder about things seen versus things unseen that I have to re-issue every couple of years.</p>
<p>Actually, this time around I answered it <em>in advance</em>, in an <a href="http://interviews.slashdot.org/story/14/03/10/137246/interviews-esr-answers-your-questions?sdsrc=rel">Ask Me Anything</a> on Slashdot just about exactly a month ago.  The following is a lightly edited and somewhat expanded version of that answer.</p>
<p><span id="more-5665"></span></p>
<p>I actually chuckled when I read rumor that the few anti-open-source advocates still standing  were crowing about the Hearbeat bug, because I&#8217;ve seen this movie before after every serious security flap in an open-source tool. The script, which includes a bunch of people indignantly exclaiming that many-eyeballs is useless because bug X lurked in a dusty corner for Y months, is so predictable that I can anticipate a lot of the lines.</p>
<p>The mistake being made here is a classic example of Frederic Bastiat&#8217;s &#8220;things seen versus things unseen&#8221;. Critics of Linus&#8217;s Law overweight the bug they can <em>see</em> and underweight the high probability that equivalently positioned closed-source security flaws they <em>can&#8217;t</em> see are actually far worse, just so far undiscovered. </p>
<p>That&#8217;s how it seems to go whenever we get a hint of the defect rate inside closed-source blobs, anyway. As a very pertinent example, in the last couple months I&#8217;ve learned some things about the security-defect density in proprietary firmware on residential and small business Internet routers that would absolutely curl your hair. It&#8217;s far, far worse than most people understand out there.</p>
<p>Friends don&#8217;t let friends run factory firmware. You really do <em>not</em> want to be relying on anything less audited than OpenWRT or one of its kindred (DDWRT, or CeroWRT for the bleeding edge). And yet the next time any security flaw turns up in one of those open-source projects, we&#8217;ll see a replay of the movie with yet another round of squawking about open source not working.</p>
<p>Ironically enough this will happen precisely because the open-source process <em>is</em> working &#8230; while, elsewhere, bugs that are far worse lurk in closed-source router firmware. Things seen vs. things unseen&#8230;</p>
<p>Returning to Heartbleed, one 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.  This is for the very good reason that no such empirically-better implementation is known to exist.  What is the defect history on proprietary SSL/TLS blobs out there?  We don&#8217;t know; the vendors aren&#8217;t saying.  And we can&#8217;t even estimate the quality of their code, because we can&#8217;t audit it.</p>
<p>The response to the Heartbleed bug illustrates another huge advantage of open source: how rapidly we can push fixes.  The repair for my Linux systems was a push-one-button fix less than two days after the bug hit the news. Proprietary-software customers will be lucky to see a fix within two months, and all too many of them will <em>never</em> see a fix patch. </p>
<p>The reason for this is that the business models for closed-source software pretty much require software updates to be an expensive, high-friction process hedged about with fees, approval requirements, and legal restrictions.  Not like open-source-land, where we can ship a fix minutes after it&#8217;s compiled and tested because nobody is trying to collect rent on it.</p>
<p>Sunlight remains the best disinfectant. Open source is no guarantee of perfect results, but every controlled comparison that has been tried has shown that closed source is generally worse.</p>
<p>Finally and in 2014 perhaps most tellingly&#8230;if the source of the code you rely on is closed, how do you know your vendor hasn&#8217;t colluded with some spy shop to install a back door? </p>
