Section 5.3. Crafting a Strategy for Managing Open Source

5.3. Crafting a Strategy for Managing Open Source

Many CIOs and IT departments have yet to come to terms with open source and define their relationship to it. On the one hand, the press reports everyday about all sorts of companies saving a bundle with open source. Large players such as IBM and Novell are promoting open source projects and bundles that fit into their product strategy. Frequently the engineering and development staff is already using it to some extent. In many ways, the problem resembles the way that company web sites popped up spontaneously all over the Internet in the mid- to late 1990s.

The question we will address next is how that opportunity can be managed. What rules should govern progress toward greater adoption of open source in an organization? Which sorts of governance models are being used in which types of organizations?

5.3.1. Unique Challenges of Controlling Open Source Adoption

The vast potential of open source comes with a variety of risks that are not present in commercial software. To avoid uncoordinated chaos, these risks must be managed with some sort of governance structure or policy that prevents unmonitored and unauthorized use of open source. This governance structure is generally different from policies that are used to control other technology, for the following reasons:

• Open source is free of charge. Anybody can download an open source program and install it without paying a feeand often they do it without any checks and balances. This means the purchasing process cannot be used to control the acquisition of open source.

• Open source can be easy to install and get running. This makes it alluring for frustrated users or IT departments that want to do things for themselves. Striking out on your own without adequate operational skills, however, frequently leads to disaster.

• Open source is available for almost every need. This adds to the allure for those who want to go it alone, yet lack the proper skill level.

• Open source comes with source code. With the required skills, anyone can modify and customize open source software. Although commercial software also can be customized, the customizations that can be applied to open source software are limitless. This provides an unrestricted potential for creating key-person risk.

• Open source licensing has important and subtle implications. The most dangerous situation is to use open source as part of a commercial product, without thinking things through carefully. Many open source projects can be safely included in commercial projects through licenses designed for this purpose, such as the Lesser General Public License (LGPL), a version of the GPL that makes including open source libraries less restrictive. However, if developers are not careful, using open source in sloppy ways can result in an obligation to make an entire product open source. While this can be remedied by removing the open source, few companies want to have any such ugly surprises. The other issue with licensing involves careful handling of intellectual property issues when releasing software as open source. Only open source to which a company has clear title should be released.

• Employees can contribute to open source projects. Sometimes encouraged by the company, sometimes on their own, employees can lead or contribute to open source projects. When this happens on company time and using company resources, questions of intellectual property ownership, such as who owns what and whether permission has been properly granted, must be handled carefully.

5.3.2. Different Companies, Different Responses

The right response to these issues changes dramatically based on an organization's size and the way it uses open source. For most IT departments, the issue concerns controlling the introduction of open source to avoid such problems as expanding the required skill set without careful deliberation, or making sure projects are properly supported and within the department's skills to support.

At a small company, the task of open source governance can be assigned to an individual who approves the use of open source. The approval can be based on formal or informal standards according to the company's style. The next problem is to make sure everyone knows that this person must approve any use of open source. This is about all that is needed for your average IT department that is not developing any software products and does not intend to release anything as open source or participate in development.

In a large company, the governance procedures must be far more formal. One person is no longer a reliable stopgap, and instead, the job is performed by one or several committees. Informal methods will no longer suffice, and the company must create a policy for all the issues involved, including the following:

• When is it appropriate to use open source? For what purposes and in what contexts should open source be used?

• What must be demonstrated and documented to gain approval?

• Which open source licenses are acceptable?

• When and how should open source be used in product development?

• When can internally developed software be released as open source, if at all?

• How will the company support open source development?

• How many employees should participate in open source development?

The goal of policies designed to cover these issues is to prevent the negative side effects of using open source too liberally. The specific policies that are right for a particular company depend on many factors, including the type of business the company is in, its tolerance for risk, and so on.

Hewlett-Packard is one of the most advanced corporations in terms of its approach to open source. At http://opensource.hp.com/, you can see all the projects in which HP is participating. HP's Open Source Program Office uses an Open Source Policy Document and an Open Source Review Process to ensure compliance with corporate standards.

Enthusiastic adoption by large enterprises such as IBM, HP, and Amazon.comcompanies that are wary of undo risk exposureindicates that it is possible to manage the risks of open source, as long as a proactive and rigorous approach is taken.