Open Source has become a major force in the software industry, powering many of the most popular and innovative applications and platforms in the world. From Linux to Android, from Drupal to WordPress, from Kubernetes to TensorFlow, open source software (OSS) is everywhere. It’s estimated that 96% of all codebases contain OSS, and that at least 85% of enterprise codebases are built with open source components.
In its Annual Report 2022, The Linux Foundation celebrates the growth of the global impact of open source, and its increasing adoption by companies and organizations of all sizes. The report also highlights its importance for the future of technology, and the need for companies to have a strategy for managing its use, particularly in the context of compliance, best practices, and security.
In the whitepaper Open Source:The Missing Data and Management Layer the LF states that leading tech companies such as Apple, Meta, Amazon and Google have detailed strategies in releasing, contributing and sponsoring OSS projects and conferences, and it’s becoming a key part of the business strategy also for companies in other industries, such as Comcast, Bloomberg, and BMW.
That’s why a growing number of companies are creating a team dedicated to managing this relationship, and this team is called Open Source Program Office (OSPO).
In this blog post, we will explain what an OSPO is and why it is essential for companies at any stage of OSS adoption.
What is an OSPO?
In The Evolution of the Open Source Program Office the TODO Group, an open community born in 2012 that promotes sustainable OSS adoption and governance within organizations, proposed a Five-Stage OSPO Maturity Model, which describes the evolution of the adoption in companies and can be summarized as follows:
- Stage 0: Adopting Open Source Ad Hoc: the company uses OSS, but there is no formal process for managing it. Developers are free to use it to solve problems, but little attention is given to licence compliance or the long-term impact on the company’s software supply chain.
- Stage 1: Providing OSS Compliance, Inventory, and Developer Education: the company recognizes that OSS is a key part of the business, and that they need to manage the legal compliance, security practices, developer education, and software inventory. The company creates an OSPO team to manage these activities.
- Stage 2: Evangelizing OSS Use and Ecosystem Participation: the company recognizes the importance of open source ecosystem for the business, and turn to the OSPOs to help them understand how to contribute to and participate to projects and events.
- Stage 3: Hosting OSS Projects and Growing Communities: the company hosts or is a primary sponsor of open source projects, dedicating resources to the development of a project and the growth of its community. OSPOs manage the ecosystem, coach project leaders, nurture the community, and seek the assistance of major foundations.
- Stage 4: Becoming a Strategic Decision-Making Partner: the OSPO is a strategic partner for the company, is involved in all major decisions related to OSS, becomes an internal technology consultant to the CTO and takes a leadership role in benchmarking what can be considered a good OSS project.
An OSPO serves as the center of competency for an organization’s open source operations and structure. It is responsible for defining and implementing strategies and policies to guide these efforts. This can include setting policies around code use, distribution, selection, auditing, contributing, and other key areas; providing education and training to people (inside and outside the organization) involved in open source activities; supporting an organization’s efficiency in developing software through encouraging sustainable usage of existing open source components and, where appropriate, contributing enhancements back to these project; when needed, guiding teams with open sourcing their software; ensuring engineering effectiveness; ensuring legal compliance; and promoting and building community engagement.
The OSPO is a unit within a company. It can be a whole team or a single person, depending on the size of the company, the level of OSS adoption, and the company’s strategy. But why is it important to have an OSPO?
Why is an OSPO important?
OSS is a key part of the business strategy for many companies, but it also presents many challenges. Let’s take a look at some of them.
Open source software is governed by various licenses that specify the rights and obligations of the users and contributors. Some licenses are more permissive, such as MIT or Apache, while others are more restrictive, such as GPL or AGPL. It is important to understand and respect the terms and conditions of each license, as well as the compatibility and conflicts between different licenses. Failing to do so can result in legal risks, such as lawsuits, fines, or loss of intellectual property rights.
Open source software is exposed to a large and diverse user base, which can increase the chances of discovering and exploiting vulnerabilities. Some open source projects may not have adequate security measures, such as code reviews, testing, encryption, or authentication. Moreover, some components may come from untrusted or unknown sources, which can pose a threat to the software supply chain. Therefore, it is essential to verify and validate the security of the OSS that is used or produced, as well as to monitor and update it regularly to address any security issues or vulnerabilities .
The Open Source Security Foundation (OpenSSF) is a cross-industry collaboration that brings together the industry’s most important open source security initiatives and the companies that support them. The OpenSSF aims to improve the security of OSS by building a broader community, focused on security best practices, vulnerability disclosure, and security tooling, and it can be a valuable resource for companies that want to improve their security practices: it’s essential for them to understand and manage the software supply chain, and to have a strategy for managing the use of OSS, and it may soon become a law requirement.
Adopting OSS requires a different mindset and skillset than proprietary software. Developers need to be familiar with a new set of values and practices, such as collaboration, transparency, version control, issue tracking, and they need to be proficient in open source tools and platforms that enable communication, documentation, testing and deployment.
Developers need to understand how to write high-quality and maintainable code that can be easily reused by others, how to contribute to open source projects, and how to participate in open source events. OSS is about community, and developers need to learn how to be part of it.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Open source software involves a large and complex network of dependencies and relationships between different components and projects. It can be challenging to keep track of all the open source software that is used or produced by a company, as well as their sources, versions, licenses, security status, and performance metrics. Having an accurate and up-to-date software inventory is crucial for managing the software lifecycle effectively and efficiently, and in some countries maintaining a Software Bill of Materials (SBOM) is a legal requirement.
Open source ecosystem
OSS depends on the active and healthy participation of the open source community. The community consists of various stakeholders, such as developers, users, maintainers, sponsors, foundations, advocates. It is important to engage with the community in a respectful and constructive manner, as well as to contribute back to the community in various ways, such as reporting bugs, providing feedback, submitting patches, donating funds, or hosting events.
This is not only a matter of good citizenship, but also a matter of business. Participating in the open source ecosystem can help to attract and retain talent, to build trust, reputation, influence, and value for the company.
By addressing these challenges, an OSPO can help companies reap the benefits of open source software, while mitigating the risks. An OSPO can also help companies evolve and improve their open source maturity over time. At this point it should be clear that since OSS is vital, companies need to establish a structured way to manage it, and that’s why an OSPO is so important. But how do you create an OSPO?
How to create an OSPO
The TODO Group provides definitions, guides, and case studies of OSPOs already established in various companies. You can take a look at how the OSPO operates in Microsoft, for example.
Image: The OSPO Landscape
The starting point for any company that wants to create an OSPO should be the TODO guide.
As with many other strategic decisions, we think that the company needs to clarify why it wants to create an OSPO and what are its expected outcome and benefits. The OSPO should align with the company’s vision and values, and be a natural extension of its culture, not an isolated unit. The company should also define the OSPO’s mission, goals, and scope.
The company should also define the structure and the location of the OSPO. It can be centralized or decentralized, depending on the size and culture of the company. It can be a cross-functional team, with members from various departments such as engineering, legal, developer relations or marketing, or maybe it will be a single person reporting to the CTO and advising the other teams on open source matters.
The OSPO should be responsible for defining the policies and processes, engage with the internal and external community, foster collaboration, provide the tools and resources to participate in projects and events: this unit needs a good leader, with the right skills and experience and a deep understanding of the company’s business and culture. A good reference for this role is the TODO Group’s Template Job Posting for Open Source Office Lead.
The process of identifying the goals, the structure and the leader of the OSPO should be transparent, because it will have a central role in the company’s strategy and business. It should involve everyone from the CTO to the developers, making sure every input and feedback is taken into account.
Once the OSPO is established, let’s take a look at some of the first activities it should perform.
What does an OSPO do?
There is no one-size-fits-all approach to managing open source software, and the OSPO should adapt to the company’s needs and culture. However, according to various sources, and examples from companies that have already established an OSPO, we can summarize some common activities that an OSPO should perform as first steps:
Assess the current open source situation: it should perform an audit of the company’s OSS, to understand what is used and produced, and how it is used and produced. It should also assess the company’s open source maturity, to understand what is the current level of adoption and what are the strengths and weaknesses. It could use frameworks such as the OSPO Maturity Model.
Get executive buy-in and support: it should engage with the CTO and the other executives, to make sure they understand the importance of OSS for the company’s business, and to get their support and backing for the OSPO’s activities. It needs to demonstrate the value proposition and business case of OSS, and the expected costs and benefits. It also needs to secure the necessary resources and budget.
Build a cross-functional team: even if the OSPO is a single person, this is not a one-persone job, it needs to collaborate with various teams and departments to handle various aspects of open source management. An OSPO would recruit or assign people who have experience and expertise in OSS development, and good communication and collaboration skills, and define a clear reporting structure and authority.
Define policies and processes: it should define the policies and processes for managing OSS, such as the selection, evaluation, and approval of components, the contribution to projects, the participation in events, the reporting of security vulnerabilities, the management of the software supply chain, the creation and maintenance of a software inventory, the creation and maintenance of a software bill of materials, the training of developers, and so on.
These are some of the activities that an OSPO should perform once it is established. Again, the OSPO is not a static or fixed entity, it is dynamic and evolving, because the open source landscape is constantly changing, and the company’s strategy can change as well. So the best advice is to start small, and then iterate and improve over time.
Each company should find its own way, and the OSPO should fit its specific objectives and context.'
If you want to learn more about OSPOs, here are some useful resources:
- OSPONews from the TODO Group
- A Deep Dive into Open Source Program Offices
- Linux Foundation Europe Newsroom
- Voices Of Open Source
We also wrote about software supply chain security in a previous blog post The point of no return for software dependencies, and understanding this topic is essential for OSPOs.
In this post, we saw that OSS is a valuable asset for companies, but also that using and producing OSS also come with some challenges. To address these challenges effectively and efficiently, a growing number of companies are creating a team dedicated to managing the use of open source software, and this team is called Open Source Program Office (OSPO).
An OSPO can help companies maximize their investment in OSS, and reduce the risks of using, contributing to, and releasing OSS. It can also help companies evolve and improve their open source maturity, strategy, governance, culture and operations.
We hope you have enjoyed reading this post and learned something new. If your company already has an OSPO, we would love to hear about your experience, and if you are planning to create an OSPO, we would love to hear about your plans. Feel free to contact SparkFabrik on any of our social channels!
Thank you for your time and attention. 😎