Managing the use of open source software and decreasing compliance risks is key to the success of any software product. An open source program office can help an organisation do just that. Find out how.
Open source software (OSS) is integral to building a modern software solution. Be it an internal or a customer facing solution, organisations rely significantly on open source software today. OSS components are governed by their unique licence terms, and non-compliance with these can often expose organisations to security and intellectual property (IP) risks which eventually may hamper a company’s brand value.
When development teams are delivering a software release, they are primarily trying to meet project deadlines. Therefore, the tracking of versions of components and libraries, or the third party code pulled into the project, is not as rigorous as it should be. This means that licences and vulnerable OSS components can enter the code base and be delivered to customers. This can be risky for both the customer and the company delivering the software solution.
Another increasingly challenging area is that of developers contributing to open source projects. Companies can reap numerous benefits if they do so. This includes keeping skills current, retention of staff, attracting developers to work for the organisation, and improving the image of the company. Many open source projects require developers to sign a contributor licence agreement. This states that any IP created by the developer belongs to the project and not to the contributing developer. In this scenario, organisations need to be careful that IP and trade secrets that are not open source are not being signed over to open source projects.
Developers need to be educated about open source licensing issues, determining what to leverage, when or how much they can contribute to the community, and what packages might bring risk to the organisation’s reputation. All this can be streamlined by putting a strategic policy and operations in place. One way of doing this is by creating an entity that is dedicated to working around all things open source—an entity called the open source program office (OSPO).
An OSPO creates an ecosystem for employees to use open source software in a way that compliance risks are kept at bay. The role of an OSPO is not limited to supervising open source usage; it is also responsible for contributing back to the community and managing the company’s growth in the market by actively engaging in events, as well as conducting webinars and campaigns.
In this article we will see why there is a need for building an OSPO, and how it has emerged as a prominent entity for any open source policy and governance programme.
Why should you have an OSPO?
With the wide use of open source software, regulating its usage and keeping the compliance strategy in check can be often overwhelming for the teams involved in the product development cycle.
Developers often overlook licence obligations, and sometimes the management or stakeholders are also not fully aware of the implications of non-compliance with these open source licences. OSPO handles open source software right from its on-boarding till the time it is delivered to the end user and everything inbetween, irrespective of whether it is being used for internal or external purposes.
An OSPO builds a solid foundation by starting compliance and regulatory checks in the early software development life cycle. This usually begins by guiding and aligning the involved team members towards a common path that benefits the organisation’s values. The OSPO puts in place policies and processes around open source usage and governs the roles and responsibilities across the company.
To conclude, it aligns the efforts of all relevant teams involved in building the product and helps increase the organisation’s capacity for better and effective use of open source.
| The rise of the OSPO |
| Companies like Microsoft, Google and Netflix have well established OSPOs within their organisations. Many others, like Porsche and Spotify, are building their own OSPOs to leverage the usage of open source in an efficient way.
Here is what leaders from renowned companies have to say about OSPO practices.
|
The function of an OSPO
The function of an OSPO may vary from organisation to organisation depending on the number of its employees and the number of people that are part of the OSPO team. Another factor is the purpose of using open source. An organisation may only want to use open source software for building the product or may also look at contributing back to the community.
Evaluating factors such as which open source licences are appropriate or whether full-time employees should be contributing to an open source project may be part of the OSPO’s role. Putting a contributor licence agreement (CLA) in place for developers that are willing to contribute and determining what open source components will help in accelerating a product’s growth and quality are some other roles of an OSPO.
Some of the key functions of an OSPO involve:
- Putting an open source compliance and governance policy in place to mitigate intellectual property risks to the organisation
- Educating developers towards better decision-making
- Defining policies that lay out the requirements and rules for working with open source across the company
- Monitoring the usage of open source software inside as well as outside the organisation
- Conducting meetings after every software release to discuss what went well and what could be done better with the OSS compliance process
- Accelerating the software development life cycle (SDLC)
- Transparency and coordination amongst different departments
- Streamlining processes to help mitigate risks at an early stage
- Encouraging members to contribute upstream to gain the collaborative and innovative benefits of open source projects
- Producing a report with suitable remediation and recommendations for the product team
- Preparing compliance artifacts and ensuring licence obligations are fulfilled
Building an OSPO
The OSPO is typically staffed with personnel from multiple departments within the company. The process involves training and educating the relevant departments regarding open source compliance basics and the risks involved in its usage. It may provide legal and technical support services so that the open source requirement goals are met.
An OSPO may be formed by the following people within the organisation (this is a non-exhaustive list of people who can be a part of it):
- Principal/Chief: This role can be taken by the flag bearer, the one who runs the OSPO. The chief knows the various aspects of using open source like the effect of using different components, licence implications, development and contributing to the community. These requirements are entirely dependent on an organisation’s needs.
- Program manager: The program manager sets the requirements and objectives for the target solution. He/she works alongside the product and engineering teams to connect workflows. This includes ensuring that policies and tools are implemented in a developer-friendly manner.
- Legal support: Legal support can come from outside the firm or in-house, but is an important part of an OSPO. The legal role works closely with the program manager to define policies that govern OSS use, including which open source licences are allowed for each product, how to (or whether to) contribute to existing open source projects, and so on.
- Product and engineering teams/developers: The engineering team should be well-versed with open source licence(s) and their associated risks. The team must seek approval from the OSPO before consuming any open source component. The team may have to be trained with respect to open source compliance basics and its usage at regular intervals
- CTOs/CIOs/stakeholders: A company’s leadership has a huge impact on the OSPO strategies. The stakeholders have a great say in the decision making process for any product/solution’s delivery. Due to the nature of the OSPO’s function within a company, the VP of engineering, CTO/CIO, or chief compliance/risk officer must get involved in the OSPO.
- IT teams: Having support from the IT department is very important. An OSPO may be tasked with implementing internal tools to improve developer efficiency, monitor open source compliance, or dictate open source security measures. IT teams are key in helping to connect workflows, and ensure policies are implemented in a developer-friendly manner.
In the 2021 State of OSPO Survey conducted by the TODO Group, the key findings were:
- There are many opportunities to educate companies about how OSPOs can benefit them.
OSPOs had a positive impact on their sponsor’s software practices, but their benefits differed depending on the size of an organisation. - Companies that intended to start an OSPO hoped it would increase innovation, but setting a strategy and a budget remained top challenges to their goals.
- Almost half of the survey participants without an OSPO believed it would help their company, but of those that didn’t think it would help, 35 per cent said they haven’t even considered it.
- 27 per cent of survey participants said a company’s open source participation is very influential in their organisation’s buying decisions.
The use of open source software when building any software solution is almost inevitable today. However, the open source licence risks cannot be overseen. What is needed is a strategic streamlining process that helps combat the compliance issues that come in the way of using open source components effectively.
An OSPO helps set a regulatory culture by building a centralised dedicated team that educates employees and brings awareness regarding everything related to open source usage in an organisation. An OSPO can also work as a guide to fetch top talent from the industry, which will eventually be a boon for business goals.Sakshi Sharma
