Open Source Program Offices: The Primer on Organizational Structures, Roles and Responsibilities, and Challenges

Open source initiatives provide companies with proven, successful models to collaborate with other companies, create new technologies, and support the development of new technical communities. Companies across many industries are creating Open Source Program Offices (OSPOs) and staffing them with highly skilled individuals to help them drive for a leadership position in open source projects and gain a critical footprint in this external R&D ecosystem.

In this article, we take a close look at how enterprises structure their OSPOs, discuss their roles and responsibilities, and preview some of the challenges that will be countered and need to be addressed.

Disclaimer: This article expresses my own views, and does not necessarily reflect those of my current or any of my previous employers.

Introduction

The availability of enterprise grade open source software is changing the way organizations develop and deliver products and services. The combination of a transparent development community and access to public source code enables organizations to think differently about how they procure, implement, test, deploy, and maintain software. Open source software has created an ecosystem with a wealth of benefits for those involved. Companies across industries and domains are in a race to build up their open source operations under an OSPO to help them use and contribute to open source more efficiently and effectively. 

Open source software allows shared development and lowers R&D cost by enabling companies to reap the benefit from the availability of billions of dollars worth of open source software, which they can harness to create better products and services. It also helps accelerate product development and enables a faster time to market by aligning business needs with the upstream open source projects. Companies do not get involved in open source projects because it is fun; they do it because it is a part of their business or product strategy. OSPOs manage and orchestrate that involvement. 

The first step to establish an OSPO is to realize that open source is key to mastering software, given the reliance on open source software in almost every software product or service that exists today. Leading companies in a growing number of industries have established their position through software dominance, and open source is often a critical component of this dominance. The second step is an executive sponsor that will support the establishment and funding of an OSPO. The executive sponsor is an individual who can provide financial stability with a long-term commitment to improving and growing open source engineering in the organization. This person will also play a critical role in identifying a trusted open source leader who can create and grow the OSPO.

In the following sections, we explore two main themes: the first is the structure of an OSPO from an organizational perspective, and the second is the scope of responsibilities associated with an OSPO. 

OSPO Organizational Structures

This section explores some of the common OSPO structures. It is important to keep in mind that no two companies are alike. Therefore, there are no cookie-cutter style OSPO structures. Instead, many companies, including those with a long record of open source involvement, keep experimenting with different setups. Generally, their goal is to find the most suitable and efficient structure based upon their overall software strategy, open source aspirations, reliance on open source software in products and services, current and desired position in specific open source projects/communities, and some other internal factors.  

Example 1: OSPO within an R&D Center

One common structure for an OSPO is to have it within an R&D organization. For instance, we used this model with the Open Source Group at Samsung when I established and lead the group for almost 6 years. In this example, the open source leader owns open source upstream engineering, strategy, and support functions, and reports directly to the President of R&D. The OSPO has a dedicated budget to cover headcount, travel, and sponsorship costs for events, membership dues for open source foundations, hardware and software expenses, and a variety of other expenses. In this capacity as VP of Open Source I reported to the EVP of Research in Korea who was the executive and financial sponsor of the Samsung Open Source Group.

There are two main reasons to structure the OSPO under an R&D organization. The first is to isolate the group from product divisions, thereby preventing it from becoming an auxiliary development arm for those divisions, distracting them from their upstream responsibilities. This setup allows the OSPO to maintain a certain level of independence, both financially and in terms of projects, so it can focus on open source technologies of the highest priority without favoritism to any product division. The second reason to structure an OSPO within R&D is to better support efforts that involve external parties, such as other companies and universities, away from the daily product pressures. 

Example 2: Corporate-level OSPO with supporting division-level OSPOs 

This model works best in large companies with multiple product divisions. It consists of a corporate-level OSPO, which coordinates the activity of multiple supporting OSPOs at the division-level. The corporate OSPO is responsible for setting company-wide policies and processes, deciding on strategy, working with open source foundations, driving major open source initiatives, and open source matters at the corporate level in general. 

The supporting OSPOs are responsible for the executing open source strategy at the division-level, ensuring staff follow the corporate policies and processes, delivering training, and in many cases, responsible for upstream open source engineering. The corporate OSPO may not have any engineering resources with the exception of very few senior engineers to provide technical leadership in their respective expertise areas.

Example 3: Virtual OSPO

The virtual OSPO is a common setup in which the company has a head of open source, typically within the engineering organization, without any dedicated staff. The head of open source works with a virtual OSPO staff that consist of individuals from different teams such as Legal, Engineering, Developer Relations, Marketing, etc., each of whom dedicate a certain percentage of their time to support open source activities. 

A virtual OSPO does not typically have a dedicated budget; rather the budget for any open source spending would typically come from the Engineering organization or the CTO office. 

