19 The Rise of the Open Source Program Offices (OSPO)

The coming together of the Linux Kernel released by Linus Torvalds in 1991 with the GNU Tools (created in 1984) started the GNU/Linux Operating System (OS). This became a viable alternative for proprietary operating systems and began the era of widespread Open Source use as is further discussed in Chapter 1. The General Public Licence (GPL) discussed in Chapter 4 has been widely adopted and changed how people licensed software. This began a new era in how a significant amount of software is created and consumed. Linux has become an underlying operating system of choice for many products and industries—from the supercomputer to the phones in our hands, and more. And the Open Source way of developing and releasing software has now touched components and technologies in every single area, from cloud to embedded software and even hardware and data.

Fast forward to 2021, and it is hard to find organisations or enterprises that do not use Open Source in some way (see Figure 19.1). Technology companies, in fact, have been using Open Source since the early days. Today, even very traditional industries and governments use Open Source software. What started as cost-savings efforts by systems administrators is now intentionally and proactively used for its ability to accelerate innovation. Digital transformation has skyrocketed the scale of Open Source, in terms of usage and reach. Companies tend to go through a pattern, from usage to contributing to existing projects and open sourcing their own code. This extended usage has awakened a wide range of organisations to the value of hiring and supporting Open Source developers. From legal to human resources, marketing, finance, and customer care (and everything in between), savvy department heads and business owners began to manage all aspects of Open Source more actively and strategically. From the start of this century, we saw the rise of the Open Source manager role in companies using Open Source software.

OSPOs have become de rigeur from 2020 and many organisations wonder how they benefit from starting one and, perhaps, why they should invest in one, especially when they are already consuming Open Source software. What is the advantage of engaging, beyond just downloading and using the code? This is a valid and inevitable question. The biggest reason to do so is to drive product/service intention and strategy proactively, which, incidentally, happens to be the biggest benefit of engaging with Open Source projects. Proactively driving product/service strategy tends to speed time to market, providing a competitive advantage.

What does this mean? When you ask engaged companies where they derive the most value from their own Open Source engagement efforts, they often point to projects that are core to their products—projects that let them collaborate with industry peers, learn, and share their stories, experiences, and lessons through various Open Source foundations and their events and activities. By contrast, opting simply to consume Open Source software without engaging in the process and the community can place an artificial limit on how much value organisations can realise from that Open Source software and their ability to influence.

Here are some drivers that may lead organisations to support the development of an OPSO:

The results of a 2020 study about perceived ROI (return on investment) from Open Source benefits are summarised in Figure 19.2.¹

OSPOs often start with one individual who brings a vision of the scope of the company’s Open Source vision and the OSPO and works hard to customise it for the company’s unique business needs. Not all companies need the same type of OSPO. Each organisation should consider the options and create a model that works well for its individual culture and structure. In particular, an OSPO needs to help align Open Source engagement with the greater business strategy of the company. A centralised model works well in a company where a centre of excellence helps organise and create all policies and processes to manage Open Source work overseen by the company’s engineering organisations. When there are many divisions, each doing vastly different product work, a decentralised model may work best. In companies which have strong functional groups, like legal, marketing, and communications, a matrixed function may work. And in smaller organisations, a volunteer group or part-time OSPO may be most effective.

The scope of OSPOs also varies. Some focus only on compliance and work closely with the legal team and the development teams creating customer-facing products. They either run compliance tooling or build it and help to integrate it into development pipelines, as well as to help teams run scans and publish their disclosures. Often this type of OSPO is developer-heavy, because compliance tooling requires integration, customisation, and scripting to work.

Some OSPOs do a lot of marketing work. They put a specific focus on evangelising the company’s Open Source work by sponsoring events, volunteering to speak at departmental meetings, etc. They leave the consumption, contribution, and compliance of Open Source components to the engineering teams to manage.

Increasingly, OSPOs handle multiple aspects of Open Source. The best way to characterise it is shown in Figure 19.3. Acting as a centre of excellence in all things Open Source, the OSPO guides the company in getting the highest return from the use and adoption of Open Source methodologies.

Large company OSPOs may have functions at the Director and VP (Vice President) levels, which closely coordinate with the CTO and/or Senior Vice President (SVP) of Engineering. These OSPO leaders work closely with leadership to provide an Open Source perspective and to stay aligned with business strategies. Smaller companies may appoint a single person at the Senior Manager level or Principal Engineer level. Because this function stands at the intersection of so many disciplines and impacts company risk, strategy, transformation, and even sustainability, it is a function that needs to ensure its strategy is aligned with company strategy.

