Open Source Reliability and Support

When evaluating an open source technology for use in the enterprise, a critical question you must ask, especially if you are new to using open source in a business-critical application, is “How do I know I can rely on it?”

For proprietary commercial software, the vendor will invariably do all it can to represent the product as the most rock-solid piece of technology ever developed, extol the desire of their support organization to bend over backwards to fix your problems the day before they arise. These things may or may not be true, and how you evaluate the vendor’s claims in these areas will greatly impact how you make your decision. You will probably rely on industry reputation, check customer references, look at the company’s history and track record in the press, perhaps start with a pilot implementation.

In the open source world, many of these same techniques for evaluation apply, but they may not be the ones you start with. For example, you may want to first characterize the type(s) of support available to you for the technology you’re looking at – professional open source, stack solutions provider, community support, training, hiring developers, relying on consultants, etc. You also take a look at the community surrounding the technology – if email lists, online documentation, forums, FAQs, etc. look useful, responsive, and have a diversity of participants, that’s a good sign. After all, one of many motivations behind adopting an open source solution might be to give yourself support alternatives if your primary support vendor cannot come through for you. You can also review the release history of the product and evaluate the types and frequency of releases. The transparent nature of open source will allow you to read the product release notes and obtain a clear, unbiased sense of the maturity and reliability of the technology, as well as how responsible the developers are about addressing issues and bugs.

Evaluating the vendor(s) providing services related to the technology is of course also important. These companies may be professional open source firms dedicated to supporting the specific product, a stack solutions provider offering more generalized support for the components the product runs on, or other training/service providers. Here you can apply most of the same techniques you would use with a proprietary software vendor. Finally, you can evaluate the ‘in-house’ and/or consultant-based support options – how you evaluate this will vary depending on the technology and the makeup of your organization.

Does this create more work and more complexity? Yes and no. The benefit is that you will have much greater transparency early in the process into the workings of both the technology itself and the community organized around the techology. These are excellent indicators of whether the solution will be a good fit for you, and may allow you to pare your list of options earlier that you would otherwise. The extra complexity may lay in the fact that this part of the evaluation process occurs before you ever have contact with the vendor’s sales team, so you’ll be relying on your own initiative to navigate the evaluation path. However, with just a little savvy, you should see this effort bear fruit rather quickly.

Open Source and Security

The impact of the open source model on security is an oft-studied topic. Rather than try to add anything new, I wish to point out some helpful references and try to address a couple of common misconceptions I have encountered in the clinical trial software and enterprise IT communities.

First of all, using an open source application, database, server, etc. DOES NOT mean that your data is accessible to anyone who tries to access it! Astonishingly, this is a fairly common misconception for people who only have a casual understanding of what open source software is. In fact, open source software powers some of the most secure software systems on the planet that require highly regulated, very fine-grained control over which users can access certain data.

Security in open source software is based on a rejection of the “security through obscurity” concept, and instead relies on an approach far closer to the centuries-old scientific model of peer review. From the beginning of a project, open source developers understand that their code is going to be subject to review and critique by a potentially large community. Rather than simply making vulnerabilities hard to find, open source developers have to rely on sound architecture and design principles. System access privileges, user authentication rights, and encryption features cannot easily hide “back doors” and each programmer is motivated to not only produce code that will pass a test suite, but produce code that will stand up to the (often severe) scrutiny of their peers and users. In this fundamental way the open source model has been proven to result in more secure solutions than a closed-source, proprietary development model.

This is not to say you cannot find counter-examples! Of course, any specific technology, open source or not, should be evaluated against your particular security criteria. For further information on this topic, check out David Wheeler’s reasoned, in-depth discussion of open source and security here.