Back to article
Bring Order to Your Open Source
Building an Open Source Policy
July 5, 2007
As open source makes greater inroads within IT organizations, it's time for companies to get serious about creating policies and governance models around its use.
Thorough license reviews, for example, are a good idea, given the requirements of various reciprocal open source licenses that require community distribution of code modifications, or that include software patent restrictions around them.
Companies probably are using open source software more than they realize, experts say, even if they still tend to be selective about where they'll take advantage of it. They tend to impose stricter requirements around approving its use when it comes to mission critical or customer-facing applications, says Brian Fan, senior partner with business and strategy consulting firm Olliance Group.
For these applications, the availability of commercial support for open source components is critical, because companies fear problems that could have an impact on their brand or customer relationships and want to have SLAs in place with parties who can quickly resolve any issues.
Fan was one of three experts this week who shared their views on some of the key governance issues around open source.
Who needs an open source policy?
Everybody. Phil Robb, R&D section manager in HP's open source and linux organization, says his company probably uses and interacts with open source more than the average organization--internally as part of the corporate IT infrastructure, as a distributor, within its software, embedded in its hardware, and as an active member in open source communities.
"If you interact with it in any of those ways, you need a policy," he says.
What's the state of open source policy and governance adoption among organizations?
"We pretty much see companies are all over the map," says Fan, some of them with policies from the early part of the decade that need extensions, some with very onerous policies written by the legal department that aren't being followed by the engineers, and some in denial that open source is even in widespread use.
Whatever the state, "We recommend that companies not panic," he says. You can come up with a well thought-out, comprehensive policy that covers all kinds of issues and put in place a process to remediate existing open source in use into compliance with a new policy with a few months.
Who should be involved in development and oversight of policy?
The consensus seems to be to make sure there's cross-functional representation. At Great American Insurance Group, an enterprise architecture review counsel, a virtual group chaired by the chief architect, is composed of architects across functional areas in IT, says Mark A. Bunch, a senior front end architect who also serves as an enterprise architect involved in defining the acquisition, support and governance of open source in the organization.
"From our experience, for its success, it needs to be a very cross functional group of folks," concurs Robb. "A lot about using open source software, particularly in distribution models, is understanding the technical aspects of use, along with what the legal implications are over various licenses associated with those pieces."
HP has R&D, legal, IP licensing team, as well as QA-oriented and project management personnel involved.
How do you get compliance with governance requirements?
"If you have someone with a problem about this, bring them into the process," Robb advises, which HP did by bringing a rep from HP Labs into the compliance efforts.
The labs team had some difficulty in abiding by the processes in the beginning, but that's changed with someone now on the team who can appreciate both positions. Understanding and compliance of the labs for processes and policies around open source interaction and usage is much better, he says.