Taming the Wild Open Source Implementation

By Bob Violino  |  Posted 2009-01-30

Open source deployments are becoming more pervasive as enterprise IT shops get more comfortable using the software. But open source can present challenges, and organizations would be wise to follow some best practices.

Clearly, open source has arrived as an enterprise IT strategy. A research report released by Gartner Inc. in November 2008 shows that adoption of open source software is becoming pervasive, with 85% of 274 worldwide companies surveyed by the Stamford, Conn., firm currently using open source and the remaining 15% expecting to in the next 12 months.

But the same survey shows that there’s a need for more discipline when it comes to implementing open source. Nearly 70% of the companies surveyed still have no formal policy for evaluating and cataloguing open source usage in their enterprise, Gartner says, opening up potential liabilities for intellectual-property violations.

The research firm says a lack of governance was the number one challenge for open source users in the survey, followed by conflicting terms and conditions and the availability of too many license types and forms.

Here are some recommended best practices that can help organizations launch successful open source deployments:

Create an open source policy that includes governance over how open source will be procured and used. Surely some departments and individuals will use open source software on their own, and companies will launch broader, enterprise use of some applications. Organizations need to have a formal policy in place to oversee how open source is being implemented and to measure its effectiveness.

It’s important to understand how open source is used in the organization, says Bernard Golden, CEO of Navica, a San Carlos, Calif., consulting firm that focuses on open source. “Is it solely used within the firewalls of the organization, is software distributed?” Golden says. “Understanding this is vital to ensure compliance with open source licenses. The quid pro quo for free software is expectation of license compliance.”

Part of the governance effort includes tracking and project management to identify when and where open source is used, Golden says. Organizations should consider creating an “open source review board” to examine requests to use open source within the company.

Select widely supported platforms. Choose open source applications that have rich support and a strong community, says Ray Wang, vice president and principal analyst at Forrester Research Inc. in Cambridge, Mass.

“The richness of the tool, support community, and the wide range of widgets and theme options are key criteria,” Wang says. With a strong community, “you'll get the benefits of a community ecosystem,” he says. “You can't pay enough money for that kind of level of support.”

Keep abreast of release changes. Open source software is constantly being revised for improvements—one of the benefits of the open model.

“The pace of innovation is much faster with open source projects,” Wang says. “Releases often follow agile methodologies with frequent updates from small but powerful teams. With so many releases and bug fixes in play, users should keep abreast of changes on a weekly basis, at a minimum.”

Understand that open source welcomes active participation. Again, part of the success of open source stems from the fact that the software is continually evolving based on input from users. “Contribute to the community as much as possible. The power of open source is with the community,” Wang says.

Managers need to recognize that open source is more self-service than traditional packaged software, Golden adds. “Employees willing to take an active approach to the technology rather than passively expecting the vendor to deliver a complete solution are crucial,” he says. “Assess the [ability] of employees to understand technical capability and [their] willingness to roll up their sleeves."

If you’re modifying open source code, engage with open source project leaders. If any changes are made in code, they should be submitted to the community for review in order to be included in the mainline code base, Golden says.

“Attempting to maintain a separate code tree inevitably leads to extra effort and decreased quality,” he says. For example, the organization will have to repeatedly reapply its changes to every code release if these are not included in the code base.

Golden says organizations can work with open source communities via mailing lists or forums. They can report bugs or make suggestions regarding product features. “This gets your organization's use cases and needs into the discussion about what to do with the product going forward,” he says.

If an organization needs extensions to a product, it should evaluate contracting for them with product maintainers or leaders within the community.