After years of observing the evolution of Open Source Program Offices (OSPOs) among members of the TODO Group, we’ve identified common patterns and summarized them in a shared framework. There are five common stages of the OSPOs that identify the status of your organization’s involvement in Open Source: use it as suggestions to advance your Open Source journey. This article is a companion to What is an OSPO and why you need one.

A walk through the different stages of an OSPO

To better explain the evolution of OSPOs, members from the TODO Group run an annual OSPO survey and propose a maturity model you can use for your organization. This model serves as a framework to understand the stages of an OSPO and thus identify where the organization is in terms of open source involvement and help them advance into a more mature adoption:

This model is composed of two variables and four stages:

• Y variable: Ability to execute
• X variable: OSPO level
• Stage 1: Legal driven
• Stage 2: Community driven
• Stage 3: Engagement driven
• Stage 4: Leadership driven

Stage 0: Adopting Open Source ad-hoc

Almost all organizations use Open Source, although how they adapt and use it varies. They may use it as a building block or library in a product or tool or as a key part of a vendor’s product stack or support the vendor’s service offering. Modern cloud-native applications, almost by default, use Open Source systems for container orchestration, observability, data storage, messaging, and more.

 However, the very earliest form of adoption is ad hoc, by developers solving problems using readily available tools and technologies. This “ad -hoc adoption” usually means little thought is given to license compliance outside the defaults or to longer-term impacts of consuming Open Source and distributing products built with Open Source components.

Stage 1 (Legal driven): Providing Open Source compliance, inventory, and developer education

In general, an organization forms an OSPO when it realizes that its people are consuming Open Source products and code across nearly all engineering and development departments and functions. This usage is typically internal, not part of products or services to customers or users. At this early stage, organizations often use many different names for the OSPO. IBM initially called its programmatic Open Source efforts the “Open Source Steering Committee” as an example.

Organizations in stage 1 recognize that Open Source is a key part of their business and technology strategy. They understand that the security practices of Open Source projects differ from those of proprietary software companies.

Organizations must identify their legal and security risks. Risk mitigation strategies include:

• Careful licensing
• Developer education
• Inventory taking

Stage 2 (Community driven): Evangelizing Open Source use and ecosystem participation

Early period

After organizations recognize the value of Open Source and the need for compliance, education, and a Software Bill of Material (SBOM), they begin to realize the economic benefits of Open Source usage and seek to expand it. OSPOs in stage 2 create such internal mechanisms as ambassadors who promote usage of approved Open Source products, educational programs on good hygiene, and technical training or tuition reimbursement for skill building and certifications in Open Source. With these initiatives, an organization can grow its use of Open Source and amplify its message that it’s not only important but desirable and preferable to proprietary software products.

Growth period

As advancing in this stage, organizations begin incentivizing their developers to work on OSS projects critical to their operations, to the degree that developers become highly active contributors or primary maintainers.

• OSPOs begin to streamline and optimize open outbound source contributions for their developers.
• OSPOs create and launch open source projects to establish broad credibility in the open source community

Stage 3 (Engagement driven): Hosting Open Source projects and growing communities

At stage 3, organizations initiate and then host or act as primary sponsors of Open Source projects. They will dedicate one or more full time employees to a project, and they accept responsibility for nurturing a project community, ensuring its health. They don’t confuse this level of organizational commitment with individual employees who decide to open source their projects. In this stage, organizational leaders support incubating and launching projects into the public sphere because they understand how they benefit their organization. Such projects tend to offer better performance and economics on crucial capabilities that may be non-core to the organization’s value proposition but critical to its technology infrastructure.

This is the stage where the OSPO develops processes, playbooks and tools to vet, organize, and operate Open Source projects and to prepare and coach their leaders.

Stage 4 (Leadership driven): Becoming a strategic decision-making Partner

At this maturity stage, the OSPO becomes a strategic partner for technology decisions, helping to guide choices and shape long-term commitments to projects. The CTO and other technology leaders consult the OSPO and its leadership on which Open Source technologies to rely on and which decision criteria to use in judging projects. Because major technology choices tend to generate significant secondary and tertiary costs and affect upstream and downstream technologies as well as hiring plans, the choice of Open Source projects becomes a major business decision.

The OSPO becomes a strategic partner for technology decisions, helping to guide choices and shape long-term commitments to projects. The OSPO evolves to offer strategic guidance:

• Advises the CTO and technology leadership on Open Source technologies to adopt/remove from the organization’s technology stack
• Take the lead on benchmarking what constitutes an acceptable Open Source project
• Help organizations understand and navigate project politics

The rise of the Open Source Program Office (OSPO) roughly mirrors the proliferation of Open Source software to build and run the most important technology applications within organizations in the world today. A well-designed OSPO is the center of competency for an organization’s Open Source operations and structure. Its role can include setting code use, distribution, selection, auditing, and other policies, as well as training developers, ensuring legal compliance, and promoting and building community engagement that benefits the organization strategically.

The Evolution of the OSPO: from tech giants’ resources to a worldwide adopted open source best practice

The OSPO concept is now about two decades old but really started to accelerate in the last decade or so, spreading beyond the boundaries of technology firms. Nowadays companies like Amazon, Google, VMware, Cisco, Goldman Sachs, Porsche, Aiven are encouraging their employees to contribute to Open Source projects that are strategic to their business and security. Initially focused on license compliance in the early days, the OSPO often plays a broader role inside organizations today.

OSPOs serve to educate developers and other employees about Open Source by fostering best practices and participation in communities to make developers more efficient. Over time, OSPOs have evolved from engaging in existing projects to generating and launching projects to the broader community. Upper-level management is more likely to acknowledge the crucial role that Open Source technologies play in accelerating innovation and sharing software development costs across multiple beneficiaries.

The formation of OSPOs can be analogous to when organizations first started to establish Chief Information Security Officer positions (CISO) as a reaction to security incidents. The organizations that established these centers of security competency protected and armed themselves for a better future. Those who did not, suffered the consequences of poor security practices with negative financial impact.

When you should start an OSPO

Chances are, your organization may already have an OSPO although under a different name. Depending on the organization’s industry, size, values, or even the region where it’s established at, it may be known as FOSS Center of Competence like at Mercedes-Benz or Open Source Programme Office at the World Health Organization.

Starting an Open Source Program office means moving from open source ad-hoc to adopting a strategic posture around open source. If your organization is not there yet, we recommend reading “How to convince your manager to start an OSPO” or taking a look at the different responsibilities to better explain to managers the mission of the OSPO.

Crucial characteristics and responsibilities of an OSPO

According to the Evolution of the OSPO study conducted by the Linux Foundation, any function calling itself an OSPO likely indicates that the organization has reached a maturity stage and critical mass where its OSPOs share key characteristics:

• Employees or teams are tasked with fostering and nurturing OSS usage.
• The organization has a formal policy around the use and production of OSS.
• Decision-makers and recognize that OSS and open source more broadly are important strategic assets.
• Significant numbers of employees or teams are contributing code to open source projects.
• Processes, procedures, and tools are in place to streamline and facilitate open source consumption and participation.

OSPO responsibilities vary depending on many factors, such as the organization size, industry, or culture but overall, the OSPO mind map can help you identify all different topics an OSPO can potentially take care of within an organization.

As the world shifts from proprietary software to Open Source everywhere, the role of the OSPO will grow in importance. The expectation of a successful OSPO will transition from educating developers or marshaling code contributions to adding meaningful strategic value and driving higher level Open Source strategy, innovation, and developer efficiency.