Six Options For Open-Source Support

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

Commercial software can be costly in more ways than one. As if hefty license fees weren't bad enough, product support is limited to whatever services the vendor agrees to sell you, at a price that's tough to negotiate. Of course, you could fix program bugs yourself if you had access to the source code—but the typical software maker doesn't provide this.

So how do you break the cycle of vendor dependency? One popular choice is to explore open-source alternatives.

Such nonproprietary software has key advantages. For one thing, it's free, at least insofar as no license fees are involved. Moreover, its source code is accessible to everyone, giving rise to a new class of support providers whose numbers are steadily growing.

Although enterprises are still in the early phases of adopting open source, the software is gaining ground. Fifty-six percent of companies used open source last year, up from 46% in 2004, according to a 2005 Forrester Research survey of more than 100 IT decision-makers in North America. The study further found that nearly 20% more were planning to use open source in 2005, compared with 14% a year earlier. And according to a separate report from Gartner, 95% of all Global 2000 organizations will have formal open-source acquisition and management strategies in place by 2008.

Despite their popularity, not all open-source initiatives originate with management. At many organizations, software-development teams pursue open source independently of the CIO and other IT leaders—and often without their knowledge.

With that in mind, CIOs would be well-advised not to buck the open-source trend. On the contrary, they should assume responsibility for open-source initiatives and ensure that their companies have the right support structures in place.

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.

    Building excellence in open-source support isn't about choosing just one of these options. Rather, it's about finding the best mix for an organization. No single solution can meet all the open-source needs of all organizations. CIOs should first investigate all the options, then evaluate the opportunities with their own requirements in mind.

    It makes a difference whether the enterprise is using the software for noncritical systems or in a production environment. As you move from the development phase to production, your support requirements will change.

    While this may sound obvious, organizations commonly make the mistake of treating all their support needs the same, regardless of the levels of risk involved. That's because CIOs are accustomed to working with commercial-software vendors that provide support from development to deployment and even beyond. But in the case of open source, access to both the code and an online community of users may obviate the need for vendor support during evaluation or development, assuming the technical capabilities are adequate to the task. Open-source support for these early phases tends to focus more on the learning curve, which may benefit some businesses.

    Once the open-source software moves from deployment to production, support requirements will closely resemble those of commercial software. The organization will want 24/7 coverage, service-level agreements, an escalation path for problems, and accountability.

    All things being equal, the greater the amount of risk involved, the more important it is to build solid support structures around the software. Whereas buying a support-insurance policy may be unnecessary for nonproduction systems, it may be a basic requirement for production-oriented ones.

    Support models will continue to evolve as open-source vendors strive to meet the requirements of corporate users. At the same time, users will gradually accept the new community model for software development.

    Building expertise in open source takes time. It also calls for a willingness on the part of CIOs to experiment with new models of doing business and managing resources. When open source is done right, however, its benefits can greatly outweigh its risks.

    Raven Zachary is a senior analyst and the open-source practice head at the 451 Group, which recently acquired his O*rev consultancy.

    What open-source support models has your organization explored? Tell us at [email protected].

    See Related Articles:
    Putting Open Source To Work, April 2005
    Highlights And Hits: Is Open-Source The Answer To High Software Costs? November 2005

    Open-source support needs will vary, depending on the type and purpose of the software your organization is using. You must also take future requirements into account when embarking on a support strategy. Here's how to get started.

    Month 1 > Audit current and future use of open source

  • Compile a list of all open-source software in use or under consideration. Even include software that staffers have been using without authorization.

  • Identify your internal leads for each open-source component and how support is currently provided. Name a point person for each component identified; learn how the software is supported, if at all.

  • Determine the ideal level of support for each open-source component, based on the software's importance to the business. For example, open-source software in production requires greater support than an open-source tool the development team is using.

    Month 2 > Devise a plan for open-source support

  • Talk with your organization's legal and purchasing departments about open-source software. Open-source use isn't just an IT-development issue. Your development team should work closely with your IT-operations team.

  • Develop an open-source support plan that includes clearly defined expectations. Explore all support options for each open-source component.

  • Review your budget to fund new initiatives. Supplemental support for existing open-source software will involve additional costs. Make sure new costs are captured; propose costs as new items for the next budget cycle.

  • Evaluate new open-source components as though you were evaluating commercial software, with selection criteria identified for support.

    Month 3 > Begin to roll out your plan

  • Record sources of community support for all open-source components.

  • Survey existing IT suppliers about their level of open-source expertise and opportunities for support. Evaluate additional open-source suppliers.

  • Create an RFP for open-source support, based on your audit and support plan. Distribute the RFP to providers, including existing IT suppliers and product- and stack-support specialists. Have your internal development and operations teams reply to the RFP as if they were outside suppliers.

  • Look at training and hiring capabilities to strengthen internal support.

    We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
    Comment  | 
    Print  | 
    More Insights
  • Copyright © 2021 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service