What is an Open Source Program Office (OSPO)?

Compliance 

Modern organizations understand their increasing reliance on open source but have critical questions about risk and governance. OSPOs can raise and address questions such as:

• What open source software do we use, and are we in compliance with its license requirements?

• What open source software are we producing or contributing to?

• Are all our open source dependencies patched from known vulnerabilities and up to date?

• What open source projects could we use to accelerate our software development?

Contributions

Relying on open source can also mean participating in the community by contributing changes to the projects you depend on. These changes could be bug fixes, security patches, documentation updates, or new features. OSPOs help guide organizations and employees on best practices for contributing changes, particularly when the project requires an individual or corporate Contributor License Agreement.

Collaboration

OSPOs work to guide organizations through questions like these, connecting people, communities, and departments like legal, engineering, and security along the way. If these questions are important to your organization, consider building an OSPO.

OSPOs can help reduce legal risk by setting OSS policy, educating developers, and automating compliance. Developers can benefit from guidance on what project licenses are acceptable for specific use cases so that the business strategy is aligned with engineering decisions about when and how to use open source.

OSPOs play a key role in development collaboration. Promoting the use of open source within the organization generates development collaboration with employees and open source communities. OSPOs can also drive development collaboration by coordinating innersource programs where common needs across multiple teams are identified and solutions are developed and shared internally.  

One part of what OSPOs do is to create a paved path for making company projects publicly available as open source. This aims to share openly with the world what may be beneficial to others. However, not all projects an organization develops are appropriate to share with the whole world, so innersource becomes an extension of the open source program that helps development collaboration grow but stays limited to the organization's staff. Both models accelerate development collaboration, although with different scopes. For example, establishing asynchronous development workflows are beneficial for both open source and innersource because it allows for collaboration that is not restricted by geography, timezone, or location. There is much more to say about innersource, available on the innersource resource page.

Open source compliance is just one part of what OSPOs do. It’s often the first thing an OSPO does, but it doesn’t stop there. OSPOs participate in the life of a new open source project by offering guidance, templates, and knowledge about what has served other open source projects well. Developers starting an open source project have excellent skill sets in creating the code and writing documentation, but supplementing those skills with community building, marketing, and at-scale maintainership can be pivotal in an open source project reaching its goals.

There is no one right answer, as it depends on each organization. Though, we’ve seen several  different patterns. Common reporting structures include the OSPO within a research and development engineering department, directly under a Chief Technology Officer, or in the legal department. Alternatively, some organizations have opted for a virtual team model, where representatives from different departments make up a virtual OSPO. Regardless of organizational reporting structure, a successful OSPO must partner with a diverse set of departments within their organization. A deeper dive into this topic can be found in the Linux Foundation’s research on OSPOs.