From Policy to Process: Best Practices for Creating an Open Source Governance Process

These days, practically every company out there is involved with free and open source software (FOSS) in one way or another, but don’t be fooled by the use of the words “free” and “open”: FOSS still needs to be managed just like any other third-party software. The ways in which it enters your company, what it can be used for, how it impacts your daily operations — these processes need to be tracked, organized, and streamlined.

Creating an open source policy manual is the first step companies typically take to help manage the use and adoption of FOSS, and this is usually followed by setting up the right governance processes to help implement the policies. Companies often struggle with several questions they need to answer in establishing these processes. This article will help you identify some of the common questions and factors to consider when setting up an open source governance process. We’ll also provide practical tips on some of these areas based on what organizations have done in the real world.

Please note that this article builds heavily on Stormy Peters’ excellent guide: Best Practices for Creating an Open Source Policy. If you haven’t already done so, be sure to read that article before proceeding any further.

Why do you need an open source governance process?

There’s hardly a company today that does not interact with FOSS to some degree. These interactions range anywhere from using FOSS as part of their internal IT infrastructure, to distributing it as part of a product they sell. Some of these interactions may even be unintentional. For example, a company may buy third-party software that incorporates FOSS components.

FOSS can enter a company through many channels, most (if not all) of which may not be set up to track its flow through the organization. While many consider this non-traditional fluidity one of the key benefits of FOSS, it does pose certain challenges in today’s world of corporate accountability. In fact, tracking FOSS in your company usually goes beyond the well understood need for audits and compliance. Information collected as part of FOSS governance can be an invaluable tool in making strategic decisions and is often used as a competitive advantage.

A well designed open source governance process can help your company:

• Track the various FOSS projects (and associated licenses) that are currently being used in your organization.
• Identify all the areas that have a key relationship with FOSS and the nature of that relationship (consumer, participant, maintainer, etc.)
• Establish a direct communication channel to all of the key stakeholders for any timely updates related to FOSS (e.g., upcoming license change of a FOSS package you depend on).
• Integrate FOSS reviews into your regular corporate work flow so nothing falls through the cracks.
• Cultivate mutually beneficial relationships with FOSS projects and communities that are important to your company.
• Relax. While an open source governance process won‚Äôt pay for your vacation, it will certainly help provide the peace of mind that comes with knowing your organization is well equipped to maximize FOSS benefits while minimizing risk.

It is also key to understand that there are a lot of variables that will influence your choices in each of the sections outlined below. These variables include:

Organizational maturity: Whether your company is a 20 person start-up or a 200,000 person enterprise will have a strong impact on all aspects of your FOSS governance process.

Primary business: FOSS, in the context of this discussion, is a key part of your technology arsenal. If your primary business is in the technology space, FOSS could have an undeniable role in your strategy. On the other hand, if your company relies on others to provide technology expertise, you may also need to procure FOSS expertise from similar external providers.

Existing processes (procurement, product/service releases, public relations, etc.): FOSS will affect all aspects of your organization. In some cases you may need to augment existing processes, while in others you may need completely new ones.

Organizational culture: Your FOSS governance process will need to fit in with your existing organizational culture in order for it to succeed. For example, this could mean deciding between a heavyweight process that is very structured and implemented top-down, a lightweight process that is more informal and driven organically from the bottom up, or some hybrid of the two. Organizational culture is intangible and can be difficult to incorporate in governance processes, but it can make the difference between a process that struggles for adoption and one that becomes a great success.

Keep these variables in mind as you read through the sections below, and while planning and designing your FOSS governance process.

Common factors to consider before implementing a governance process

Before you embark on creating an open source governance process, here are a few items you should already have lined up:

• An open source strategy and policy
• Sponsorship and organizational support
• Funding
• FOSS expertise, gaps, and dependencies identified
• Metrics and tracking

Let’s look at each one of these in a bit more detail.

An Open Source Strategy and Policy

An open source governance process puts your open source strategy and policy to work. It’s only natural that you need an open source policy in place before you start designing and implementing an open source governance process.

However, this is not a hard requirement. Organizations often start with a process and a loosely defined policy. It is not uncommon to find even large organizations where one person has been entrusted with the responsibility of figuring out an open source policy and process.

That said, starting from a policy gives you the benefit of knowing what your organization expects from its relationship with FOSS. With that knowledge, you can develop a process that complements and accelerates the implementation of that policy. It also ensures that the amount of time, money, personnel, and effort you invest is in tune with your company’s expectations with regard to FOSS.

Sponsorship and Organizational Support

Since FOSS interfaces with almost all aspects of an organization, your FOSS governance process should follow suit. In large organizations, this usually means you will need to navigate organizational charts and interact with people at various levels. Once the process is in place, you’ll need to convince some of these same people to use it.

