The Unpriced Value of Open Source

The Impossible Invoice

In 2024, Manuel Hoffmann, Frank Nagle, and Yanuo Zhou tried to calculate the value of the open-source software used by businesses. Their first answer was surprisingly small. If the widely used packages in their data had to be recreated once, they estimated the labor cost at about $4.15 billion. Then they asked a different question: what if open source did not exist and every firm using one of those packages had to recreate it internally? The answer became $8.8 trillion. Their data did not even include operating systems, a fairly consequential omission when one of the things we are talking about is Linux.[1]

The $8.8 trillion number has understandably attracted more attention than the $4.15 billion number. It is also not a useful estimate of what open source is worth. The calculation assumes every firm using open source software (OSS) had to produce the OSS themselves.[1] In an actual economy, vendors would appear, companies would switch products, some would build more software internally, and others would abandon projects that no longer made economic sense. Once those responses accumulated, we would no longer have today's economy with a different software bill. We would have a different economy.

I will call $8.8 trillion Exhibit A: the impossible invoice. It is useful because it makes something otherwise difficult to see almost comically visible: an enormous amount of software is being reused rather than recreated. But nobody would ever pay the invoice, and the fact that nobody has to pay it is a large part of the phenomenon we are trying to value.

The problem is visible in national accounting too. Researchers at the U.S. Bureau of Economic Analysis have estimated that Americans produced about $36 billion of open-source software investment in 2019, using methods intended to make that production comparable with other software investment. That is a reasonable thing to measure: people did work, and the work produced an asset.[2] The harder part comes after the asset has been produced, because repeated productive use of software acquired at no price does not generate repeated purchases corresponding to the capability the next users receive.

Suppose a five-person company starts tomorrow using Linux, PostgreSQL, Python, a web framework, dozens of libraries, and a collection of build, testing, deployment, encryption, and monitoring tools. Its payroll appears in the accounts. Its computers appear. Its cloud bill appears. If it buys support, that appears too. What does not appear is a transaction saying that this five-person company has just acquired the practical use of technical systems embodying work performed by thousands of people over decades.

There was no such transaction, so there is nothing obviously missing from the bookkeeping. The company really did inherit the capability, however, and the absence of a price is part of how it managed to do so.

There is nothing unique about inheriting valuable knowledge without paying its creator. Science does this. Mathematics does it. Public standards do it. What is unusual about software is that the inherited object is often executable and modifiable. A scientific paper can tell you how something works, and a standard can specify how systems should interoperate. Linux is already a working system, and you can modify it this afternoon.

That is the peculiar economic object at the center of open source. Productive capability has been substantially separated from exclusive ownership. The copyright may belong to somebody, and a project may have elaborate governance, but a subsequent user can often acquire, execute, modify, and build upon the productive artifact without buying the capability from its creator.

That changes the valuation question. Instead of asking what the software would cost if somebody had to buy or rebuild it, we can ask what becomes economically sensible once nobody has to build that layer again.

The Cost of Finding Out

One of the cleaner places to see the effect is supercomputing in the 1990s. In 1994, researchers at NASA Goddard built the first Beowulf cluster by combining commodity personal computers, inexpensive Ethernet networking, and Linux. NASA's later history of the project describes its origins in a world of proprietary hardware and proprietary system software, and identifies both falling microprocessor costs and the growth of the open-software movement as conditions that made the new architecture possible.[3]

Linux did not make microprocessors fast, and Ethernet did not arrive courtesy of Linus Torvalds. The contribution was compositional. Researchers could assemble standardized hardware into a useful computing system with an operating system they could inspect and modify. A different architecture became economical, and NASA later credited the combination of commodity PCs, Ethernet, and open-source Linux with making high-performance cluster computing widely replicable at much lower cost.[3]

The same structure appears twelve years later in the birth of commercial cloud computing. When Amazon opened EC2 for beta testing in August 2006, it offered virtual computing capacity for ten cents per instance-hour and allowed customers to acquire as many virtual CPUs as they needed. Amazon's Jeff Barr noted in the launch announcement that EC2 had been built using Xen, the open-source virtual-machine monitor.[4]

