These days we can assume that most large enterprises have some sort of open source software presence in the data center. Whether it is racks full of Linux servers, a few contrasting Linux instances, or even just Apache running on Windows, open source is prevalent. So what happens when you need help with open source software? Not just simple configuration issues but problems like, “it doesn’t work as documented” and true bugs that bite. There are options, but are they worth it?
First, let me clarify. Commercial (closed source) software support is neither better nor worse. The open source “community,” a.k.a. forums and mailing lists, is credited for much of the strength of open source. This is true, but today we’re going to explore professional support organizations and their promises. A mailing list isn’t too useful when your mission critical server is down through no fault of your own. Often you will find answers to error messages and common mistakes, but all too often it turns out to be a bug that you must somehow work around.
It is very unlikely you will be able to commission the developers to release an update immediately when you discover a bug, so you must mitigate the situation yourself. There are multiple approaches when users encounter a bug in open source software, including:
- Try another version, which often requires accompanying libraries to be updated
- Try on another server, perhaps a different Linux distro
- Try to compile your own version from the latest official release
- Continue searching Google, hoping that someone with the same problem has found a solution already
There are certainly more issues than “bug which cannot be worked around,” but let’s stick with that support issue at the moment.
With open source software, support usually involves some challenging problems. That is not to say that commercial software users are somehow less sophisticated, nor that commercial software is more stable. Software that comes bundled as a complete solution, for example with its own version of the JRE, does tend to run more reliably. It’s just one less thing to go wrong, if for example the admins decide to update the distribution’s supported JRE. There will always be other compatibility issues to deal with, but both closed and open source software distributors can work around the most common pain points by including as much as possible with their product.
Many people disagree with that philosophy. This “including glue” idea tends to prevail in the commercial industry, but open source (community-only kinds) tend to rely on the Linux distributions to get the dependencies correct. This has opened a market for the software support companies.
Matt Asay of news.com points out that the support lines for closed-source software get used quite differently than those in the open source business. In short, closed source customers tend to heavily use support channels during the installation and setup phase of a software deployment, whereas open source support is more heavily used to request features, report bugs, and customize the application for better integration. Some may say this sounds like the open source customers enjoy tinkering and are shoehorning software where it does not belong. While this is the case in some circumstances, it’s more the exception than the rule. It is true that open source software tends to be more versatile, and customers do find very interesting ways of applying the technologies.
The true need for open source software support, therefore, is reliability. Integration, scaling, customization, bugs, etc are all important support needs, but when it comes down to it, the key concern is reliability. Companies need to know that seemingly unrelated changes will not affect their production services. They need to be able to point fingers and find resolutions quickly, without relying on their own overworked staff to provide elaborate mitigation strategies.
Therein lays the niche. A few companies have dedicated themselves to providing solutions to common problems. Taking it one step beyond Red Hat Enterprise Linux, as the easy example, these companies support specific software stacks. This enables them to focus on the intermingled reliance a few pieces of software have in common, rather than dealing with an entire operating system. As an example, not an attempted comprehensive list, both SourceLabs and OpenLogic have adopted this business model.
SourceLabs provides an open source Java middleware platform, called SASH. It includes Spring, Axis, Struts, Hibernate and Tomcat, with accompanying support. Relevant patches and dependencies are provided in a guaranteed-to-work package. SourceLabs offers support and frequent tested and certified updates for their SASH framework. This is a wonderful example of the packaged solution, which may otherwise be tricky to maintain should you choose to go it alone.
OpenLogic on the other hand, supports a LAMP stack, development tools, Java services, and tons of other applications. Their model is more akin to what most of us think about when talking about “support.” OpenLogic provides 24×7 call centers, which can assist you with any related issues. They also offer Developer Support, which is essentially consulting and best practices tutoring. Finally, OpenLogic also provides hundreds of certified and tested open source package that you can install safe in the knowledge that support isn’t far away.
Open source software is no longer the journey into the unknown it used to be. The main Linux distributions have become much better in the last decade, and the mission critical applications can be backed via numerous support options. Issues with open source adoption remain, but the two mentioned companies can address most concerns easily, so be sure not to dismiss open source software too quickly: you’ll be missing out.
