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 codebut 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 leadersand 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 supportand that's a drawback for CIOs. Only a small percentage of the more than 100,000 projects listed on the open-source hosting site SourceForge.net 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:
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.
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."
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.
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.
It's easy to find experts on open-source project mailing lists and team rosters. Also helpful are Internet resources such as FindOpenSourceSupport.com. 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
Month 2 > Devise a plan for open-source support
Month 3 > Begin to roll out your plan