"Open source has revolutionized the IT industry, both from the vendor perspective and the user perspective. What that means is that a lot of the assumptions that IT has about the way to do projects and work with vendors really need to be reexamined...How do you find the things you traditionally got from vendors in what I call this "unbundled" world?"

Bernard Golden, CEO of Navica

Open Source Software (OSS) has permeated the enterprise. Some organizations still prohibit the use of OSS altogether, but they are unquestionably in the minority. For most companies, it's not a question of "should we use OSS?" but rather, "how and where can we best take advantage of open source solutions?"

As companies have shifted from prohibiting OSS use to embracing it, they must now deal with technical support issues. This article examines the various option available to support companies that use OSS.

Support Requirements

When it comes to support, OSS is no different than proprietary software as the burden of supporting any software falls squarely on the Information Technology (IT) team. The question to the IT team becomes how to best support the OSS in use. Possible options include taking advantage of mailing list support, creating an internal support capability, engaging a consultant, or using a commercial open source support provider.

At the enterprise level, the expense of proprietary software support and maintenance, typically an additional 15% to 25% of the annual licensing fee, is assumed and factored into the cost of the software. In contrast, one of the more compelling benefits of OSS has been the user's ability to obtain support directly from the development community. In other words, free software and free support, straight from the individuals who develop the software.

Mailing list support, however, requires in-house resources to: (i) identify, define, and communicate a problem in a way that it can be answered by mailing list participants; (ii) recognize whether or not an answer is accurate and implement accurate answers received; and (iii) document the implementation. It also assumes that any answers provided from the OSS developer community will be timely. Mailing lists can be very fast and helpful, but there are no guarantees.

As OSS spreads into broader enterprise usage, the bar for support gets higher. OSS components are often used in mission critical production applications requiring a high level of support, typically 24x7 coverage with well defined Service Level Agreements (SLAs). When you take into account the number of OSS components that are typically used, including the components they depend on, it's not always practical or cost-effective for a company to seek support directly from the developer community.

Enterprises often have several critical requirements for OSS support, including:

• SLAs providing 24x7 support coverage with fast response times to address production issues
• Access to experts for the OSS in use
• System-level expertise to help troubleshoot and resolve problems in mixed source production applications comprised of multiple open source components, custom code and commercial solutions
• Support for older versions due to a reluctance to upgrade production systems to the latest release of an OSS component
• Anonymity regarding the type of software in use and any associated problems
• Necessary fixes are contributed back to the OSS project for inclusion in new releases
• Cost-effective support and the ability to shop for the best service at the best price

Support Options

Support usually means that there is someone who is responsible for resolving problems with the software. Support equates to reduced downtime and higher productivity. A traditional support agreement gives an IT department access to a team of professionals who troubleshoot problems, resolve issues, and provide software updates and bug fixes.

Four options for OSS support exist. The first option is referred to as mailing list support. This option can take the form of posting questions to user forums or browsing Frequently Asked Questions (FAQs) and knowledge bases. The advantages of this option are: (i) it contacts the developers who have contributed to the OSS project, and (ii) it is usually available at no cost. The limitations of mailing list support include:

• There are no SLA guarantees
• Once a problem starts to go beyond the boundaries of that specific OSS package and includes other OSS, custom code or commercial software, the source of the problem becomes more difficult to pinpoint
• The time-sensitive nature of an organization's IT problems makes enterprises reluctant to seek aid from sources unable to dedicate continuous resources until the problem is solved
• Mailing lists may not properly address the confidentiality concerns of large enterprises

The second option for OSS support is hiring one or two of the community's experts as employees or contract workers. Most OSS developers hold software jobs and enjoy being paid to work on their favourite project. However, this is not a scalable solution; hiring a person for every open source project you use, when you use dozens or hundreds of them, is not feasible. Also, many successful OSS projects have fewer than 10 developers, so an expert isn't always available for hire.

The third option is commercial support for individual OSS packages. One of the prevailing questions for developers of OSS is "how do we make money?" and the answer is often "consulting." Typically, developers of OSS form companies that provide training, documentation, customization, and technical support. The support is generally excellent, assuming that the developers have the skills to provide support in addition to developing software. As with proprietary software support, it can be available on an incident-based price schedule or by subscription.

