Six Options For Open-Source Support - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Enterprise Applications
01:48 PM

Six Options For Open-Source Support

Companies are turning to open-source software as an alternative to vendor lock-in.

They'll find the more mature an open-source software project, the more mature support options its users enjoy. For example, organizations can obtain support services for JBoss, an open-source application server, from JBoss Inc.; and Covalent Technologies offers support for Apache, a popular open-source Web server. In addition, successful open-source projects have large, active user communities that provide assistance.

However, not all open source projects can boast abundant support—and that's a drawback for CIOs. Only a small percentage of the more than 100,000 projects listed on the open-source hosting site have both mature support options and an active community of users. In fact, just 1.7% of those projects are considered mature, reports Michael Bergman, CTO and co-founder of BrightPlanet Corp., in a recent blog entry.

Deciding which open-source support options are best depends on a number of factors, including which open-source software the organization uses, how it's used, and what the organization's own software-support capabilities are.

To make a good decision, consider the following six choices:

  • Product support. Some mature projects receive support from open-source vendors such as JBoss and Laszlo, which make their money through the services they provide. Such vendor-backed projects still may be thought of as open-source products.

    Under this "professional open source" model, as JBoss calls it, the user organization enters into separate agreements with its various vendors. The agreements differ with respect to the specific software involved, the service levels available, and the cost of support. As a result, the more complex the mix of open-source products, the more intricate the support matrix becomes. The user company is responsible for integrating the disparate components, as well as for resolving compatibility problems that may arise.

    On the plus side, open-source vendors often provide better support than commercial ones. Unlike traditional vendors, they typically offer customers direct access to their development teams, which frequently include members of the original development project. These teams can make changes to the project's source code as needed.

  • Stack support. A new wave of companies, known collectively as open-source stack providers, has emerged to address the problem of integrating and supporting multiple open-source software components in a single organization. Stack providers assemble sets, or stacks, of commonly used open-source software components and offer services around them, including support and integration testing.

    Specialized stack providers include OpenLogic, SourceLabs, and SpikeSource. Several well-known commercial vendors, including Hewlett-Packard and Novell, are building similar open-source offerings. "We provide a safe sandbox for the CIO while still giving developers the benefit of open source," says Anders Tjernlund, VP of support services at SpikeSource.

    For businesses planning to use a common set of open-source software components, working with a stack provider may fit their needs. But beware: Most of these providers support only the most popular components.

    In addition, stack providers usually aren't as knowledgeable about the software as open-source vendors themselves. Because of this, some partner with vendors to offer customers greater expertise. This can be a good compromise.

    Another limitation of stack providers is that they can't employ members of all the open-source project teams. As a result, they must coordinate potential code changes with the various teams as problems are discovered, as opposed to making the changes directly.

    These and other trade-offs have deterred some CIOs from opting for a "single throat to choke" approach to open-source support.

    "If the throat is that big, it's hard to get your hands around it," says Alan Boyer, CIO of Home Interiors International, a direct seller of home-décor products.

    "I don't want to choke anybody," adds Mitch Greenwald, CIO of staffing provider SeatonCorp. "I just want [the software] to work."

  • Community support. Successful open-source initiatives spawn active online communities that offer multiple means of support. These include mailing lists, discussion forums, even direct E-mail correspondence with open-source project developers. But for community support to be effective, an organization must feel a strong sense of internal ownership.

    CIOs mustn't confuse community support with free support. Any company that relies completely on community support is essentially taking support matters into its own hands. A more prudent company will also have internal experts who can be held responsible for systems and escalation paths should problems arise. These internal experts should become user participants in the software's larger online community.

    Unlike a commercial software vendor, an open-source community won't give users preferential treatment based on their enterprise's size. That means the CIO of a Fortune 100 company will receive the same level of support as the CIO of a small nonprofit. Similarly, a posting from a team at a major corporation won't automatically take priority, even if it relates to a critical production failure. The upshot: If you're looking to an open-source community for support, you'll need some patience.

  • Training. While open source demands a large measure of self-reliance, it doesn't necessarily require you to add technical staff. Instead, the enterprise can train existing technicians to work with the software. With IT budgets being cut and opportunities for training drying up, such a move could improve employee morale by providing new avenues for growth. Training is available from an increasing number of companies, including Covalent, JBoss, and LearningPatterns.

  • Hiring project developers. Some organizations that depend on open-source software hire full-time open-source project-development consultants as team members. Adding specialized staffers gives the organization its own in-house experts and a greater capacity for self-support. Also, having those project developers on hand lets the organization make direct changes to the source code.

    This approach has its limitations, however. First, the issue of customer influence over an open-source project must be treated with great sensitivity, as the community may perceive the involvement to be promoting self-interest over what's best for the project. Second, hiring open-source project developers requires financial resources that relatively few companies possess. Finally, this model won't scale well as open source proliferates, and the demand for project developers will outpace the availability of talent.

  • Using consultants. Consultants are a viable option for organizations that either can't hire open-source specialists, don't have time for in-house training, or don't need a professional-support agreement.

    It's easy to find experts on open-source project mailing lists and team rosters. Also helpful are Internet resources such as Launched in 2004, this Web site lists more than 500 open-source consultants and providers.

    It's best to use consultants transitionally, as they may be costlier and less committed than regular employees over the long term. Gradually, they can train the internal team, then remain on call as needed.

    We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
    2 of 4
    Comment  | 
    Print  | 
    More Insights
  • InformationWeek Is Getting an Upgrade!

    Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

    Remote Work Tops SF, NYC for Most High-Paying Job Openings
    Jessica Davis, Senior Editor, Enterprise Apps,  7/20/2021
    Blockchain Gets Real Across Industries
    Lisa Morgan, Freelance Writer,  7/22/2021
    Seeking a Competitive Edge vs. Chasing Savings in the Cloud
    Joao-Pierre S. Ruth, Senior Writer,  7/19/2021
    White Papers
    Register for InformationWeek Newsletters
    Current Issue
    Monitoring Critical Cloud Workloads Report
    In this report, our experts will discuss how to advance your ability to monitor critical workloads as they move about the various cloud platforms in your company.
    Flash Poll