Chapter 3: Creating Your OSPO

• Introduction
• Starting with Strategy
• Designing your OSPO
• Using Maturity Models for OSPOs
• Applying This to Your Organization
• Possible Problems and how to Overcome Them
• Resources and Footnotes

Introduction

OSPOs can be really diverse, so taking the time to design an OSPO that will deliver on your organization’s goals is important.

This chapter will first help you to idenify your strategy so you can have a basis for planning the work your organization should do, and how the OSPO should be structured.

It will then look at designing and building a stable and strong OSPO that’s capable of covering the open source-related tasks and responsibilities needed by your organization.

Lastly, this chapter will introduce maturity model as a way of understanding what’s appropriate for your OSPO now and in the future as needs change.

Starting With Strategy

How To Develop Strategy

For individuals in Open Source Program Offices, effectively communicating the open source strategy to C-level executives demands a keen understanding of the industry landscape and alignment with the key considerations of CEOs and CFOs. This alignment necessitates a clear comprehension of the overarching corporate strategy and identifying technologies within the open source realm that can propel the organization toward its strategic objectives.

Victor Lu and Rob Moffat Presentation - Strategy - End Game for FINOS Maturity Model ¹

An OSPO achieves this by creating and maintaining a framework covering the following aspects: strategy, governance, compliance, and community engagement. The OSPO’s strategy focuses on aligning the organization’s open source use, contributions and compliance activities to its overall organization objectives across its projects, products, services, and internal infrastructure.

A strategy creates a high-level consensus on concrete topics and their impact on your organization and the people within it.

Things to consider when creating your strategy:

1. Create a strategy document: A good practice is to document this strategy in an open source strategy document ². This guide takes you through the process step-by-step.
2. Understand your Organization’s Goals: As mentioned in the previous chapter, you will need to understand your organization’s goals, and its current engagement with open source.
3. Consider the Context: When developing your OSPO’s strategy and design, you have a few different ways to approach its structure and position in the org chart before you think about personnel, technology, and budget. There is an excellent guide produced by the TODO group, called A deep dive into OSPOs ³ which explains all essential information on OSPO structures and operations.
4. Review an example OSPO’s structure: To get an overview of the potential activities of an OSPO you can review the OSPO Mind Map ⁴. This outlines the main responsibilities, roles, behaviors, and team sizes within the ecosystem of an OSPO.

Designing Your OSPO

Identifying What Your OSPO Should Manage

To do a good job, an OSPO needs to understand how the organization works. Knowing the company’s goals helps the OSPO make informed choices about using open source. For example, in a business setting, an OSPO might look at these areas to see how open source fits in::

Since every organization is unique in its values, business drivers, and culture, it’s challenging to provide specific content. However, addressing the following questions can help structure the document effectively:

• Which open source technology is and which will be important for your organization’s goals and product roadmap?
• Which open source projects directly and indirectly develop or influence these technologies and your organization’s goals?
• Which specific practices can best foster a sustainable open source ecosystem?
• Which of the organization’s processes have areas for improvement?
• How can open source support those improvements?
• How can you make workers champions for open source?
• How can the message be effectively transmitted to management for their understanding?

Taking the time to understand where the OSPO can add value will then help you to recognize who your stakeholders are.

Identifying Your OSPO’s Stakeholders

There are some common parts of the business where an OSPO may find its stakeholders. Stakeholders are all the people who will be affected by the work you will do. The OSPO flower diagram helps to visualize the different stakeholder groups. Each petal represents a certain group of stakeholders with specific activities associated with this group. The OSPO Flower Diagram can also be used to help you map the specific communication channels, documentation and other material used with each group of stakeholders.

Depending on the complexity of your organization and the resources available to your OSPO, these petals can become more granular and include additional petals with different names.

ospoflower.pdf

• Individual Contributors: This petal represents the people who the OSPO will work within the organization, focusing on the intrinsic and extrinsic motivators of contributing to open source from an individual point of view. It requires a cultural change effort and may involve activities such as establishing mentoring programs.

• Management: In this petal, the OSPO focuses on strategy and finding alignment between open source and the overall business/organization strategy. Managers face unique challenges, and using the strengths of open source helps them overcome these challenges effectively.

• Legal: This petal represents the legal aspects of open source. It deals with understanding and managing legal requirements and obligations related to open source initiatives within the organization. This ensures compliance and reduces legal risks.

• Business: This petal focuses on how the OSPO ensures all the pieces of the organization structure fit together. It involves sharing best practices across different business/team units and fostering collaboration and knowledge transfer.

• Open Source Ecosystem: This petal represents the broader open source community and project ecosystem outside the organization. The OSPO engages with this ecosystem, which includes other organizations, projects, and individuals, to exchange ideas, collaborate, and contribute to the larger open source community.

• OSPO: This represents the inner workings of the OSPO itself. The people within the OSPO collaborate and coordinate all the open source initiatives within the organization. They oversee the activities, ensure smooth operations, and provide guidance and support to other stakeholders involved in open source.

Collaborating With External Regulators

External regulators aren’t included in the flower diagram, as this is a special case.

Organizations are subject to various external regulators that influence and shape their policies and processes. These regulators ensure compliance with legal requirements, ethical standards, and industry-specific guidelines. Some external regulators include:

• Government Agencies: Government bodies establish and enforce laws and regulations that impact organizations.
• Industry Regulators: Many industries have their own regulatory bodies or professional associations that set guidelines and standards for organizations to follow.
• Consumer Protection Agencies: Consumer protection agencies ensure that organizations provide fair and safe products or services to consumers.