Amazon deserves the causal credit for turning computing capacity into a metered service that customers could acquire in tiny increments. Open source did not invent that business model. But the service arrived in a world where increasingly large parts of the software underneath a new Internet company—operating systems, web servers, databases, language runtimes, libraries, and virtualization itself—could already be inherited rather than purchased or independently recreated.

Paul Graham had noticed the change before EC2 existed. Writing in November 2005, he argued that startups required less and less money because of four developments: open source, Moore's law, the Web, and better programming languages. When he and his cofounders started Viaweb in 1995, they paid $5,000 for Netscape Commerce Server because they needed secure HTTP and there was no inexpensive substitute that did what they needed.[5] That same year, Y Combinator's first batch received only $6,000 per founder, an amount Jessica Livingston later said they derived from an MIT graduate student's summer stipend.[5]

The comparison should not be pushed farther than Graham pushed it. Hardware had become vastly cheaper, programming languages had improved, the Web had changed distribution, and YC itself predates EC2. What matters is the scale of the shift in the starting conditions. In 1995, one piece of server software cost Viaweb almost as much as YC would later invest in an entire founder for a summer.

Cloud computing pushed that change much farther, and here we have unusually good empirical evidence of what cheap infrastructure does to experimentation. Michael Ewens, Ramana Nanda, and Matthew Rhodes-Kropf studied startups in sectors that benefited substantially from the arrival of AWS and compared them with startups in sectors less affected by cloud computing. After AWS appeared, initial venture financing in the affected sectors fell by about 20 percent. Among companies that survived for at least three years, however, total capital raised was unchanged.[6]

Venture capitalists responded by making more initial investments without a corresponding increase in follow-on rounds. The number of initial investments in the affected sectors nearly doubled, while investors became more willing to abandon companies after the initial experiment had produced information. The successful companies had not become permanently cheap. The large capital commitments had moved later, to a point when investors knew more about whether there was something worth building.[6]

That study measures the effect of cloud computing, not the independent causal contribution of open source. It belongs here because it isolates a broader mechanism that is otherwise difficult to observe: cheap inherited infrastructure lowers the cost of finding out whether an uncertain project deserves further investment. Open source is a distinctive part of that infrastructure because it supplies not merely inexpensive inputs but reusable and modifiable technical capability; Graham's earlier account independently identifies it as one of the forces already pushing startup costs downward before elastic cloud computing arrived.

This distinction changes how we should think about the value of a cost reduction. If an experiment that once required $5 million can now be conducted for $500,000, the economic effect is not necessarily a $4.5 million saving. Some $5 million experiments are never attempted. At $500,000, somebody may decide it is worth finding out.

The failures belong to the mechanism too. When the initial bet is cheap, capital can be redirected after an idea proves unpromising rather than committed before much is known. An economy with the same stock of money and talent can therefore test more possibilities. Replacement-cost accounting can see the software that was not rewritten; it has a much harder time seeing the experiment that became cheap enough to try.

Nobody Has to Own the Whole Stack

Android shows a related effect operating at the scale of an industry, but the relevant constraint is different. When Google and thirty-three other companies announced the Open Handset Alliance in 2007, they described Android as a complete mobile software stack intended in part to reduce the cost and time required to develop and distribute mobile devices and services. When the source was released the following year, manufacturers could begin with the code for a complete mobile platform and adapt it to their own hardware.[7]

Smartphones already existed, so the interesting counterfactual is a world in which every handset manufacturer needs some other answer to the operating-system problem. Apple had its answer. Nokia, BlackBerry, and Microsoft had theirs. The question was what the many firms that wanted to compete in smartphone hardware would have to own, license, or build before they could enter the market.

Android removed a large piece of that admission price. A manufacturer still needed hardware engineering, radio expertise, industrial design, certification, manufacturing, supply chains, distribution, and plenty of software work of its own. It did not also have to become an operating-system company. The Open Handset Alliance explicitly described the Apache license as commercially friendly and designed to let manufacturers customize and differentiate their products while retaining proprietary additions if they wished.[7]