Ensuring the governance process is sponsored at a sufficiently high level goes a long way towards opening doors. In organizations that take a strategic view of FOSS, the Chief Technology Officer (CTO) usually is the executive sponsor for FOSS strategy and its implementation.

Similarly, the personnel who will use the governance process on an ongoing basis should be involved in its design so as to give them a sense of ownership later on. This also gives them the opportunity to share insights about what will work and what won’t. To do this, you should identify the various touch points your organization has with FOSS. These may include:

• Procurement
• Information Technology (IT)
• Product Development
• Service Organizations
• Mergers and Acquisitions
• Alliances and Partnerships

Funding

Implementing an open source governance process is going to require some investment. Funding is typically necessary to cover a variety of expenses, including:

• Hiring one or more people to run and maintain the process.
• Training the various groups within your company who are going to actually use the process.
• Covering costs associated with developing or licensing any software that might help implement the process.
• Bringing in the occasional outside expert or consultant.

FOSS Expertise, Gaps, and Dependencies

Since your open source governance process is going to serve as the central, company-wide resource for FOSS expertise, you should identify sources of such expertise as well as any key gaps and dependencies. This could include legal experts with deep knowledge of various FOSS licenses, community experts who practice the fine art of FOSS community building, and training partners who offer both broad and deep sessions based on your needs. Note that it is highly likely that at least one or more of these experts may be outside your company.

Metrics and Tracking

The renowned psychologist George Miller once said: “The chance is negligible that you will measure the right things accidentally.” A well designed FOSS governance process is going to turn up several pieces of data that, if tracked and measured, can provide some astonishing insights into your company’s FOSS adoption.

Here are a few examples of such patterns that can be detected as well what you can do with the data:

• What are the top open source projects that your company depends on? How good is your relationship with these communities?
• Who are the developers that contribute most to open source projects? Is there a particular department that tends to adopt and contribute to FOSS significantly more (or less) than others?
• How long does a typical open source review take? Where are the bottlenecks?
• What are all the products/services that interact with Project X and/or License Y?

As you can see, by planning ahead you can ensure that you measure and track the key pieces of data that are important to your unique needs and goals.

By incorporating the above list into your planning, you will be well equipped to design and implement a FOSS governance process tailored to meet your company’s needs.

How to Develop and Maintain an Open Source Governance Process

Once you’ve had an opportunity to plan the key aspects of your open source governance process, you’re ready to develop and implement it.

As you begin designing the governance process based on your plans, you’re likely to face decisions around some common design factors, which we’ll describe below. One approach in developing your FOSS governance process is to view each of these factors as modules that must be properly integrated to create the right governance process for your company.

Centralized vs. Decentralized

This is a classic question that one faces when designing a process of moderate to high complexity. While there are numerous benefits to choosing one or the other, your FOSS governance process is probably going to be a mixture of the two. This is especially true for large companies that have separate departments or business units. Usually these departments operate with a lot of autonomy in almost all aspects of their business. In addition, they may each have defined their own processes for certain common areas.

In the case of a FOSS governance process, there is immense benefit to having a central data store that tracks FOSS usage and contribution across the entire company. In addition, operating a central review body such as the Open Source Review Board (OSRB) outlined in Stormy Peters’ article on policy creation adds value. The OSRB can provide an additional layer of checks and balances in addition to centralizing key tasks that may be performed redundantly across various departments.

However, such centralization can also easily turn into a bottleneck.

One way to balance this is to identify the minimal set of process artifacts that really need to be centralized as opposed to others that can be delegated to individual departments. For example, everybody across the company may be required to use a central database to store FOSS proposals and reviews, while individual departments may choose to enforce stricter requirements for compliance than those the central OSRB recommends.

Existing vs. New Process

This is another common question that comes up when designing a FOSS governance process. One school of thought suggests that FOSS should simply be treated as any other piece of third-party software and, as such, existing processes for third-party software should be leveraged for FOSS as well. The other approach insists that FOSS is different from third-party software and necessitates the creation of a separate FOSS governance process. The former may prove sufficient if your FOSS strategy is primarily centered around using FOSS to lower software costs. If you’re looking at FOSS in a much more nuanced manner, then the latter is probably the way to go.

Note that just because you have defined a separate governance process for FOSS does not mean you cannot reuse certain existing work flows. For example, an organization that uses Bugzilla to track defects in their software may decide to use the same tool to track FOSS usage and contributions as well.

Tools and Automation

A FOSS governance process can benefit greatly from the proper application of the right tools for help in automation. Fortunately, there are several ready-made options available. The following is a short list of these options. Descriptions of their functionality, pros and cons is a topic for a separate article.

FOSS options:

• FOSSology http://www.fossology.org/
• OSSDiscovery http://ossdiscovery.opensource.collab.net/
• Tiddly-Guv http://trac.tiddlywiki.org/browser/Trunk/contributors/MichaelMahemoff

