Open source and Unreliability?

Statements to the effect that “open source software is unreliable” are disingenuous. With 120,000 software projects on SourceForge, it is pretty silly to make any generalizations about open source quality. One might just as well say that “all proprietary software is reliable,” although experience easily dismisses any such misconception. The reality is that most software (open source as well as proprietary) is of insufficiently high quality from the enduser’s perspective, and the current brouhaha is a case of the pot calling the kettle black.


Software products (both open source and proprietary) vary dramatically in their quality: a five-user open source project is a far cry from the Apache web server (running the majority of sites on the Internet). The quality argument that the proprietary vendors ought to be making about open source software (OSS) is rather that the hurdle to go from successful OSS project to widely-adopted enterprise product is a big one, requiring fault tolerance, security, integration, compliance, performance, scalability, usability, ease of configuration, ease of administration, and so on. Few open source projects (and few proprietary software projects, for that matter) ever get there.

But some open source software no doubt has―take Apache, Linux, and Firefox for example, each of which is defensibly ahead of its proprietary alternatives. In reaching such quality “critical mass”, open source is an asset rather than a hindrance!:

Scrutiny of the source code. To ensure software quality, there is nothing like the added developer accountability that results from the public scrutiny of (and commentary on) his/her code base. Products that pass muster are likely to have cleaner, more elegant internal architectures that will make them a far better long-term investment. (The reverse is also true―vendors of proprietary products often fear that open source will air their architectural dirty laundry, as much as they fear it will cannibalize their license revenues.)

Transparency of development and quality regimen. Open source projects/vendors are far more likely to open up their bug databases, provide open communication between developers and users (via forums), as well as to open their development, build and test regimen. By inviting users into the “sausage factory”, open source is at least welcoming greater participation and feedback.

What I don’t get is the argument by the proprietary camp that being open source is somehow a liability in the pursuit of software quality. Perhaps their rationale is really that open source is cheap enough that the associated quality assurance (QA) regimen must be inadequate. This is a gap that the commercial open source (not an oxymoron) vendors (e.g., Red Hat, MySQL, Zimbra, but also IBM and now Oracle) have as their raison d’etre, and I’d bet we spend a higher percentage of the associated revenues funding QA than is typical for proprietary software. Add in the greater open source community’s contribution to QA, and you can see why some open source solutions are quality leaders, not followers.

The net: software quality varies more between projects/products than it does within categories (OSS versus proprietary), so (1) do your own due diligence in order to ensure that the quality of the candidate software is sufficient for your needs; and (2) between comparable proprietary and open source alternatives, open source is the more likely to provide higher quality for your investment.

Comments are closed.