Years ago we used to have debates about whether open source or proprietary software was higher quality, by which we mostly meant fewer bugs. Coverity’s reports each year showed that, in fact, open-source software did have a lower bug density on average.

Not that it matters.

“Of course bug-free software matters,” you insist. But you’re wrong. As David Heinemeier Hansson persuasively argues, bugs are a fact of life in software, and FIXING THEM RIGHT THIS SECOND isn’t what software users actually want, though many demand it. It’s time to think differently about software bugs, even in open source.

Bugs are normal. Get over it.

The good news with software is that everything is fixable because, well, it’s software. Ship a hardware widget, and you’re somewhat stuck. Ship a software widget, and it’s eminently fixable.

And buggy.

Yes, buggy. As Heinemeier Hansson, founder of Rails and a principal at Basecamp, puts it:

The only reliable, widely used way to ensure impeccable software quality is to write less software that does less stuff, and then spend eons honing that tiny lot. Such an approach, however, is very rarely compatible with commercial success or even programmer motivations (despite what many may claim).

While no one likes bugs, far fewer people like the alternative: feature-less software. As Heinemeier Hansson continues, “How do you think the market would receive the iPhone 7, if its headline improvement was cutting 1/3 of the features to shrink the code base so it’d have fewer bugs?”

This jibes with Coverity’s 2013 report, in which the authors found that open-source software delivers fewer bugs than proprietary software, but only for smaller projects. That is, the less code written, the fewer bugs. Hurray?

By the way, adding bodies to hunt down bugs doesn’t really solve the problem, either. If anything, more developers simply increases the odds of more bugs, which is why Amazon CEO Jeff Bezos has long insisted on a “two-pizza rule” for development teams. If the team requires more than two pizzas to feed it, it’s too big.

Open sourcing away the bugs

Despite the endless debates over open vs. closed software quality, open source has never really been about superior software; it’s really about a superior method for exposing and eradicating problems. If a company finds a bug in its proprietary code, no one but the vendor and the complaining customer knows about it, and fixes can take years.

In open source, by contrast, when a bug is spotted, fixes can be nearly immediate.

Except, of course, when they’re not. After all, there are still multitudinous cross-scripting bugs that plague open-source software. And no one will easily forget Heartbleed and other major open source whiffs, bugs hiding in plain sight for a long time with no one spotting or fixing them.

These aren’t arguments that disprove open source’s “shallow bugs” theory (“Given enough eyeballs, all bugs are shallow”). Just because users can view source code doesn’t mean that they will. It just means that once an alert is raised, getting to the code to fix it is much easier than in proprietary software.

Yet it’s still an open question whether that’s a good idea.

Do you really want a fix?

Here’s where Heinemeier Hansson is at his most provocative. Many bugs can remain buggy, as it were, and it’s “really the pinnacle of myopia when we as users demand and demean software makers to fix our pet bug, just because we hit it, and just because it may have caused anything from a slight annoyance to loss of some time,” Heinemeier Hansson intones. He goes on:

The value of any given bug can be rated by the number of users affected times the criticality of the issue. Lots of users are losing all their data due to this bug? Okay, then, Very Damn Important! Fix it NOW! Lots of users are a little annoyed or confused by this? Probably should fix it some time soon. A few users have to spend another 30 seconds on a work around? Unlikely to get fixed any time soon!

Software organizations that stay in business triage their backlog of bugs like that. They do not drop everything to deal with any damn bug. As the economies of scale kick in, so does the magnitude of consequences from such triaging. Large software packages and organizations will have hundreds if not thousands if not TENS OF THOUSANDS of open bugs of various criticality. THIS IS NORMAL. THIS IS EXPECTED.

Not all bugs are created equally, and some are more annoying than destructive. Deal with those, try to work around them, and move on. And, if the software happens to be open source, fix it yourself. This is a far healthier way to think about software, and its inevitable bugginess.