Earlier this month I had the opportunity to work with Adam Cohn, Senior Corporate Counsel at Cisco Systems, to present a session on "Effective Open Source Development Business Practices" at the Practicing Law Institute's Open Source session on Free Software 2009: Benefits, Risks and Challenges in Today's Economic Environment. With companies of all types and sizes becoming familiar with and using open source software, creation and implementation of open source policies was a focus of our talk.
The structure and contents of an open source policy, as with any company policy, must be tailored to the particular needs of the company. As a result, this post does not focus on the specific contents of a policy (but see this article by Stormy Peters, Executive Director of the GNOME Foundation, with a "how to" on open source policies, including ideas on specific topics to cover within such policies). Instead it targets initial considerations in defining the term "policy," determining whether you need a policy, how open source fits into your risk profile, and if and how open source fits into your business strategy. Next, it offers tips on how to align your policy with your business strategy for maximum effect.
(Note: The content in this post is based on the PLI presentation, but are mine alone and do not necessarily represent the views of Adam, my co-presenter, or our respective employers.)
Initial Considerations
What does "policy" mean?
The term "policy" will have different meanings between companies, between departments within companies, and between individuals within companies. As a result, as you undertake the exercise of determining whether you need a policy and implementing the agreed upon policy, ensure everyone involved has a clear understanding of the meaning of "policy." For example, policies are implemented for a number of different purposes from minimizing operational risk (such as a manufacturing quality check process) to satisfying legal obligations (such as financial policies in support of Sarbanes-Oxley reporting obligations). Looking at this another way, a policy could be something as simple as a set of operational actions, a more complex set of review and approval guidelines, or a vision statement on what open source means to the company. Often, a "policy" will address many of these needs at once.
Do you need a policy?
Not everyone needs a true policy, and even when a policy is necessary, it should be tailored to address the particular needs of a company. Start by identifying the specific problems you are trying to solve, which might span from telling staff that open source software should not be used at all, to implementing robust processes to both use open source in product development and distribute software under an open source license. Also determine whether a separate, standalone policy is needed. You might be able to address the problems you identify through minor updates to existing policies, such as policies on use of intellectual property or review and approval procedures for product development and distribution.
What is your risk profile?
By identifying the risks your policy should address, you will be better able to make your policy meaningful. For example, your company might have a particular sensitivity to one of the following types of risks: (a) fear that use of open source, along with related review and approval procedures, will result in the inefficient use of resource as compared to the perceived benefit; (b) fear of lack of warranty or infringement indemnity; (c) lack of understanding of community needs and dynamics; and (d) lack of understanding on customer concerns and expectations concerning your use of open source. Companies that use open source sparingly for internal purposes alone might view (a) and (b) as bigger risks than (c) and (d) and should adjust their policies accordingly. By contrast, companies that are not involved in open source communities and that frequently distribute closed source products containing open source components might be more concerned about (c) and (d), and they would have different policy needs.
How does open source fit into your business strategy?
As with risk profile assessment, companies must also identify how open source fits into its business goals and adjust its use of open source and related policies accordingly. The results of a year-old Gartner survey indicate that virtually all technology companies use open source software. But, mere use of open source software alone likely should not be deemed an open source business strategy. By contrast, frequent use of open source for revenue generating purposes almost certainly constitutes an open source business strategy. Consider the following broad guidelines for when a business strategy might warrant a robust open source policy:
- Minor policy should be considered: (a) Incidental use of open source in product development; (b) Use of open source in development for internal use
- Robust policy could be helpful: (a) Frequent inbound use of open source in product development; (b) Participation in open source community projects; (c) Sponsoring an open source community
- Policy is strongly recommended: (a) Open source development tools with proprietary “crown jewels”; (b) Services business for a community project; (c) Dual license strategy
Aligning Your Policy With Your Business Strategy
Policies are often designed primarily to address risks or satisfy legal obligations. By contrast, strategies are used to indicate a companies goals to be achieved over a particular time. Policies and strategies cannot exist in a vacuum, and each depends on the other. Policies cannot be narrowly tailored to address important risks unless a strategy exists to help prioritize those risks. Similarly, strategies will not be successful unless proper policies are in place to assist in effective implementation and avoid or mitigate risks. As a result, companies should make alignment of open source policies and strategies a high priority.
Once a company explores the "Initial Questions" identified above, it should consider the following recommended actions to check for compatibility and identify areas where additional consideration is needed:
- Determine whether an operational "how to" guide is sufficient, or is a vision statement appropriate. A hybrid approach is likely most appropriate.
- Identify the specific business cases that would benefit from a policy (see the discussion on "How does open source fit into your business strategy?" above).
- Assess the impacted functional areas. Think broadly, beyond the development and legal teams. Your HR (employee participation in outside projects), IT (internal security), finance (lack of indemnification; revenue recognition), and other departments might also need guidance on how open source will impact their functional areas. Also think outside your company to assess the impact on your customers, partners and the open source community.
- Assign appropriate review and decision-making authority. The more important open source is to your business strategy, the more important it is for your managers to understand what open source issues they can approve, and the proper escalation paths.
- Test hypothetical business cases. While this concept is relatively simple, it can provide a meaningful sanity check before implementing a policy in a complicated business. For example, this type of review might identify that employees do not understand open source issues enough to implement the policy and strategy, which might require more training.
- Manage conflicts with other policies and strategies. For example, a company that rarely uses open source might have an supplier indemnification policy that would not be appropriate if it decides to use open source software more frequently in its operations. Open source components often don't have the warranty and indemnifications protections these companies are used to seeing.
Companies should review their policy/strategy alignment regularly to ensure both that their strategies accurately reflect their use of open source, and their policies address the particular needs of the company.
More Information
You might also find the following web links interesting as you continue your own research into open source policies (note that I do not necessarily endorse or agree with the content in these links, but they provide other perspectives on the policy discussion):
- Black Duck Software - Offers a whitepaper entitled, "Creating and Implementing an Open Source Policy: Five Steps to Success" (registration required)
- ABA Section of Science and Technology Law - Offers both a model open source software policy outline and a model open source software review/approval form that might server as starting points for a policy. These documents were drafted in 2005 by Heather Meeker of Greenberg Traurig, LLP, who is known for her frequent involvement in open source issues, and they are available for reuse and distribution under a Creative Commons license.
- Open Logic and Stormy Peters - Offers a heavily reference "how to" guide for policy creation. As referenced earlier in this post, the article provides more detail on the specific types of content that you might consider adding to a policy. Note: Open Logic also offers papers on how to write an open source policy and open source policy best practices (registration required).
- Digium - This open source telephony software/equipment provider shows (in multiple blog posts here and here) potential customers how to assess whether open source is right for them and to what degree. This is an example of a "policy" designed to promote a particular type of software by a particular provider.
