Organizations create Open Source Program Offices (OSPOs) to oversee open source software management and strategy. This often includes oversight of a company’s open source library selection, license compliance workflows, relationship with the broader open source software (OSS) community, and more.
The rise of the Open Source Program Office stems from the fact that in today’s world of application development, there’s rarely a company — or product — that doesn’t use OSS. In fact, it’s estimated that upwards of 90% of the components of modern applications are open source, and for good reason. OSS has enabled organizations to reap numerous benefits, including cost savings, improved code quality, and more.
Of course, managing the use of open source software is quite different from proprietary source. OSS users often lack visibility and control over the development roadmap of a given library. Plus, open source comes with various licensing requirements, some of which can be confusing and even onerous.
An OSPO can help organizations implement a comprehensive strategy to address those challenges and maximize the value they gain from OSS. In this blog, we'll explore what goes into building a successful OSPO, such as staffing, strategy, and more.
Download: The Rise of the Open Source Program Office: A Guide to Getting Started
Elements of an Open Source Program Office
Microsoft, Google, Twitter, and Netflix are just a few examples of global enterprises that have Open Source Program Offices. And while every organization — and every Open Source Program Office — operates differently, many OSPOs embrace two strategic anchors: comply and contribute.
Here’s a look at each.
Comply: Open source software is free to use, but comes with an important responsibility: to comply with licensing requirements. Given the number and variety of licenses — not to mention the difficulty of unearthing deep dependencies — this can sometimes be easier said than done. And, organizations that don’t comply with licensing requirements may be at risk of potential litigation or reputational damage.
Open Source Program Offices are often tasked with developing and implementing processes that govern license compliance. This can include everything from determining which licenses can be used with which projects, to overseeing how teams track their open source components and dependencies, and plenty in between. OSPOs may also be responsible for evaluating software composition analysis tools that can simplify compliance workflows and processes.
Contribute: One of the main reasons why open source has thrived in recent years is the sizable community that supports it. As the chart below illustrates, there are hundreds of thousands of active OSS contributors working on a wide variety of projects.
The OSS community is a diverse group that includes everyone from individual developers to large enterprises that sponsor various projects. And, contribution is a core pillar of the open source community mindset. An important part of this pillar is establishing processes for engineers to contribute to OSS projects. This is the case for two main reasons:
- Your engineering team may need to contribute or adapt open source projects to successfully integrate them into proprietary software. Contributing is also a way to help future-proof your decision to leverage specific open source components.
- Top engineering talent is drawn to companies with strong open source programs. Smart developers are drawn to smart code — which is visible if it is open sourced.
Of course, encouraging your developers to contribute to OSS projects also helps build goodwill with the open source community. Other ways to give back include publishing guides and stories of their success creating open source management programs, sponsoring events for open source projects, and donating to open source projects.
Staffing an Open Source Program Office
The number and type of employees who comprise an Open Source Program Office often vary based on the size and priorities of an organization. Generally, however, OSPOs include the following roles and functions:
- Program Manager
- Legal/Compliance Support
- Developer Advocate/Coordinator
- Executive Sponsor
Program Manager: As the title implies, the OSPO Program Manager is generally responsible for overseeing program initiatives, advocating for resources, and managing an organization’s open source strategy. This individual should be especially mindful of how the OSS strategy connects to an organization’s broader business goals, including revenue targets, recruiting efforts, brand awareness, and engineering excellence.
Legal Support: Whether an in-house lawyer, outside firm, or both, legal support is an important part of a strong OSPO. The legal role partners closely with the Program Manager to define policies that govern OSS use, including which open source licenses are permissible for each company product, how to (or whether to) contribute to existing open source products, and which licenses should be utilized when publishing internal products to the open source community.
Developer Advocate/Coordinator: The role that product and engineering play in an OSPO varies from company to company. But regardless of the specifics, those teams will play important roles in a successful OSS program. This is true for many reasons. For one, an OSPO Program Manager may look to implement new tools and processes that directly impact development workflows. The Program Manager will need to work hand in hand with product and engineering to connect workflows and ensure policies and tools are implemented in a developer-friendly manner. Along those lines, development teams are tasked with actually executing code changes and updates that stem from OSS compliance/security initiatives, so it’s critical that there’s a direct line from Program Manager/legal to developer.
Executive Sponsor: As is the case with most any initiative, an Open Source Program Office can only maximize its impact with the support of company leadership. That’s why executive buy-in is so critical. Due to the nature of the OSPO’s function within a company, the VP of Engineering, CTO/CIO, or Chief Compliance/Risk Officer are logical candidates to fill this role.
Building an Open Source Program Office: Additional Resources
For more information on creating an Open Source Program Office, check out the following resources:
Whitepaper: The Rise of the Open Source Program Office: A Guide to Getting Started
Description: Explore the “who,” “why,” and “how” of starting an Open Source Program Office in your organization.
Blog: Takeaways from ISO/IEC DIS 5230: OpenChain Specification
Description: The recently published ISO/IEC 5230 is an international standard that outlines elements of a successful open source license compliance program — and, as you might expect, there’s plenty of overlap with the mission of an OSPO.