The Value of Open Source Program Offices
- Open Source is All About Integration
- The Value of an OSPO
- Reasons Behind Starting an OSPO
- Reasons Behind Sustaining an OSPO
- Assessing Value of Open Source Activity -
✅ Assessment
- Recommendations -
💡 Recommendations
- Resources -
📚 Continue Here
Open Source is all about Integration
Organizations of various types—including end-user companies, software vendors, universities, and public administrations—maintain a relationship with open source. To responsibly manage not only software but also hardware, content, and other aspects of technology, organizations must engage with open source. This involves finding ways to integrate such culture and operations into their IT strategy and technology and AI stacks. Establishing an organizational structure is a crucial first step to solidify commitment. This is where an Open Source Program Office (OSPO) becomes key. It serves as a means for organizations to support their objectives and address challenges related to open source.
💡 OSPOs are all about Integration, not Isolation
Supply Chain and Open Source
Sometimes, organizational stakeholders may assume that they do not use open source projects because their end product is proprietary. However, a closer examination of the entire software supply chain often reveals that such proprietary software contains open source dependencies or other artifacts that form the baseline. If the contributors working on those open source projects were to leave, the project could become obsolete or a target for security vulnerabilities. This, in turn, would affect the proprietary software the organization uses or sells, directly impacting its reputation, performance, or revenue
Below are common situations where an organization, aiming to manage open source for integration into its digital/IT strategy and technology infrastructure, may encounter issues. If ignored or neglected, these issues can lead to mid-term and long-term innovation bottlenecks and security vulnerabilities.
-
Vulnerability Management: keeping track of the open source usage (software, hardware, etc) by the organization and performing risk assessments on the identified projects. By identifying key projects within the organization, they can prioritize securing them by tracking common vulnerabilities and exposures.
-
Complexity of the open source supply chain: Its widespread distribution, collaborative efforts that are often decentralized, and the anonymity of its contributors make it challenging for organizations to accurately assess risks and comprehend the security and quality standards of the software, hardware, data, etc.
-
Tension between the need to ship product features and the need to contribute back to open source: Open source contributions may take a back seat when dealing with multiple day-to-day tasks.
-
Collaboration with the community and industry: Having the organization provide resources whether that’s coding, expertise, or money donations as incentives for fixing common vulnerabilities and exposures that can occur in the projects the organization relies on (see Log4Shell real vulnerability example) in a timely fashion, as well as collaborations with industry working groups foster cooperative efforts to address security concerns holistically.
-
Procurement processes with never-ending steps: Open source is a dynamic ecosystem whose contributions should occur as smoothly and naturally as possible. The long procurement processes faced in highly regulated environments, such as finance companies and governments, create a barrier to open source contribution and engagement.
-
Lack of consciousness about organizational responsibility: Due to the way open source was taught in the past, engineering-based tools, or even the engineering jargon used, the concept of open source may not be taken seriously in other areas of the organization involved in decision-making processes, management, or policy making.
To fully overcome these and other challenges, organizations must be equipped to manage open source operations on both cultural and practical levels. The how of accomplishing this is often through the OSPO, as it fosters committed, cross-functional collaboration within the organization to address open source issues encountered by various teams or departments.
💡 OSPOs foster cross-functional collaboration
But how exactly can an OSPO enable cross-functional collaboration? Why and how does this cross-functional collaboration aid in achieving the organization’s goals? Additionally, why is this cross-functional collaboration essential for the creation and long-term sustainability of an OSPO within the organization?
The value of an OSPO
To understand the value of an OSPO, it is important for the reader to understand the reasons for (1) Establishing an OSPO and (2) Sustaining it over the long term.
In this book, the section on starting an OSPO is aimed at organizations that are taking their first steps toward creating an OSPO. This means that even if they already have personnel dedicated to dealing with open source tasks from time to time, they still lack a structured and specialized unit (or units) within their organization. On the other hand, the section on sustaining an open source through an OSPO is more relevant to individuals in organizations that have already established specialized units, covering aspects such as strategy, compliance, community involvement, and governance
In both sections, the emphasis is on the different responsibilities of an OSPO to help manage open source as an ongoing activity and be well integrated into all organization’s units. This responsibility may evolve and become more complex over time, but it is definitely not a temporary task with a predetermined completion point.
Source:OSPOs, key lever for open source sustainability
The reasons behind starting an OSPO
Integrating open source into an organization’s infrastructure and operations is a vast field that encompasses various angles and objectives. The business value of the OSPO report explains some of the reasons shared by Open Source leaders across different industries and organization sizes.
- Building standardized processes around open source
- Learn how to approach the open source community
- Embracing the Sustainability of Open Source Projects
- Managing Compliance
- Expanding access to open knowledge
- Improving development velocity
- Mitigating Security Risks
The reasons behind sustaining open source operations through an OSPO
Stopping the work of an OSPO could have significant negative impacts on those organizations that use open source (directly or indirectly) at any level, including loss of open source expertise, increased security and legal risks, reduced community engagement, and damage to reputation.
💡 Open Source is a silent critical need
An OSPO needs to be an ongoing initiative within an organization in order to evolve its culture and open source knowledge, helping the organization to contribute to and build more secure open-source software, as well as improving the sustainability of open-source projects.
The different roles and pillars of support of an OSPO shared below can help readers understand why it should be viewed as a critical area to maintain and nurture within an organization, rather than just a pet project with an expiration date.
-
Acts as a Counselor: Sometimes a strategic approach just means stepping back and taking the time to think through some of the hard questions about what type of engagement model is right for any particular project or how involved the organization should be in each project. There is also the question of when it makes sense to contribute to an existing project versus creating a new project. An OSPO that is having these strategy-level conversations will be able to provide guidelines to workers at the different teams so that workers do not have to consider the business implications of different open source engagement models every time they try to solve a problem
-
Acts as a Facilitator: The OSPO also plays a sort of translation role between Organization’s teams and decision makers' interests regarding open source and the needs from the open source community. They also help organizations navigate the cultural, process, and tool changes required to engage with the open source community effectively and in a healthy way.
-
Acts as an Advocate: OSPOs can promote the use and/or contribution of open source and best practices across different organizational units. This can help organizations realize the benefits of open source as well as engaging people to contribute to open source projects or start new ones
-
Acts as an Environmentalist: OSPOs can help organizations support and sustain open source projects in the long term by addressing issues such as security, maintenance, and project health. This can help ensure that open source projects remain healthy in the long term and continue to benefit the wider community.
-
Acts as a Gatekeeper: OSPOs can help enforce OS policies and strengthen OS governance. This can help organizations to ensure compliance and mitigate OS security risks.
[Apendix A] A perspective of open source in public administrations
We can see that more public sector organizations are realising the value of an Open Source Programme Office to not only achieve their digital policy goals to better serve their citizens but also to transform their organizations toward achieving these goals. Public sector organizations face unique challenges when it comes to managing their open source operations, including the need to comply with strict laws and regulations, and the requirement to provide transparent and accountable operations. An OSPO can help governments and public sector organizations to overcome these challenges.
-
Improved Compliance: An OSPO helps to ensure that their open source operations are compliant with relevant laws and regulations, including data privacy laws, procurement regulations, and transparency requirements. This helps organizations to avoid costly legal and regulatory challenges, and to maintain their reputation as responsible public sector organizations.
-
Increased Collaboration: An OSPO helps to foster collaboration between different departments and with external stakeholders, including other public sector organizations, open source communities, and civil society organizations. This increased collaboration helps organizations to access a wider pool of talent and resources, and to develop better open source solutions.
-
Better Resource Allocation: An OSPO helps to allocate resources more effectively, ensuring that open source operations are well-supported and that key initiatives are given the resources they need to succeed. This helps organizations to maximize the benefits of open source technology, and to drive innovation and growth.
-
Improved Service Delivery: An OSPO helps to improve the delivery of public services, by enabling them to adopt innovative and cost-effective technologies, and to collaborate with external stakeholders to develop better solutions. This helps organizations to provide better services to citizens, and to meet the changing needs of their communities.
The European Commission’s Open Source Program Office (OSPO) has launched a new portal that serves as a wiki or knowledge archive, providing up-to-date information on advancements in OSPO-related topics for public administrators. This portal offers a variety of resources, including useful studies, presentations, use cases, guides, and more, to readers interested in learning more about OSPO-related topics. Check 📚 Continue Here
at the end of this chapter.
[Appendix B] A broader view of open source
By extending the concept of open to encompass (for instance) open research, design, or access, we can identify additional benefits that these practices bring to organizations. This broader view of openness is gaining traction in academic and public sectors, where terms other than open source are sometimes used instead, such as open technology or open work. However, since these terms are not as well-known among organizations, many of them still use open source as a term to indicate activities beyond software.
Source: Khalil Khalaf - The Pros and Cons of Open Source Software
Note: You may have noticed that in this book, when referring to open source, we also include other kinds of open initiatives beyond software, such as hardware, data, etc.
Assessing the value of open source usage (also called consumption)
✅ Assessment
Organizations may underestimate how much they already depend on the usage (also called consumption) of open source. There are some studies which analyze usage of open source software in the industry. The Synopsys Open Source Security and Risk Analysis Report 2022 for example finds that the average software project consists to 78% of open source software.
Assess this value for your own organization by taking steps such as:
- Collect information about open source software used by your development and operations teams
- Get clarity about composition of commercial software you buy or services you use, ask vendors for what open source software they use, e.g. by requesting Software Bill of Materials (SBOMs)
- Assess value by evaluating what costs would occur by using alternative proprietary solutions and components
- Take factors such as speed of innovation or engineering agility into account
This is an example of the activities an organization will perform at the consumer stage in the open source maturity model. This naturally leads to the next step to the participant stage:
Assessing value of open source contributions
✅ Assessment
Despite an organization might be aware of the general problems, responsibility and benefits that contributing to open source provides, identifying specific key motivators to move people to take action (create activity) and prioritize open source is a tough task. In this section, we will assess a 4-step process for communicating the value of contributing to open source and going beyond, which the OSPO can use when working with the different teams that engage with open source. (Source: ospo-book mailing list discussion)
Step one: Assess open source activity engagement
Get familiar with maturity models of open source adoption. These levels describe how open source is used in an increasingly effective fashion to drive value and address organization’s needs. One of the distinguishing factors for the different maturity levels is how open source contribution and creation are handled in an organization.
For instance, a typical maturity model of corporate open source adoption looks like this (see this example by Dr. Ibrahim H):
- Denial - No or unconscious use of open source
- Consumption / Usage - Passive use of open source software
- Participation - Engagement with open source communities
- Contribution - Pragmatic contributions to open source projects
- Leadership - Strategic involvement with open source to drive business value
Step two: Identify and categorize the benefits of open source activities for your organization
Once you have a certain familiarity with open source adoption models, the next natural question to ask is What are the benefits of open source activities for the organization?
The OSPO Japan Local Meetup Working Group, supported by the TODO Group and OpenChain, meets on the fourth Friday of every month. The group 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.
You can find a summary of their work in both Japanese and English in this Qiita article written by one of its members
Step three: Initiate conversations and define unique motivators
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
Step four: Map motivators with different activity types across the organization
Create a second division that categorizes each of these unique motivators according to the different stages within the previously mentioned OSPO model, or a similar model as referenced in step 2. As an example, below is a possible categorization, proposed by one of the contributors to this book
Recommendations
💡 Recommendations
In this section, you will find a series of real-world scenarios that are encountered in open source management across organizations. For each scenario, you can find recommendations from real-world experiences from open source professionals.
Scenario #5
There is a lack of understanding about open source practices across the organization
Recommendation: Promote organizational-wide understanding of open source practices through the OSPO by offering educational workshops, creating accessible resources, and establishing open source champions in different departments to foster a culture of open source literacy
Scenario #6
An OSPO is seen as a Sales Profit or Marketing Tool
Recommendation: Ensure that the OSPO is recognized as an integral part of the organization’s digital, software, or IT strategy, rather than as a sales profit or marketing tool. Emphasize its role in fostering open source best practices, contributing to technological innovation, and supporting the overall organization’s IT / Digital development plan.
Scenario #7
An OSPO is seen as an added value and not as direct support for the core organization’s areas and functions
Recommendation: Highlight how the people behind the OSPO with expertise in open source can enhance key business processes, drive innovation, and directly support strategic objectives, thereby integrating it as an essential component of the organization’s operational framework
Scenario #8
An OSPO struggles with gaining executive support and buy-in
Recommendation: communicate the strategic value of open source through the OSPO, showcasing tangible benefits through case studies or success stories, and aligning its initiatives with key organizational priorities.
Scenario #9
An OSPO has a technical focus and forgets about open source culture
Recommendation: Embrace the full spectrum of open source culture, which includes transparency, diversity, and cooperation. Encourage the organization to foster an environment where these values are actively promoted and practiced
Resources
📚 Continue Here
- Open source and the software supply chain - John Mark Walker
- Strategy: End Game for FINOS Maturity Model - Victor Lu
- Securing the Software Supply Chain: The Role of OSPOs - Jessica Marz
- Simple Frequently Asked Questions OSPO Guide - OSPO SWG Japan
- The Business Value of the OSPO Report - Linux Foundation
- EC Open Source Programme Office - European Commission Joinup
- Public Services Should Sustain Critical Open Source Software - FOSSEPS
- How Governments Want to Use OSPOs to Transform Themselves - Sivan Pätsch
- Open Source Security and Risk Analysis Report 2022 - Synopsys
- Open Technology - Scheerder, Jeroen & Koymans
- The Pros and Cons of Open Source Software - Khalil Khalaf