Why Open Source is Infrastructure, and Why it Matters

By Ashwin Ramaswami and Stewart Scott

At the heart of OpenSSF’s mission is the recognition that open source is infrastructure: it powers the critical systems that we all depend on and should be secured and invested in accordingly. But what does this infrastructure analogy exactly mean, and how could it help open source consumers and policymakers? A new report by the Atlantic Council’s Cyber Statecraft Initiative helps draw light on this question: Avoiding the success trap: Toward policy for open-source software as infrastructure.

Through the Open Source Policy Network, the Cyber Statecraft Initiative has convened OSS developers, maintainers, and stakeholders to develop community-led strategy and policy recommendations for OSS. In this post, we present key takeaways from this report.

Three Analogies

The idea of “open source is infrastructure” can be best understood using three different analogies. Each analogy helps policymakers, funders, and developers think more broadly about an aspect of the open source software ecosystem and corresponding policy recommendations.

1. Water management systems: Like water, we all consume open source software packages through other software products. In fact, software packages are even labeled as “upstream” or “downstream” dependencies. But just like one cannot assume water from the ground is safe to drink or sustainable, OSS consumers cannot simply assume its sustainability or security either. They have a responsibility to ensure the OSS they consume is well-supported and secure and contribute back to secure it.

2. Capital markets: Like capital markets, the open source ecosystem can face compounding, systemic risks, particularly when a vulnerability in an OSS project can be a single point of failure for many systems downstream. Like those of capital markets, these risks can be mitigated by increasing transparency and reporting to consumers and regulators.
   
3. Roads and bridges: Like roads and bridges, OSS makes up critical infrastructure that many depend on, and insufficient investment and maintenance lead risk to accumulate over time. Long-term, consistent, and even mundane support for both OSS and roads and bridges is generally preferable to waiting for catastrophic failure.

What Next?

The report concludes with the following three categories of actions to strengthen the security and sustainability of the open source ecosystem:

1. Encourage responsible OSS consumption: We can do this through creating both best practices and guidelines on how to contribute to OSS. More specifically, companies and nonprofits can develop a standard of best practices for contributing to open source software. The National Institute of Standards and Technology (NIST) could develop an OSS Best Practices framework, and the federal government in general should establish Open Source Program Offices to help agencies manage their OSS strategy, policy, and engagement.

2. Identify and mitigate systemic risk: It is important to have resources and efforts to identify systemic digital risks, including key open source packages for targeted support. For example, an Office of Digital Systemic Risk Management (ODSRM) within the federal government could play such a role.

3. Provide resources with security and sustainability in mind: More funding is needed to support open source software—for example, an OSS Trust Fund that provides sustainable and long-lasting investments in the security and maintenance of OSS code and the health of OSS communities. Companies could also develop an adopt-a-package program to provide resources to support maintenance of the OSS packages they depend on.

Understanding open source software as infrastructure not only helps prioritize it for the long-term maintenance and funding it needs but also allows us to learn from other types of infrastructure policy to see how we can best support the open source ecosystem. The OpenSSF’s Open Source Software Security Mobilization Plan represents part of this effort to sustain and secure open source software as infrastructure, but there are more ways that every stakeholder in the community—from policymakers to users and maintainers—can contribute to our collective security.