The result was not merely that manufacturers avoided an OS license. A semiconductor company could concentrate on chips supporting a common platform. A handset maker could concentrate more heavily on hardware, manufacturing, price, design, and distribution. An application company could target a common software environment instead of establishing a separate relationship with every device manufacturer. The common layer reduced the amount of the total system each participant had to own before the participants could work together.

Artificial intelligence provides a more compact example of what happens when the common layer can itself accumulate. PyTorch began inside Meta and became an open-source machine-learning framework; by the time Meta transferred it into an independent foundation in 2022, about 2,400 contributors had built more than 150,000 projects on it. The founding governing group included AMD, AWS, Google Cloud, Meta, Microsoft Azure, and NVIDIA—competitors jointly supporting a common framework while competing elsewhere.[8]

The relevant object here is the framework, not a claim that modern AI as a whole is open. GPUs and CUDA are proprietary, many model weights and datasets are restricted, and frontier training remains enormously capital intensive.[9] PyTorch matters because a researcher can inherit working implementations of automatic differentiation, tensor computation, optimization, hardware integration, and distributed-training machinery instead of rebuilding those capabilities before reaching the research question at hand.

That inheritance can deepen over time. A difficult technique may begin as one group's research result, appear as an open implementation, be improved by other users, and eventually enter a shared framework as ordinary infrastructure. The next researcher encounters yesterday's frontier as part of today's starting point. As learned systems move into vehicles, robots, and other physical machinery, the accumulated training and simulation stack can carry the same inheritance into industries that no longer look much like software.

The larger effect is therefore not simply that open source reduces today's bill. It permits successful technical work to become common productive capital and allows independent actors to specialize above layers they do not own. Some of the value lies in avoiding repetition; some lies in reaching the next unsolved problem sooner.

Who Pays for the Commons?

The missing price has been doing useful work throughout this story. It lets productive capability travel downstream without requiring every new user to negotiate for it. But the same missing transaction means that growing downstream dependence does not automatically send money, review, or governance capacity back toward the layer everyone has inherited. The two effects are not separate problems; they are opposite faces of the same mechanism.

IBM gave a remarkably clear account of why a profit-seeking firm might nevertheless contribute heavily to the common layer. In its 2000 annual report, IBM said it would invest $1 billion in Linux and dedicate 1,500 programmers to enabling its products for the operating system. The company expected Linux to weaken the ability of proprietary operating-system vendors to control customers and developers, while shifting economic value toward services, middleware, and servers—areas in which IBM expected to profit.[10]

The apparent paradox disappears once we stop assuming that a company must capture value from the same layer in which it creates value. IBM could make Linux better and earn its return somewhere else. Google could make Android broadly available while earning money from complementary services. Meta could support PyTorch because owning the machine-learning framework was not necessarily the most valuable point at which to collect rent. A firm may prefer a larger market around a common intermediate layer to a smaller market from which it extracts a fee at every passage.

That arrangement does not remain attractive to every sponsor forever. In August 2023, HashiCorp changed future releases of Terraform and several other products from the open-source Mozilla Public License to the Business Source License. HashiCorp kept the source visible and continued allowing broad copying, modification, redistribution, and many commercial uses, but withdrew the right to use future releases in offerings that competed directly with HashiCorp. Its explanation was explicit: other vendors were using HashiCorp's open-source work and the surrounding community for their own commercial purposes without contributing materially back.[11]

HashiCorp was not returning to conventional closed proprietary software so much as trying to move the booth. It wanted to preserve many of the benefits of source availability while reclaiming the commercial-reuse right it believed allowed too much of the return to escape. But the rights already granted under the old license survived the change. The existing MPL-licensed Terraform code was forked into OpenTofu, which soon moved under Linux Foundation governance as an open-source successor.[12]

That episode makes the economic tension unusually visible. A company can spend years benefiting from the expansion produced by unrestricted reuse and later conclude that the return is landing too far from the layer it finances. Open-source licensing does not prevent that calculation from changing, but prior grants of reuse rights can constrain how completely the common layer can be pulled back behind a new gate.

