An open source program office (OSPO) is an organizational unit of a company tasked with governing the use of, contribution to, and leadership of open source projects from the company’s perspective. Governance is the management of the company’s open source engagement by way of policies, guidance, and education.
An OSPO often starts out as a single person, who is tasked with reigning in the use of open-source software in projects and products. Once the scope of the challenge becomes clear, the OSPO is set up as a new organizational unit. An OSPO is typically a central function, often located in the office of the CTO.
The overall mandate of an OSPO can be laid out along the three dimensions of a basic maturity model of engaging with open source. This model consists of three stages:
- Using open-source software in projects and products. The main challenge of using open-source software is to ensure that only software that fits the company’s business model is used and that vulnerabilities are avoided or at least managed.
This form of engagement is therefore mostly about license compliance and supply chain security. Tools and tactics are focused inwards. They include, for example, education, software composition analysis, and component managers.
- Contributing code to existing open source projects. The main challenge of contributing to open source projects is to avoid the outflow of intellectual property that is competitively differentiating and therefore should be kept closed. This includes avoiding any contribution that signals important information to markets and the competition about the company’s product strategy.
This form of engagement is mostly about managing the dependencies on open-source software. Tools and tactics include education of the company’s open source contributors and outreach to open source communities.
- Creating and leading open source projects. The main challenge is to identify the business opportunities and justify the costs that result from creating and leading open source projects. This includes prioritizing and aligning open source leadership with the strategic goals of the company.
This form of engagement is mostly about industry collaboration for market positioning and managing revenue streams. It requires understanding of how industry dynamics play out, including but not limited to which features, components, or layers of the stack are ready for commoditization.
A company’s open source strategy consists of strategies for these three forms of engagement. The open source strategy, initially designed or at least facilitated by the company’s OSPO, is part of and has to align with the company’s overall business strategy.
For each form of engagement, the OSPO may have to set-up and operate tools and metrics, perform internal and external marketing, train its employees, ensure compliance, manage risks, respond to crises, etc. All of these tasks come with often non-trivial workflows.
The scope of an OSPO’s mandate widens with the growing maturity of the open source understanding and engagement of the organization: From initially just using open-source software, through contributing to open source projects, all the way to creating and leading open source projects. All of these activities need competent guidance, policies, and tooling.
© 2024 Dirk Riehle, used with permission.
Next up: Using open-source software