Commercial options:

• BlackDuck http://www.blackducksoftware.com/
• Palamida http://www.palamida.com/
• Protecode http://www.protecode.com/

In many cases, you may find that some combination of the tools above will provide the solution that is most helpful to you.  Also, while it may be tempting to design your process around one or more of these tools, doing so could result in a sub-optimal FOSS governance process. This is why you should define your policy, develop your process, and only then choose the right tool(s) to help automate your process.

Web Presence

In addition to the tools that help you implement your FOSS governance process, you should consider setting up a FOSS portal. Depending on whether you will also be contributing to FOSS, you may actually need both an internal and an external facing portal.

The internal portal will help serve as the central resource for all things related to FOSS within your company. These are some of the common portions of an internal FOSS portal:

• Documentation on your company‚Äôs open source policies and strategy.
• A clear description of the FOSS governance process, its work flow, roles, and responsibilities.
• FAQs, project and license advisories, training guides, and other useful self-service resources.
• Any tools associated with the FOSS governance process and associated guides.
• A list of case studies of various FOSS reviews that have been approved (or denied) by your Open Source Review Board (OSRB).

An external portal usually includes sections such as:

• An overview section highlighting your company‚Äôs open source strategy.
• A detailed list and descriptions of the various FOSS projects your company is involved with and its role in these communities.
• Technical articles, white papers, developer interviews, etc. that provide greater insight on specific projects and people.
• A list of upcoming events where representatives of your company may be available to interact with customers and the FOSS community.

One common section that should be present on any portal is the “Contact Us” section. You should establish clear, easy lines of communication with the consumers of your FOSS governance process. This will be crucial to ensure there is a free flow of information both in and out of the FOSS governance process.

Launch and Roll-Out

Once you’ve developed your FOSS governance process and are ready to implement it, you should consider doing so in phases. A targeted pilot for a short period of time can help test all aspects of your process. In addition, it can provide valuable feedback on areas that need to be refined before proceeding with a more widespread roll-out.

After your FOSS governance process has been in place for a while, you may want to measure its effectiveness. Analyzing the data you’ve collected to see if it matches your expectations is one way to measure this. In addition, you may want to perform random audits across your company to test both coverage and adoption.

Keep in mind that just like your FOSS policy, your governance process is also going to require ongoing changes to keep up with the evolving needs of your company.

Critical factors that can help you implement a successful governance process

In addition to the items covered above, the following is a list of practical recommendations that can help you implement a successful FOSS governance process.

We Are Here to Help, We Are Not the Police

Design, develop, and run the process as a resource that’s available to help rather than yet another piece of bureaucracy that will result in roadblocks. There are several intricacies associated with FOSS adoption that people will be more than happy to not have to keep up with and instead rely on a trusted internal source that does the job for them. However, if employees start perceiving the process as a Big Brother, they may try working around it.

The Only Thing Constant is Change

FOSS moves at a rapid pace. As your organization matures in its usage of and contribution to FOSS, be prepared to evolve your open source governance process to keep up with the rate of progress.

There is No Such Thing as Over-Engineering

Well, actually there is. Try to keep the process and its various interfaces as simple as you can without compromising on its effectiveness. The last thing you want is to have a process so complex to understand that nobody uses it.

Communicate, Communicate, Communicate

This is especially key for large organizations where new processes can easily get lost in the labyrinth of corporate communications. You will need to market the governance process through emails, webinars, blogs, word of mouth, and any other media that’s effective in your company.

Engage Those Open Source Champions

All companies have people who are agents of change. These dynamic individuals are at the forefront of new ideas and innovation happening in the company. Find the people who champion FOSS adoption in your company, and cultivate a good relationship with them. Sometimes, you may need to identify them via external forums such as open source project mailing lists, blogs, and twitter. Our advice is to track them down, buy them a cup of coffee (or a beer), and enlist their aid as you design, perfect, and market your FOSS governance process.

Summary

Now that you’ve read this article, you should have a clear understanding of the benefits of having a formal FOSS governance process. You should also have a framework with which you can plan, develop, and implement a governance process. So go to it! With this information you should be able to create and implement a process that aligns with organizational culture, structure, and goals so that your company can successfully execute its FOSS strategy.

Ragavan Srinivasan
Ragavan Srinivasan works as Open Source Program Manager at VMware. He’s interested in building a vibrant community of users and developers around VMware‚Äôs open source projects. Prior to joining VMware, Ragavan created and helped launch FOSSBazaar while leading several initiatives for Hewlett-Packard‚Äôs Open Source Program Office. As one of the founders of the Kids on Computers project, he is working to set up a computer lab for an elementary school in Mexico, running Linux of course.