Open Source Software and the Governance Problem Nobody Talks About

In April 2014, a vulnerability was disclosed in OpenSSL, the software library that provides encrypted communication for a huge portion of the internet. The vulnerability, officially CVE-2014-0160, became known as Heartbleed. It allowed an attacker to read protected memory from a server running a vulnerable version of OpenSSL, potentially exposing private keys, passwords, and other sensitive data. The bug had been present in the code for roughly two years before anyone found it.

When people started looking into how OpenSSL was maintained, the answer was uncomfortable. At the time of the Heartbleed disclosure, the project was run by a small team of developers, funded primarily through donations. Reports from that period estimated the project's annual funding at a very modest level, something in the range of thousands of dollars per year, for software that was running on hundreds of millions of servers. I want to be careful with that figure because the specific amount circulated in press reports varied, but the directional point is accurate and widely documented: one of the most critical pieces of security infrastructure on the internet was sustained by minimal resources.

The Heartbleed story gets told as a security story. It is also a governance story. Open source software powers an enormous fraction of the modern internet. Linux runs most web servers. Apache HTTP Server and Nginx serve a significant share of web traffic. OpenSSL, before and after Heartbleed, is still present in countless applications and systems because replacing it is hard and expensive. These projects are built and maintained largely by volunteers and small teams. Many of them are not under the governance umbrella of a foundation with stable funding and professional staff. They are maintained by developers who do it because the project matters to them, often in their spare time, sometimes decades after the initial version was written.

The enterprise adoption pattern is where the governance problem gets most visible. Organizations use open source software to avoid license fees, which is economically rational. If a well-maintained, widely-deployed open source library does what a commercial library does, paying for a commercial license looks like an unnecessary cost. What organizations often don't fully account for is the question of who patches the open source software when a critical vulnerability is found. If the answer is "the same volunteer who wrote it in 2009," the organization has outsourced its security dependency to someone it is not paying and has no formal relationship with. When a vulnerability is disclosed, the enterprise files a ticket with its IT team. The IT team waits for a patch. The patch comes from the volunteer developer, who may or may not be able to prioritize it ahead of their day job.

This is not a criticism of open source developers. It is a structural problem. The economics of open source software create a situation where the people who generate enormous value for the software industry often capture very little of it. A small open source library might be used by thousands of commercial products, embedded in enterprise software that sells for millions of dollars per year. The developer who wrote and maintains it might see none of that revenue. The organizations that depend on it have no contractual relationship with the developer and no formal obligation to contribute back. The result is a commons that is systematically underinvested relative to its importance.

The Apache Software Foundation and the Linux Foundation are real organizations that provide governance frameworks, infrastructure, and some funding for open source projects. Projects under their umbrellas tend to have more sustainable governance than solo-maintained repositories. But most open source software does not live under a foundation umbrella. The vast majority of open source code on the internet is maintained under informal arrangements where the sustainability of the project depends almost entirely on the individual developer's continued motivation.

Post-Heartbleed, there was a response. The Core Infrastructure Initiative was launched in 2014 with funding from major technology companies specifically to address security-critical open source projects that were underfunded. It later evolved into what is now the Open Source Security Foundation. OpenSSL itself received substantially more funding and professional development capacity as a result. The response was genuine and meaningful, but it took a high-profile, widely-exploited vulnerability to create the urgency. The question I find myself sitting with is how many OpenSSL-scale critical infrastructure projects are still running on volunteer effort and minimal funding, with a bug in the code that no one has found yet.

From an IS perspective, this is an information problem as much as a governance problem. Organizations often do not have a complete picture of the open source components in their software stacks, who maintains them, how actively they are maintained, or how many other organizations depend on the same component. Security researchers use the term "software bill of materials" to describe the inventory of components that a software product depends on. The idea is that you can't manage what you can't see. If an organization doesn't know it is running a particular version of a particular open source library, it can't know to apply the patch when a vulnerability is disclosed.

The governance problem also has a coordination dimension. The benefits of open source are widely distributed across thousands of organizations. The costs of maintaining secure, well-governed open source infrastructure are not automatically shared in proportion to the benefits. That is the classic structure of a public goods problem. Individual organizations have incentives to free-ride on the contributions of others. The collective result is underinvestment. Solving it requires either changing the incentives, which is hard, or creating coordination mechanisms that make it easier and more visible to contribute back, which is what the foundations and initiatives that emerged post-Heartbleed have been trying to do.