Choosing the Right Type of Open Source Support

Open source software is used by organizations both large and small for everything from desktop applications to mission-critical infrastructure, but many enterprises have inconsistent open source support coverage or lack technical support altogether. Just as most companies won’t use commercial software without technical support coverage, it’s important to evaluate technical support needs and options for any open source used in the enterprise. For some companies it makes sense to rely on internal expertise for open source support, while others require commercial-grade support coverage for some or all of the open source software they use.

In this post I’ll outline the key issues you should consider when evaluating support options for the open source deployed in your organization. I’ll also link to a resource that can help you work through the pros and cons of each option.

Supporting Open Source with Internal Expertise

It’s not uncommon for enterprises to rely on internal expertise for open source support, especially when open source is first introduced to the organization. After all, it’s usually an organization’s developers or IT staff who first bring open source into the company, and it often makes sense for those same individuals to support the technology they want to use on the job. In this situation, the internal support team typically utilizes open source community forums and mailing lists to help troubleshoot and resolve problems.

This approach to open source support may be appropriate for smaller organizations, companies in early adoption phases, non-critical open source deployments, and companies with extremely tight budgets. However, as open source becomes a bigger and more critical part of development and/or IT infrastructure, organizations need to move beyond internal expertise and treat open source support the same as commercial software.

Some of the key issues you need to consider when evaluating this option are:

• Project Maturity – Is the project community large, does it respond to questions in a timely fashion, and is documentation available?

• Nature of the Deployment – Is the open source package used in mission-critical applications? How long can you wait for help if problems arise?

• Frequency and Nature of Issues – How often do you expect issues to arise, and how complicated might they be? Will you ever need support outside of normal business hours?

• Staff Time and Expertise - How much experience does your staff have with the software? Do they have time to spend resolving support issues?

• Privacy - If an employee posts a question on a community forum, are you at risk of disclosing confidential information? Is there a policy against this?

• Bug Fixes - Should you encounter a bug in the open source package, are your personnel capable of creating and submitting a fix to the community?

Component-Level Support for Open Source

Component-level support contracts are typically purchased to cover open source used in mission-critical infrastructure or applications, or to “fill expertise gaps” when personnel lack the time or expertise necessary to support particular packages. This option is often a good fit for organizations that are just beginning to use an open source package and have limited expertise. Organizations also may purchase component-level support after relying on internal expertise during initial phases of testing and experimentation.

Component-level support offers enterprises the flexibility to mix commercial-grade support for some packages while relying on internal support for others. It also allows organizations to scale coverage levels as needs evolve. However, “one-off” open source support contracts like this typically cost more on a per-package basis than contracts covering multiple packages, and may also be limited in scope when it comes to integration issues.

Some of the key issues you need to consider when evaluating this option are:

• Open Source Experience – How broad is the support provider’s experience with open source software?

• Community Involvement – Is the support provider involved with the open source community behind the package? Has it contributed code or patches to the community?

• Indemnification – Does the provider offer indemnification coverage for the open source it supports? What are the limits and remedies?

• Cost – How much does support cost? How many incidents are included in the contract? Are there limitations? How does this compare to other providers?

• Versions – Which versions of the package are supported, and how often does the provider “sunset” coverage for older versions? Will you be forced to upgrade in the future in order to maintain coverage?

• Integration – If the open source package is used in conjunction with other software, will the provider fully troubleshoot issues related to the integration or blame the problem on other applications?

Aggregated Open Source Support Coverage

Aggregated support contracts are ideal for organizations that use multiple open source packages and don’t want to tie up internal resources with support issues. By purchasing support from a single provider for multiple open source packages, enterprises can often simplify internal procurement and help desk procedures. In addition, aggregated coverage is likely to be cheaper than purchasing multiple component-level support contracts from a variety of providers.

In addition to the issues highlighted above for component-level providers, the following issues should be considered when evaluating an aggregated support contract for multiple open source packages:

• Number of Packages Supported – Does the provider offer support for only a few specific packages or a broad range of open source software?

• New Packages – If you begin using additional open source, will the provider be able to extend coverage to those packages? Can it extend support coverage for open source packages not currently on its list?

• Other Services – Does the provider offer complimentary open source services that may be required in the future? What are the costs of those services?

Summary

The right type of support for your organization depends on many different factors, and your open source support needs will almost certainly vary over time. Open source packages – and companies’ open source usage models – can change rapidly, so it’s worth re-evaluating your support options on an annual basis.

For a deeper look at the issues to consider for each of the open source support models, take a look at our Open Source Support Evaluation Kit. This free resource provides additional detail on the key issues outlined above and also includes a worksheet to help you work through the questions and costs you need to evaluate.



Follow @openlogic
Follow @gbellcolorado
Subscribe to The Enterprise Open Source Blog by Email

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.