The five stages of the Open Source Program Office

[This article is contributed by TODO Group, an OSI Affiliate organization]

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