There is a different problem when no participant has a sufficiently strong private reason to carry the common layer. Heartbleed exposed it in 2014. OpenSSL was critical infrastructure used across the Internet, yet the resources devoted to securing and maintaining it were badly out of proportion to the dependence placed upon it. The vulnerability helped prompt the Linux Foundation's Core Infrastructure Initiative, through which large technology companies began collectively funding OpenSSL and other critical projects that had lacked adequate support.[13]

Log4Shell showed how wide the blast radius of such a common dependency could become. CISA, the FBI, NSA, and several foreign cybersecurity agencies issued coordinated warnings because the vulnerability affected systems across conventional IT, cloud environments, and operational technology.[14] The Apache Software Foundation does not itself pay developers to work on Apache projects, although many contributors are paid by companies and institutions that depend on those projects. The funding that exists therefore comes through employers, sponsors, and other arrangements rather than through an automatic claim that scales with the amount of downstream dependence.[14]

The xz-utils backdoor in 2024 showed a darker version of the same institutional weakness. An attacker worked into a position of trust around a widely distributed compression library and inserted a sophisticated backdoor into upstream releases; OpenSSF and the OpenJS Foundation subsequently warned maintainers about similar social-engineering efforts aimed at obtaining project authority. Their warning points directly to small teams and individual maintainers who are overwhelmed by commercial users that depend heavily on their projects while contributing little support back.[15]

Heartbleed, Log4Shell, and xz do not establish that open software is inherently less secure than proprietary software. They expose three consequences of a looser coupling between use and support: dependence can grow without a funding channel, the resulting dependency can acquire an enormous blast radius, and thin maintenance or governance structures can themselves become attack surfaces. The missing price can eventually reappear as a security and governance externality rather than a software invoice.

None of the obvious responses removes the trade. Collective funding can preserve unrestricted inheritance, but somebody must decide which projects deserve support and how much. Complementary-product firms can carry a common layer while sufficient profit remains elsewhere in the stack, but that arrangement lasts only as long as their incentives remain aligned. Relicensing can restore a stronger upstream claim on commercial value by reducing some of the reuse rights that helped the ecosystem grow. Accepting chronic underfunding preserves the lowest-friction inheritance while leaving more maintenance, security, and governance costs outside the transactions generating the downstream benefit.

This is why Exhibit A remains useful despite being an impossible valuation. Its $8.8 trillion invoice freezes the economy and charges everyone for a form of reuse that normally occurs without a bill. The real economy responds to the absence of that bill: firms can specialize more narrowly, experiments become cheaper, technical achievements accumulate into common starting points, and some projects cross the threshold into feasibility that otherwise would not.

A world with much less open source would still have operating systems, clouds, smartphones, AI, and software companies. It would have proprietary substitutes, excellent products, competing vendors, and plenty of innovation. But more technical layers would have to be purchased, negotiated, vertically integrated, or recreated before the next layer could begin. That changes who can participate, how expensive it is to be wrong, and how far forward each new project gets to start.

The economic problem is therefore not to discover the hidden price that open source should have been charging all along. Much of its value exists because that price is absent, while some of the resulting maintenance and governance burden exists for exactly the same reason. A tollbooth at every layer would make more of the upstream value collectible, but it would also alter the inheritance that created much of the downstream value in the first place. The harder problem is how to send enough value back upstream to maintain and govern common technical capital without rebuilding the gates whose absence allows so much productive capability to flow downstream.

Notes

[1] Manuel Hoffmann, Frank Nagle, and Yanuo Zhou, “The Value of Open Source Software”, Harvard Business School Working Paper 24-038, 2024. The paper reports a $4.15 billion supply-side recreation estimate and an $8.8 trillion demand-side estimate under the assumption that each firm would recreate the OSS it uses; the authors also note that operating systems are omitted from their data.

[2] J Bayoán Santiago Calderón, Carol Robbins, Ledia Guci, Gizem Korkmaz, and Brandon L. Kramer, “Measuring the Cost of Open Source Software Innovation on GitHub”, U.S. Bureau of Economic Analysis Working Paper 2022-10, July 2022. The paper estimates U.S. OSS investment in 2019 at $36.2 billion.

