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
- 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:
- Information Technology (IT)
- Product Development
- Service Organizations
- Mergers and Acquisitions
- Alliances and Partnerships
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.
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.