Example 4: No Official OSPO

The next example is an organization that does not have an official OSPO. This is typical in smaller companies and startups where different individuals fulfill the duties associated with an OSPO. This structure provides more flexibility for smaller organizations, but is difficult to scale as the organization grows.

Example 5: OSPO as Part of the CTO Office or Engineering 

In medium sized companies, it is common to house the OSPO either within the Engineering organization or under the CTO office. This OSPO structure typically has a dedicated budget managed by the executive sponsor (SVP of Engineering or the CTO). The OSPO may have its own budget, but all spending and any external commitments require the approval of the executive sponsor. The OSPO might have dedicated engineering resources that work on upstream projects depending on the company's needs. 

Staffing an OSPO 

The staffing of an OSPO depends on many variables. However, several roles are required regardless of the specific structure of any given OSPO. These roles do not have to be distinct positions. In some cases, distinguished individuals with a very strong set of skills can fulfill more than one role.

Head of OSPO 

The Head of the OSPO is sometimes called Director or Vice President of Open Source, depending upon the size of the organization and the open source team. The Head of Open Source is responsible for managing and executing company-wide open source strategy and business metrics to track the business and technical success of the program. Depending on the structure of the OSPO, the office leader can also be responsible for open source engineering resources, ensuring open source compliance, representing the company towards open source organizations, and participating in open standards efforts. 

Software Architect 

I believe that it is mandatory for an OSPO to have one or more Senior Software Architect or a Principle Engineer to act as a high-level technical decision maker on topics related to open source software, from design choices to technical standards, such as platforms and coding standards.

Technical Evangelist 

A technical evangelist is an individual with a strong technical background whose primary role is to evangelize the open source contributions and solutions developed by the open source group to the company’s customers, prospects, and partners, and the open source community in general. They are responsible for building demonstrations at events, delivering technical presentations, creating documentation, and generally building support to a critical mass for a given technology. 

Compliance Engineer 

The compliance engineer supports the execution of the company’s compliance policy and process, ensuring the company fulfills all license obligations for the open source software used in products and services. Some OSPOs have complete ownership of the open source compliance function; in these cases, the OSPO may need to host several compliance engineers. 

Legal Counsel 

It is rare for an OSPO to have a Legal Counsel among its staff. In most cases, having access to a legal counsel versed in open source licensing is sufficient for small and medium size companies. 

OSPO Responsibilities

The OSPO assume different responsibilities that change over time. In the following sections, we explore these responsibilities.

Develop and Execute Open Source Strategy 

The are four primary open source software strategies: consumption, participation, contribution and leadership. Each strategy requires you to be successful at the previous strategy, and how far your company goes up this ladder is entirely up to your own discretion. 

These four strategies overlap as you transition from one position into another. Typically, the early stages are engineering-driven due to of engineers using open source components in product development. Initially, their participation in strategic projects may be limited to joining the conversation or making small contributions. With time, this usage can grow within the company and become part of the business strategy as it gains traction.

The following figure illustrates these four stages with a short summary of each one.

These stages overlap as companies transition from one stage to the next.

Some companies are able to achieve their goals simply as consumers and are content to stay at that level, while other companies have ambitions to attain certain leadership positions. There is a good chance you are already at one of these levels, so it is important to identify both your current position in the ladder and your target position, then chart a path to drive you forward.

While there are numerous strategic objectives to choose from, some objectives are quite common among companies that use and develop open source software:

• Reduce development costs
• Improve the quality and flexibility of products
• Achieve a faster time to market for products
• Increase engineering capacity through community engagement
• Broaden and deepen developer community commitment to your open source efforts

Oversee Open Source Compliance

Open source initiatives provide companies with a vehicle to accelerate innovation through collaboration with open source projects' communities. However, there are important responsibilities that accompany this: all companies must ensure compliance to the obligations of open source licenses. Open source compliance is the process by which users, integrators, and software developers observe copyright notices and satisfy license obligations for their open source software components. 

Open source compliance helps achieve four main objectives:

• Comply with open source licensing obligations.
• Facilitate effective use of open source in commercial products.
• Comply with third-party software supplier contractual obligations.
• Protect commercial product differentiation. 

OSPOs are generally involved in open source compliance in two ways:

• They are responsible for implementing and running a complete end-to-open source compliance program, which includes policy, process, tools, automation, education, and the final fulfillment of obligations for open source software included in products, software, or services. 

Or,

• They are responsible for setting the company’s general open source policies and the execution and enforcement of these policies are pushed into the various divisions across the company. For instance, ensuring open source compliance is a great example of this scenario where the OSPO focused on policies and processes, and dedicated teams on the product side are trusted than the actual implementation and execution of a compliance program.