[3] James R. Fischer, “The Roots of Beowulf”, NASA Goddard Space Flight Center, 2014; see also NASA, “Beowulf Cluster Computing Inducted into Space Technology Hall of Fame”. These sources describe the first Beowulf Linux commodity cluster at Goddard in 1994, its use of commodity hardware and Ethernet, and the role of the open-software movement in the architecture's development.

[4] Jeff Barr, “Amazon EC2 Beta”, AWS News Blog, August 25, 2006. The launch announcement describes ten-cent instance-hour pricing and identifies Xen as the virtual-machine monitor used to build EC2.

[5] Paul Graham, “The Venture Capital Squeeze”, November 2005; Jessica Livingston, “Jessica Livingston Shares 9 Things She Learned From Founding YC”, Y Combinator, July 11, 2018. Graham identifies open source among the forces lowering startup costs and recounts Viaweb's $5,000 Netscape Commerce Server purchase; Livingston recalls YC's original $6,000-per-founder investment.

[6] Michael Ewens, Ramana Nanda, and Matthew Rhodes-Kropf, “Cost of Experimentation and the Evolution of Venture Capital”, NBER Working Paper 24523, April 2018; published in the Journal of Financial Economics 128, no. 3 (2018). The study uses the arrival of cloud computing to examine how lower experimentation costs changed initial financing, follow-on investment, and venture-capital portfolio behavior.

[7] Open Handset Alliance, “Industry Leaders Announce Open Platform for Mobile Devices”, November 5, 2007; “Android FAQ”. The launch materials describe Android as an open mobile stack intended to reduce device-development costs and time, and explain the commercially permissive licensing intended to support manufacturer customization and differentiation.

[8] Meta AI, “Announcing the PyTorch Foundation: A New Era for the Cutting-Edge AI Framework”, September 12, 2022. Meta reported more than 2,400 contributors and roughly 150,000 projects built on PyTorch and named AMD, AWS, Google Cloud, Meta, Microsoft Azure, and NVIDIA among the foundation's founding members.

[9] NVIDIA, “CUDA Toolkit End User License Agreement”. CUDA is a proprietary NVIDIA software platform; this matters here because PyTorch's openness should not be read as a claim that the surrounding modern AI stack is wholly open.

[10] IBM, 2000 Annual Report, especially pp. 31–32. IBM described a $1 billion Linux investment and 1,500 dedicated programmers, while arguing that Linux would reduce operating-system vendor control and shift value toward services, middleware, and servers.

[11] Armon Dadgar, “HashiCorp Adopts Business Source License”, HashiCorp, August 10, 2023. HashiCorp explains both its original reasons for using open source and its later decision to restrict competing commercial offerings while keeping source broadly available.

[12] OpenTofu, “OpenTofu Announces Fork of Terraform”, August 25, 2023; Linux Foundation, “Linux Foundation Launches OpenTofu: A New Open Source Alternative to Terraform”, September 20, 2023. The first records the community fork of the previously MPL-licensed Terraform code; the second records OpenTofu's move under neutral Linux Foundation governance.

[13] Linux Foundation, “Never Let a Good Crisis Go to Waste: Core Infrastructure Initiative”, April 29, 2014; “Core Infrastructure Initiative Launches New Census Project”, July 9, 2015. The Foundation describes Heartbleed as the galvanizing event behind the initiative and identifies major technology companies funding critical but under-resourced OSS projects including OpenSSL.

[14] CISA et al., “Mitigating Log4Shell and Other Log4j-Related Vulnerabilities”, December 2021; Apache Software Foundation, “How the ASF Works”. CISA describes Log4j's presence across consumer and enterprise services, websites, applications, cloud assets, and operational technology. The ASF explains that project participants are volunteers in the Foundation's governance structure, although many contributors are paid by companies or institutions to work on Apache projects rather than by the Foundation itself.

[15] Open Source Security Foundation, “XZ Backdoor CVE-2024-3094”, March 30, 2024; OpenSSF and OpenJS Foundation, “Issue Alert for Social Engineering Takeovers of Open Source Projects”, April 15, 2024. The latter describes attempted maintainer takeovers resembling the xz campaign and explicitly connects such risks to small or individual maintenance teams supporting projects heavily used by commercial companies.