It was in the early 2000s that hyperscale technology companies like Google realised that it was beneficial to dedicate a small organisation to help their developers safely and smartly use Open Source and follow licences. Google’s Chris Di Bona is credited with coining the term ‘Open Source Program Office and started with a group of developers who were Open Source enthusiasts. Residing in engineering, they acted as the first line of contact for the hundreds of questions that were coming in from their developers on licences and other Open Source matters. It shielded legal teams from being overwhelmed by developers directly reaching out to them, usually with queries related to various licences. According to Chris Di Bono, who leads the Google OSPO, they saw it as vital way to enable developer productivity and excellence. That early OSPO also started taking on the function of managing Google’s relationship with external development communities on behalf of the company. These were communities of projects that the company used and depended on. More information about Google’s OSPO can be found at: <https://opensource.google/>.

In parallel, Intel created an organisation called ‘OTC’ (Open Source Technology Center) which handled upstream contributions, communicating and advocating for Open Source projects and helping make many projects enterprise-ready. One of the projects Intel championed and continues to Open Source is the Yocto Project, which is a standard for embedded Linux development today. Intel has historically been a prolific contributor to the kernel and a great supporter of many Open Source foundations. Intel’s Open Source work can be found at: <https://01.org/>.

Other OSPOs in the early days include Box, Facebook, Twitter, Sun, and many other mainstream and non-mainstream technology brands. Comcast started working in Open Source in the early 2000s and in 2017 it established the Comcast OSPO because of its scale and strategy to lean-in to Open Source. Along the way, the people running the OSPOs often helped OSPOs in other organisations with questions and best practices. In 2014, a more formal organisation coalesced, called the ToDo Group, during Facebook’s developer conference ‘@scale’. In 2016, the ToDo Group became a project in the Linux Foundation. The goal was to create a neutral place for company OSPOs to share, collaborate on common issues, and promote and support the growth of OSPOs. The ToDo group is one of the best places to learn about how to build and run an OSPO. Its members are generous with their knowledge and time because of their common goal to share and help others to make their OSPOs successful. Many case studies and other information can be found at: <https://todogroup.org/about/>.

The ToDo group defines an OSPO in this way:

An Open Source Program Office (OSPO) is the center of gravity for an organisation’s open source operations and structure. This can include training developers, ensuring legal compliance, engaging with and building communities, and defining policies that govern code usage, distribution, selection, auditing and more. <https://todogroup.org/blog/ospo-definition/>.

Today, large enterprises that use Open Source to speed their innovation typically establish an OSPO. Comcast’s OSPO and contributions, for example, are housed at <https://comcast.github.io/>. CapitalOne’s approach to Open Source can be found at <https://www.capitalone.com/tech/open-source/>.

Today, governments and universities are starting OSPOs. As such, the OSPO is a concept well understood for organising Open Source work aligned with the business and mission of an organisation. As an example of academic OSPOs, the Rochester Institute of Technology, or RIT, hosts an Open@RIT office; its mission can be found at: <https://www.rit.edu/news/rit-creates-openrit-university-wide-initiative-all-things-open>. Notably, the city of Paris is one of the pioneers in the use of Open Source and the establishment of an OSPO to help promote and manage its use; here is a link to more information about that effort: <https://www.smartcitiesworld.net/special-reports/special-reports/paris-uses-open-source-to-get-closer-to-the-citizen>. As well, here is information on the UK government’s approach to Open Source: <https://gds.blog.gov.uk/about>.

It is easy to claim that Open Source adoption and use happens organically in an organisation, which leads to dangerous oversimplifications and assumptions along the lines of ‘why can’t people who have questions just go to legal when they need to contribute?’ and ‘does an OSPO really make a difference?’ The answer is yes, it does. Especially in a large or complex organisation, the OSPO can bring a great deal of order and strategic thinking to Open Source engagement.

Legal and Efficient Use of Open Source Code: For most organisational legal teams, Open Source activities represent a fraction of their overall responsibilities. However, there are various elements of Open Source engagement that require legal guidance, especially as it relates to licences. This is where the OSPO can be a highly valuable first line of support. OSPOs work hand-in-hand with distinct parts of legal departments to create guidelines, policies, and processes that reduce friction and create more productivity for developers using and engaging with Open Source.

Because it is so easy to download Open Source projects and fragments without understanding the licence, the matter of community health and security vulnerabilities can introduce a number of risks. OSPOs establish education and guidance to make consumption efficient and compliant with policy. An OSPO routinely fields hundreds of questions about existing and new licences and new software that developers want to use.

Following licence obligations when shipping Open Source products outside the organisation is another area of risk that is best handled by an OSPO. Licence obligations typically become activated upon shipment, which means that development teams need to build the discovery and documentation of their Open Source bill of materials when releasing a product. OSPOs work with legal colleagues to create policies around what the company believes can and cannot be used, how to capture it, and how to present it in the product in a way that standardises and simplifies compliance. The productivity hit that an organisation can take is high when there is no clarity on what to do or where to go to with questions.