The downside for IT departments is dealing with many individual support providers, as many as one vendor for each OSS project. Moreover, critical issues frequently involve the integration of multiple components and systems which the project developers may not have the expertise to resolve.

The fourth option for OSS support is consolidated commercial OSS support. This new support model has emerged in recent years to provide umbrella coverage for the multiple OSS packages that a company uses. The support is typically available by a subscription contract with the level of support and speed of turnaround determining the price.

With some suppliers, support is limited to a specific stack of software projects, such as LAMP technologies and their supporting components. Other companies offer more extensive coverage. OpenLogic offers support for any of the 330-plus software projects that can be downloaded from its certified library, and extends the support to customized versions of the software. Companies offering this type of support will typically pay OSS committers and contributors to help resolve issues.

The advantage to enterprise-level companies is clear: around-the-clock quality support is available from a single vendor, regardless of the issue. Another advantage is that support aggregators often have deep experience in many projects and can help with integration issues between OSS packages as well as home grown or commercial projects.

Typical Enterprise Support Problems

In an ideal world, every IT department would have a custom support plan tailored to its specific needs. But if an OSS support provider is to be profitable, it needs to craft a menu of solutions that can be delivered to a wide range of customers. This is not a simple proposition as the typical support problems of an enterprise level company vary widely.

OpenLogic's experience, after working with many enterprise customers, is that fewer than 10% of support issues involve software defects. Most support issues are questions, ranging from a list of simple "how-to"s to complex troubleshooting. Common customer problems revolve around configuration, integration, and performance concerns. The following examples come from OpenLogic and demonstrate the types of support issues enterprises encounter.

A production team in a Fortune 1000 organization needed to deploy a complex security process using an implementation of mod_ssl for Apache. The deployment was scheduled for off-hours and needed to be finished before the beginning of the next work day. It was close to midnight, and the deployment was not proceeding as planned. Within an hour of calling, the issue had been escalated to OpenLogic's support team; OpenLogic also tapped its "Expert Community", a group of dedicated contributors and committers to OSS projects. In this case, Covalent Technologies worked with OpenLogic to resolve the issue. Fifteen minutes of troubleshooting revealed the problem: the proper authentication keys were located on a key store server that was on an unavailable network layer. The problem was complicated by the fact that the company was using a customized version of Apache. Work continued and the customer was able to implement a new, reengineered process without experiencing any downtime.

Another example highlights that it's not always convenient or practical for companies to upgrade production software in order to get critical bug fixes. One customer sought a resolution that wouldn't force a continual upgrade cycle. The OpenLogic team settled on porting fixes back to the customer's older version of the software and was able to provide a certified patch within 12 hours.

In the fast-paced financial services industry, IT teams can gain advantages from the flexibility and lower costs of using OSS. But most production applications in financial services incorporate OSS, custom code, and traditional proprietary software. In one case, a customer was on a deadline to upgrade a system that incorporated Hibernate, an open source persistence and query service, along with BEA WebLogic, IBM's DB2, and custom code. An upgrade of DB2 was causing significant performance problems which the customer suspected were caused by Hibernate. OpenLogic worked with the customer to define a set of test scenarios to pinpoint the source of the slowdown. OpenLogic was able to rule out Hibernate as the cause and eventually determined that DB2 logging capabilities had been left on, causing the slowdown.

Making Sense of the Choices

Open source has always been valued for its promise of freedom to: (i) choose the best software and (ii) modify the software as needed. In addition, OSS enables companies the freedom to choose the best support option and provider for their needs. This creates a competitive marketplace for OSS support. Providing a wide range of support options makes it easier for enterprises to use OSS with confidence, but sizing up the choices can be confusing. Before making a decision, an IT department should ask support providers the following questions:

• Which OSS packages are supported?
• Can all packages in use be supported?
• On which operating systems, database, and configurations are they supported?
• Who exactly will be involved in providing the support?
• Is integration with custom or proprietary applications supported?
• Will I need to upgrade to take advantage of fixes?
• Will fixes be contributed back to the OSS project or will I be on a forked version?
• How much will support cost?

If you use OSS or are contemplating its use, the answers to the questions above can help you select the best option to support OSS.

The Future

As more enterprise IT departments experiment with OSS, we can expect to see continued changes in the types of OSS support available. Currently more businesses can benefit from the use of OSS. In this competitive support marketplace, companies now have the freedom to choose the support option that provides the best, most cost-effective service.