The OSPO setup has a direct impact on the full scale of compliance responsibilities. Regardless of the specific role of an OSPO, it must have at least one individual who is knowledgeable in open source licensing, compliance practices, and engineering. 

The minimum set of individuals that represent the core compliance team include a legal representative, an engineering or product representative, and an open source compliance expert who is often a member of the OSPO. For a detailed discussion on the topic of open source compliance, please download the free e-book “Open Source Compliance in the Enterprise”, published by The Linux Foundation. The e-book is a practical guide for organizations on how best to use open source code in products and services, and participate in open source communities, in a legal and responsible way.

Collectively, these three roles (legal, engineering, compliance) are responsible for three main tasks:

• Ensuring mutual compliance with third-party software and open source software licenses.
• Facilitating effective usage of and contributions to open source software.
• Protecting proprietary intellectual property (and consequently product differentiation)

Establish Open Source Policies and Processes 

The policies and processes the OSPO needs to create depend on the company's current and target position in the strategy ladder. In the first stage (consumption), the OSPO needs to implement an open source infrastructure that can support the consumption and compliance aspects of open source software.

That infrastructure goes well beyond a simple policy to define the company’s guidelines for using open source software. In fact, it extends to encompass a strategy that covers usage and compliance, incorporating compliance checkpoints in the development process, establishing a team to supervise the proper usage of open source, providing necessary training, enabling tooling, and facilitating relationships with relevant open source organizations. 

Prioritize and Drive Open Source Upstream Development 

One of the primary responsibilities of an OSPO is to improve the company’s engagement with key open source projects used in products and services. The first step is to identify where the company relies on open source software by surveying all products and reviewing the software bill of materials. The next step is to prioritize the open source software that is already used and establish a contribution strategy. A focused approach like this allows the OSPO to show a return on investment across multiple products. In an enterprise setting where the OSPO and open source engineering is a cost center, the driving force should be to focus on open source projects that directly support product development.

The following figure illustrates additional elements the OSPO needs to implement to support open source contributions. 

Work with Open Source Foundations

Open source foundations are a great resource to expand your impact within the open source ecosystem. The best place to start is with foundations that host initiatives relevant to your products or technical interests. Many companies find it worthwhile to get involved with well-known, established foundations such as the Linux Foundation, Mozilla Foundation, Apache Foundation, Eclipse Foundation, and many others. If you are concerned primarily with the legal aspects, you can get involved with organizations such as the Software Freedom Law Center or the Open Invention Network. The primary goal is to identify opportunities within the ecosystem your company relies upon. The OSPO is the entity that drives these relationships based on the company’s open source strategy and product priorities. 

Track Performance Metrics 

One of the more difficult tasks for an OSPO is to decide on key performance indicators or metrics that the office should track to incentivize engineers towards the desired behavior. The traditional metrics, often used in product organizations, do not necessarily apply in the context of open source development. Therefore, the adoption of new performance metrics is required.

Additionally, many OSPOs use specialized tools to track their organization’s contributions to open source projects, analyze the type of contributions from their company, identify contribution patterns, and provide recommendations to improve development impact.

Implement Inner-sourcing Practices 

Inner-sourcing describes the process of taking the lessons learned from open source development methodology and applying them to internal projects. Driving inner-sourcing efforts is a great method for OSPOs to expand the impact of open source and to foster internal collaboration using inner-sourcing practices. These internal collaborations present incredible visibility opportunities for the OSPO with other organizations or teams within the company. In addition, such interactions and collaborations position the staff of the OSPO as the internal experts on open source practices, opening new opportunities to collaborate with R&D and product teams.

Grow Open Source Talent Inside the Company 

One of the core responsibilities of an OSPO is to grow the open source talent inside the company. To do so, OSPOs can run various programs that include workshops, training, mentoring and internal evangelizing. 

Education is an essential building block in an OSPO and it falls into two categories: technical training to expand open source technical knowledge, and compliance training to ensure that employees possess a good understanding of policies governing the use of open source software. The goal of providing this training is to raise awareness of open source policies and strategies to build a common understanding around the issues and facts of open source licensing, and the business and legal risks of incorporating open source software in products or software portfolios. Training also serves as a venue to publicize and promote compliance policies and processes within the organization, and to foster a culture of compliance.

OSPOs can also create mentoring programs where senior open source developers mentor junior developers, review their code commits, provide feedback on code before it is submitted to the upstream projects, and generally act as an advisor. The goal is to accelerate learning and support junior developers to become better and more influential in the open source projects. 

Open Source Adviser 

OSPOs act as advisors on all matters related to open source software, whether they are internal issues to the company or external issues relating to compliance, open source foundations, open standards, M&As and others. Because of the importance of this advisory role, senior OSPO staff also play a critical role in shaping their companies’ software strategy, given how key is open source within that larger software ecosystem. 

