Definitions and Keys to Success of Open Source Program Office (OSPO)

Open-source software is fundamentally different from proprietary software. Often, different teams use and/or build open-source differently. Because of this variability, it needs to be approached differently. Managing this strategy is the job of the OSPO (Open Source Program Office). But what is an OSPO? And how do you build one? The Rise of the Open Source Program Office discusses:

• Things to know when evaluating your need for an OSPO
• Areas managed by an OSPO
• Roles key to an OSPO’s success
• The key pillars of a successful OSPO
• A list of resources to read if you want to build an OSPO

At a high-level, an OSPO is a cross-functional team embedded in your company that helps dictate the open-source strategy and policies and is a key element in ensuring your company is prepared for future evolutions.

Managing your open source program is all about improving efficiency and decreasing risk. Determining factors such as which open-source licenses are appropriate, whether or not your full-time employees should be contributing to a major open source project, and determining what components will best accelerate your products growth, quality, or security all have implications on both your product’s viability and competitiveness, how your internal resources are being used, and what the risk profile of your company. An OSPO helps to define your open source management strategy.

Content Summary

A Guide To Getting Started
How Do You Get Started?
Set an initial goal
Find the right people
Executive Sponsor
Key Pillars Of A Successful OSPO
Tackling the Pillars
Compliance
Contribute
Care

A Guide To Getting Started

Managing your open source program is all about improving efficiency and decreasing risk. Determining what packages to leverage when developers should contribute, and what internal projects you may want to publish are all strategic business decisions. The decisions around open source usage and contribution should be a part of broader strategic company decisions. Determining factors such as which open-source licenses are appropriate, whether or not your full-time employees should be contributing to a major open source project, and determining what components will best accelerate your products growth, quality, or security all have implications on both your product’s viability and competitiveness, how your internal resources are being used, and what the risk profile of your company is.

Open source is not going away. Quite the opposite is happening, and enterprises are working to find the right way to work within the open-source community. At a high-level, an OSPO is a cross-functional team embedded in your company that helps dictate the open-source strategy and policies and is a key element in ensuring your company is prepared for future evolutions.

What Is An OSPO?
Open-source software is fundamentally different from proprietary software. Sometimes the open-source is owned by internal employees, sometimes it’s not. Sometimes your company influences the roadmap, sometimes not. Often, different teams use and/or build open-source differently. Because of this variability, it needs to be approached differently. Managing this strategy is the job of the OSPO (Open Source Program Office).

What Does An OSPO Manage?

• Oversight of open-source package selection, based on both usage and licensing requirements, for use in the development
• Enablement for development acceleration based on open source usage to meet business goals
• Oversight of corporate risk profile against open source license compliance and release schedules
• Stewardship of corporate open source ethics and “good citizenship” within the open-source community including contributions back to the community

Open-source programs are an emerging and critical part of a company’s software strategy. Industry leaders in tech like Microsoft, Google, Twitter and Netflix, as well as industry leaders in more established industries like Samsung, Comcast, and Intel have all established open source program offices (OSPOs). Outside of these giants, over 50% of “large” companies across tech, consumer electronics, financial services and telecom are establishing or planning to create an OSPO.

The key pillars of a successful OSPO are:

• Comply: Be a responsible member of the open-source community.
• Contribute: Build in a process for your engineering team to contribute to current open-source projects.
• Care: Give back to the community, whether it is through publishing open source projects, sponsoring open source developers, or hosting open source events.

“We seek to create a working environment that talent wants to be part of. Our engineers know that they work in an open source-friendly environment where they are supported and encouraged to work with the open source communities that are relevant to their work…“ – Gil Yahuda, Verizon Media’s OSPO leader

What Is Enterprise Open Source Being Used For?

• IT Infrastructure Modernization: 53%
• Application Development: 43%
• Application Integration: 43%
• Application Modernization: 42%
• Digital Transformation: 42%
• DevOps: 40%

How Do You Get Started?

Set an initial goal

Determine what priority aligns most with company goals. For many companies, getting started means coverage against the risk associated with open source compliance and/or open-source security. For others, the number one priority might be launching an open-source project or recruiting top open-source talent. This is variable based on processes already in place and your company’s overarching initiatives.

Once you have your goal, determine initial success criteria. Examples include:

• The mandate to decrease compliance risk for internal products
• Improving the ratio of internal to external contributors to your open source project as a demonstration of market adoption
• Targeting several external adapters for your open source project
• Developing a recruiting goal around open-source talent and leveraging your reputation in the open-source community

Find the right people

The OSPO is typically staffed with personnel from multiple departments within the company, and should not strictly be the domain of the development team. It should include one or more of the following roles:

Program Manager: It should be this person’s full-time responsibility to quarterback all program initiatives, advocate for resources, and help manage the strategy for open source at your company. They should dictate how open source strategy aligns with your overarching business goals from revenue targets, to recruiting efforts, to brand awareness, to engineering excellence.

Legal Support: While it is near impossible to embrace modern development practices without adopting open source software, leveraging open source technologies does not come without risk. Open source licenses should be viewed similarly to patent or copyright law. Each license includes instructions on how open source components can be used and the additional obligations that are required to adhere to the license. A failure to comply can result in the missed business opportunity or loss of revenue (failed acquisitions or IPO challenges, or sales that are lost due to open source compliance requirements), legal actions (loss of IP ownership, damage to reputation which could have revenue or partnership impacts, fines, etc.), and damaged engineering brand which could negatively impact recruitment efforts in competitive areas.

Good open source policies include legal counsel on 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.

Product and Engineering Support: The role that product and engineering plays in an OSPO varies from company to company, depending on company size and team structure. First and foremost, there needs to be product/ engineering buy-in for any processes, systems, and strategies. Without that, your program is unlikely to succeed. In some companies, an OSPO will even have an engineering team owning any open source contributions.