An OSPO gets involved wherever due diligence is needed, to ensure that Open Source is being used effectively, and that policies and licence obligations are being met. Other areas where OSPOs can lend insights and credence is in M&A (Mergers & Acquisitions), related due diligence, and any investment-related research organisations make.

OSPOs help organisations make decisions about intellectual property, in terms of when to open resources versus keeping them inside the company. As such, OSPOs create governance and provide facilitation on code contributions that development teams want to make to the community at large. They ensure that all the right organisations across the company can weigh in and do the due diligence to make the contribution and the developer successful. Many steps go into reviewing and ensuring that Open Source community contributions are secure and of high quality. Once Open Source items are released, OSPOs help the maintainers and developers do the right thing, in terms of community growth and maintaining a healthy community.

Understanding Company’s Use: There’s a lot of value in OSPOs helping drive developer efficiencies by cataloguing all the Open Source being used and guiding engineering organisations on duplicative use and dependencies. A canonical case of this would be seeing that an organisation is using Vue, React, and Angular across all organisations, is that a good thing for the organisation? Should they standardise on one to improve onboarding and engineering efficiency? And by understanding dependencies, a company can manage which communities it works with and how it responds to security alerts as it knows what is being used and where.

Collaborative Development and Reuse: Because Open Source communities have existed for decades, they provide particularly good development practices from which to learn about collaborative development best practices. These can be brought inside the company to improve both the velocity and quality of development. ‘InnerSource’ is a term used to define bringing Open Source projects inside the firewall. Such elements include a more componentised architecture, better documentation, and better governance for others to contribute to the project, to name a few. This is a relatively new application of Open Source methodologies that OSPOs lead inside a company today and represents a big growth area for OSPOs. For a long time, companies have tried to break down development silos, leverage talent across the company, to reuse work and not reinvent. InnerSource does just that. At the most fundamental level, it improves development and engineering practices, by ensuring that even the largest and most diverse organisations can benefit from the best software development efforts from across their various divisions and groups. You can check out more information on InnerSource practices at <http://.www.Innersourcecommons.org>.

Collective Innovation: According to a ZDNet article,² over 78 per cent of firms use Open Source to run their companies. It is hard to avoid Open Source as most proprietary products and cloud services all use Open Source innovation in one form or the other. Clearly if it is in use, making competent use of Open Source can be a competitive advantage to a company. Strategic questions about where to Open Source, when the company should keep inside the company, when to release a project, which communities with which to collaborate, and how to manage communities around company projects can create competitive advantages. It can also help companies get to market in a way that is ‘faster, better, cheaper’. Open Source is an acknowledged new way to create de facto standards in a certain technology area. A solid Open Source reputation often helps attract developers to the company, as well as helping retain developers inside a company. Managing working with external communities, foundations, and other companies in an efficient way is a key part of an OSPO’s role, external to the company.

Measuring Value and Total Cost of Ownership: While in the early days of Open Source, people consumed it because it was free, and we do still see a rise in adoption in times of financial downturn,³ cost is usually much lower on the list of reasons why people consume Open Source today. The cost advantages, however, cannot be ignored, especially in large and publicly held companies, focused on demonstrable and quarter-to-quarter financial returns. Imagine having to create every bit of the software stack, from scratch, that is commonly used in a product or service. This slide below from the Linux Foundation shows that ‘best-in-class’ companies use 80 per cent Open Source and 20 per cent proprietary software in their product code. That would take years and cost as much as or more than four times today’s development costs if one had to develop all the components in a stack. And as a direct result, time-to-market would suffer. A small team inside a company can do so much more by using the collective innovation of a global community. Besides the use, companies can access source code and customise it for their use and, by contributing back, thereby reduce the technical debt of maintaining software. So, the cost efficiencies associated with using Open Source certainly cannot be ignored.

Total cost of ownership was a convenient economic model when considering on premises use for Open Source software and has gained acceptance as it is popular with proprietary companies in a non-platform environment. It has been ideal to demonstrate that the costs of software utilisation extend beyond royalty or licence fees and to demonstrate that Open Source is not free of cost. However, economic models are discussed in more depth in Chapters 15 and 16.

If you are a serious user of Open Source and want to move with more intention and strategically, starting an OSPO is an important first step (see Figure 19.5). Some of the key steps to starting your own OSPO include:

Software is at the heart of organisations, accelerating their digital strategy and transforming how their stakeholders work with the organisation. And most of today’s software is created using Open Source tools, libraries, services, and methodologies. Open data and open standards are other tools increasingly important to a company’s digital strategy. Managing this vital supply chain in a proactive and systematic way is business-critical for an organisation. OSPOs help companies understand, organise, and align Open Source strategies to the organisation or company’s business goals and strategies.