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.