On the Quality Control of Open Source

I love open source software.

I mean, how cool is it that an individual person or a group of like-passioned people are able to write and publish software for worldwide public consumption? Oft times this software is simply given away to anyone willing to take the plunge, and there’s quite a bit of open source “stuff” that I use on a daily basis. In fact, this blog is powered by one of the world’s most popular open source blogging platforms. The open source software (OSS) movement is powerful to say the least.

There are certainly differing levels of OSS available around the web. Some versions are clearly aimed at the technical/geek/developer/adventurous type of user. This software tends to be buggy, under constant development, and often requires users to poke around the source, recompile, and–on some level–make it better. I totally understand running this type of software, and it can prove extremely useful for the people who have the know how to make it do its thing.

But another continually growing category of OSS is that of “consumer-friendly” products. WordPress is a great example of this. With barely any technical expertise (especially if you have a great web hosting provider or use wordpress.com), anyone anywhere can set up their own blog or WordPress-powered website for free and in a matter of minutes. WordPress goes through extensive testing before each version is released into the public, and even though the “techies” can still get the latest cutting edge development code, end-users generally end up receiving a solid and stable product. That’s not to say that it’s perfect, since there are always minor bugs found after release, but this is true of 100% of software on the market whether it be open source or not.

This, unfortunately, isn’t the case with every open source product released and advertised to the mainstream public.

When consumers purchase a software package from a company such as Microsoft, Adobe, or Intuit, they expect the product to be thoroughly tested and free of major bugs. They feel that they deserve quality because they paid good money for the package–and they’re right! Commercial enterprises must hire teams of quality assurance personnel to test, break, and re-test the software it makes to ensure (as much as possible) that it is free from errors.

So, when it comes to open source products, should end-users expect the same level of quality control?

I believe–quite firmly–that the answer is (mostly) yes. The cornerstone of software development in any scenario is making sure that the end-result is usable by your target audience. In fact, I would submit that anyone writing any type of software meant for public consumption should be absolutely dedicated to producing the finest quality product possible. This entails excellent software architecture, engineering, and testing at every step along the way. If the developer isn’t fully committed to producing quality code that is free from errors, then they shouldn’t be writing software in the first place.

Yup, you read correctly. If you’re not willing to put in the time and effort to produce a quality product, then get out of the business. Period.

Want an example of an open source project that needs to get it’s quality control act together? Look no further than Pidgin, a popular open source instant messaging client allows users to combine all of their IM accounts in a unified window. Last week, the developers released version 2.7 (a major update) into the wild without catching a major bug in the Windows version of the software. This bug prevented users from being properly notified (via flashing of the icon in the taskbar) each time a new message arrived. A bug report was filed, a developer responded relatively quickly, and within a day or so a patch was released to those people watching one particular bug report entry. But even after 72 hours of the patch release, no official notices were posted to the main website and no fix was applied to the installer that thousands of users are downloading every day. The official word on the subject was “we’ll release the fix in 2.7.1–whenever we get around to releasing that.” I don’t know about you, but lack of notification upon receiving an IM is a pretty important feature to fail to test. In fact, at time of this writing, I don’t think an official bug fix has been released!

This, my friends, is quite the poor example of good quality control.

While most open source developers have day jobs and aren’t earning any significant amount of money for developing code like that of Pidgin, they’re still entering into a contract with customers to provide a quality product–at least, to some extent. I believe this goes back to the mantra of “do no harm.” Developers must ensure that their software doesn’t affect the user in averse ways. Of course, there’s always the license agreement that comes with open source software stating that it’s provided as-is and under no warranty, but the point I made earlier still stands. Don’t release software without making it worth using!

So what do you think? Should free open source get the same level of attention and quality control as the commercial stuff? Or should we expect to live with unpolished software because hey, we’re getting something for nothing?

Posted in Software Tagged with: , , ,