For open source to be successful and sustainable within an organization, it’s crucial to collaborate not only with the open source community but also with external regulators. This collaboration ensures a clear understanding of open source principles when creating policies that affect the ecosystem. The primary objective is to work together and make informed decisions by fully grasping the implications of open source and its community. Thus, it’s recommended that the OSPO consider ways to develop a plan for approaching and communicating with regulators, clearly defining the roles they will play in the policymaking process.

Using Maturity Models for OSPOs

An Introduction to Maturity Models

An organization’s engagement with open source typically sits along a scale from tactical to strategic. Maturity models help you to understand where on this scale different parts of the organization sit and to have conversations about whether it’s in the right place.

There are many different open source maturity models. Some are general, some are specialized. There are maturity models for governments, NGOs, Enterprises and more, with versions and sub-versions to fit any organization.

NOTE: Maturity Models can be seen as a prescription for how OSPOs or open source engagement should develop. It can be tempting to think that it’s always better to increase maturity. But, remember that you should consider what level of maturity is appropriate for your OSPO, or each function of your OSPO. Not every part needs to be highly developed. It may already deliver the value that’s needed wihtout further development. If maturity models don’t fit for your OSPO, consider using a capability model or something else that you prefer.

Example Maturity Models

Each of these maturity models is slightly different, but they all classify open source engagement from tactical and less intentional to strategic and more intentional.

Maturity Model 1 - Open Source Engagement Adoption by Dr. Ibrahim H ⁵:

• Denial - No or unconscious use of open source
• Consumption / Usage - Passive use of OSS
• Participation - Engagement with open source communities
• Contribution - Pragmatic contributions to open source projects
• Leadership - Strategic involvement with open source to drive business value

Maturity Model 2 - Five Stages of Corporate Open Source Adoption Talk by Carl-Eric ⁶:

• Accidental - open source is used by the organisation without knowing that it’s used
• Repetitive - there are processes set up for both consumption and contribution, but contributions are sporadic
• Directed - active participation incritical open source projects
• Collaborate - open source collaboration is used as a tool to create business value
• Prevail - open source is used to influence strategic areas of the business and technology

Maturity Model 3 - The OSPO Maturity Model by The TODO Group ⁷

• Stage 0: Adopting Open Source Ad Hoc
• Stage 1: Providing OSS Compliance, Inventory, and Developer Education
• Stage 2: Evangelizing OSS Use and Ecosystem Participation
• Stage 3: Hosting OSS Projects and Growing Communities
• Stage 4: Becoming a Strategic Decision-Making Partner

Applying This to Your Organization

Here are some suggestions of how you could use the ideas and advice above to set up your OSPO. These are based on Maturity Model 3 - the OSPO Maturity Model by the TODO Group.

Using a Simple Checklist

The TODO OSPO checklist ⁸ offers a simplified set of common milestones to both early-stage and seasoned OSPOs in navigating each stage of the previously mentioned OSPO maturity model. Please note that an OSPO might remove, add, or edit some content of this checklist to adapt it to their organization’s needs.

Using Maturity Models

Once you have a certain familiarity with open source maturity models, you can start to use one to build your strategy and create your plan.

The OSPO Japan Local Meetup Working Group, supported by the TODO Group and OpenChain, has been developing a simple Frequently Asked Questions (FAQ) guide about OSPOs. This guide aims to answer questions at each step of the OSPO maturity model, which categorizes different open source activities from stage 0 to 4, and outlines the role of the OSPO at each level.

Here are some highlights from their work to inspire you:

NOTE: You can find a summary of their work in both Japanese and English in a Qiita article written by one of its members ⁹

While planning the OSPO it’s very helpful have 1:1 conversations with managers, high-level executives, and workers/contractors from different teams that use open source in their day-to-day operations, or whose strategy involves dealing with open source projects (in terms of licenses, security vulnerabilities). Use the insights from these conversations to define the organization’s unique motivators and map them to areas within the organization where open source brings value.

This will also help to build support for your work across the business even before the OSPO is officially created and launched.

Map these motivators with different activity types across the organization, by using the OSPO Maturity Model and creating a second division that categorizes each of these unique motivators according to the different stages. Use this as a reference when you are engaging and communicating with your stakeholders.

For example:

Possible Problems and How To Overcome Them

Problem

While creating the OSPO you are getting lots of questions and having to adapt your plan to take into account new information. It seems there is a lack of consistency in how open source understanding and value are perceived across the organization, leading to confusion and potential risks.

Recommendation

Ensure that you take the time to identify all your stakeholders and understand their motivations. Create publicly available open source manifestos, principles, and websites as an effective way to foster a common understanding of values, principles, and goals among all teams and subsidiaries. Taking time to establish and enforce a consistent understanding of open source throughout the organization will ensure a stable and strong foundation for the OSPO.

Resources and Footnotes

Resources

• TODO guide to outbound OSS: https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/
• TODO guide to participating in open source communities: https://todogroup.org/resources/guides/participating-in-open-source-communities/
• DevOps uses Capability, not Maturity: https://octopus.com/blog/devops-uses-capability-not-maturity
• Porsche Open Source Website: https://opensource.porsche.com/
• The Evolution of the OSPO: https://linuxfoundation.org/tools/the-evolution-of-the-open-source-program-office-ospo/
• OSPO 101 training module - OSPO and your organization: https://github.com/todogroup/ospo-career-path/tree/main/OSPO-101/module3

Footnotes