Manage Open Source IT Infrastructure 

One of the OSPO’s challenges is to ensure their organization provides an IT infrastructure that allows open source developers to communicate and work with the open source projects with minimal challenges. There are three primary domains of IT services that are common in open source development: 

• Knowledge sharing: wikis, collaborative editing platforms, and public websites.
• Communication and problem solving: mailing lists, forums, and real-time chat.
• Code development and distribution: code repositories and bug tracking platforms. 

Some or all of these tools will need to be available internally to properly support open source development. These open source practices typically require an IT infrastructure that is less restricted than a typical corporate environment. This situation might create a conflict with existing company-wide IT policies. If so, it is vital to resolve these conflicts and allow open source developers to use the tools that are familiar with them. It is worth noting that some OSPOs in large organizations even create and manage their own IT infrastructure independently from their corporate IT departments.

Eliminate Friction from Using or Contributing to Open Source 

OSPOs face a number of challenges that we can group into five areas: culture, processes, tools, continuity, and education. The following figure illustrates these various challenge areas.

The general goal of an OSPO is to make it easy for their company as a whole to use and contribute to open source software in support of their business goals. As such, facing and resolving these challenges and possibly others that are unique to your company will help you achieve that ultimate goal. 

Support Corporate Development Activities

OSPOs should be involved with open source due diligence (technical and compliance) as a part of corporate development. The two major scenarios are merger and acquisition transactions, and outsourced development.

• Mergers and Acquisitions: If a company is considering a merger or is the target of an acquisition, the OSPO is a great source of expertise for open source technical and compliance due diligence. OSPOs can help their organization understand the open source code in use by the target company and its implications as part of the due diligence process.
• Outsourced Development: The OSPO can also support corporate development when negotiating outsourced development of software, ensuring the proper compliance procedures are followed per the company’s policies and processes.

Collaborate with Universities on Open Source Projects

Many universities are eager to work with companies that offer learning opportunities for their students, in addition to gaining real world development experience. Often, this relationship is also beneficial to the companies involved because it can be a great way to develop new talent in existing open source communities and to attract new development talent. This is particularly useful for projects that have a shortage of experienced developers, making them more difficult to hire from. You cannot hire all the smart people in the world, so you will need to find a way to tap into new knowledge and influence favorable outcomes in external projects, including academia. 

Bonus: Say “No”

This is purely my favorite: saying “No.” OSPOs act as a gating organization for all major contributions that leave the company, including new projects or contributing major pieces of proprietary code. Saying “No” is the responsibility of OSPO leaders when proposals to release open source projects or contribute significant bodies of code do not meet the proper requirements for success. 

The TODO Group 

The TODO Group consist of many member companies who collaborate on the policies, practices, and pragmatics of running an open source program office. Their collaboration is managed as a community project under the Linux Foundation, and they are a resource to companies who are just starting to get their open source programs established. TODO group publishes guides for open source program offices, and its members frequently present at open source conferences on best practices.

If you are looking to establish an OSPO in your company, or you lead an OSPO and looking to connect with peers at other organizations, please visit todogroup.org to learn more and reach out to [email protected] to find out how to join. 

Closing

OSPOs play a critical role in helping companies master open source software and drive companies into leadership positions in open technologies that are critical to their products. OSPOs can support their organizations in four key areas: 

• Consumption - Establish internal infrastructure that enables proper open source practices and incorporates open source policies, processes, checklists, and training.
• Participation - Engage with the open source community on communication platforms and at events. Sponsor projects and organizations that are important to open source software you rely on for your products.
• Contribution - Hire or train developers that focus specifically on open source contributions and deploy the necessary tools to support internal open source engineering.
• Leadership - Increase engagement with open source communities, open standards bodies, and foundations. Launch new open source initiatives and increase your visibility in open source communities.

If you are a company that relies on open source software for your products or services and you do not have a formalized OSPO yet, please consider this article as a call for action to do exactly that!

Feedback

Please accept my advance apologies for any typos or possible errors. I am grateful to receive corrections and suggestions via ibrahimatlinux.com/contact.html.

License

This article is licensed under the CC BY 4.0.

About the author

Ibrahim Haddad (Ph.D) is the Executive Director of the LF AI Foundation. Throughout his career, Haddad has held technology and portfolio management roles at Ericsson Research, the Open Source Development Lab, Motorola, Palm, Hewlett-Packard, Linux Foundation and Samsung Research. He is known for his writing and speaking on topics ranging from legal compliance to using open source as an R&D tool to drive collaboration and innovation. 

Twitter: https://twitter.com/ibrahimatlinux