IT: From DevOps to Security, having support from the IT department is key. An OSPO may be tasked with implementing internal tools to improve developer efficiency, monitor open source compliance, or dictate open source security measures. IT is key in helping to connect workflows and ensure policies are implemented in a developer-friendly manner.

Top Benefits Of Using Enterprise Open Source Solutions And Technologies:

• Lower Total Cost of Ownership: 33%
• Access to the Latest Innovations: 29%
• Better Security: 29%
• Higher Quality Software: 26%
• Access to Enterprise Level Support: 25%
• Ability to Customize Applications: 25%

Executive Sponsor

For any program to get the resources it needs to be successful, executive buy-in is critical. Depending on your first initiative, this executive sponsorship can lie in several different roles:

VP Engineering and CTO: Open source initiatives frequently map to engineering excellence. Not only does having a strong open-source program improve software developments (building towards any engineering excellence initiatives), but strong open-source programs often attract great engineering talent.

CIO: Open source initiatives also have strong ties to IT initiatives, from developer efficiency to modernization efforts. A recent survey found that 53% of Enterprise IT leaders are using open source to modernize IT infrastructure, 42% are using open source for digital transformation efforts and 40% are using open-source software for DevOps. Finding a way to streamline usage, governance, and adoption of open source is key to the success of many IT teams.

Compliance & Risk: For many companies, the first initiative under an open-source program is to ensure open source compliance and limit a company’s risk exposure. This falls squarely under a Chief Compliance Officer’s mandate.

Key Pillars Of A Successful OSPO

There are three key pillars to successfully run OSPOs: comply, commit code, and contribute.

Comply: Be a responsible member of the open-source community. Use open-source components in adherence with their respective licenses. Not only does this ensure you are in good standing with the open-source community and improve your brand reputation, but this is also key to limiting your company’s risk profile.

Contribute: Build in a process for your engineering team to contribute to current open-source projects. There are several legal policies around copyright and intellectual property that dictate a clear policy be in place before your engineers can contribute to existing open-source projects.

Care: Give back to the community, whether it is through publishing open source projects, sponsoring open source developers, or hosting open source events. There is no right way to give back to the community, so figure out what aligns with your business strategy.

Tackling the Pillars

Compliance

Although each company is different, open source compliance is key for everyone. Open source compliance can dictate what companies you can sell to or partner with, what your company valuation is in a merger or acquisition (high risk means lower valuation), and what exposure you have to potential litigation or reputation damage. For most companies, tackling compliance is (and should be) the first mandate of an OSPO. Open source compliance is also a more concrete and actionable initiative and is great for establishing early OSPO wins.

To become a responsible consumer of open source you need to develop an understanding of open source licenses—we recommend perusing tldrlegal.com or reading Open Source for Business: A Practical Guide to Open Source Licensing by Heather Meeker. Leveraging this understanding of the intricacies of various licenses, create policies around which licenses are appropriate for different projects. Licensing is extremely nuanced and different licenses are often permissible for one company project, but not another.

For advice on developing policies, read or listen to Kate Downings talk on developing a comprehensive third-party package policy.

Once you understand what types of open source are permissible, you need to understand what open source your company is using.

Rather than a manual approach, we recommend leveraging an open-source management tool that can automate generating lists of open source dependencies. Since modern software development practices promote CI/CD (continuous integration, continuous delivery/continuous deployment), ensuring your lists are continuously updated with new code commits is crucial to maintain compliance.

Finally, develop processes to ensure your open source dependencies are compliant. This is frequently the most difficult part. You will want to ensure the processes you develop are efficient, scalable, and automated. Key areas to focus on when developing a system are minimizing developer workflow interruptions, minimizing manual resolutions, and streamlining communications across the teams involved (generally IT, engineering, and legal).

Though many companies start this process by leveraging spreadsheets and manually tracking down dependencies, it is better to leverage software (such as FOSSA) to improve both efficiency and accuracy.

Contribute

The contribution is a core pillar of the open-source community mindset. However, the extent to which a company contributes varies. It is up to your OSPO to determine the correct strategy for your company. No matter the extent of contribution, it is valuable to have painless processes in place for engineers to contribute.

Building strong processes that empower your engineers to contribute code is important for two main reasons. First, your engineering team may need to contribute or adapt open source projects to successfully integrate them into proprietary software. A great example of this is FOSSA’s CLI. Because it is open-source, engineering teams can contribute to ensuring it easily integrates into their build systems.

Contributing is also a way to help future-proof your decision to leverage specific open source components. When you contribute to a project with enhancements, your contributions are likely to be included in future versions of the open-source project. Furthermore, your contributions may be extended by extremely talented engineers across multiple organizations.

Second, and almost more importantly, 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 the top 30 tech companies, over half of them have open-source programs. This is best stated by Gil Yahuda, Verizon Media’s OSPO leader … “We seek to create a working environment that talent wants to be part of. Our engineers know that they work in an open-source friendly environment where they are supported and encouraged to work with the open-source communities that are relevant to their work.”

Ensuring your contribution process is easy and painless is crucial for engineering adoption. There are several resources available for developing internal policies. Google’s guides are all publically available here. We recommend working with open-source lawyers to create policies to ensure you are not publishing proprietary code.

Care

Finally, establish a means of giving back to the community. Whether or not this means developing your open source project depends on your business, but finding strategic ways to support the community is highly leveraged for both recruiting and ensuring popular projects you rely on have the support and resources they need to be maintained. Some examples of ways companies have given back to the community are publishing guides and stories of their success creating open-source management programs, sponsoring events for open source projects, and donating to open source projects.

Source: Fossa