The Gift That Runs the World

Every time you load a web page, send a message, use a phone or pay by card, you rely on software that someone gave away. The servers that host most websites run Linux. The phones most people carry run Android, built on Linux. The databases, programming languages, web servers, encryption libraries and compression tools beneath almost every application are, in large part, open source: published so that anyone may use, study, change and share them, usually at no charge.

The scale is hard to grasp. In 2024 three economists at Harvard Business School, Manuel Hoffmann, Frank Nagle and Yanuo Zhou, estimated that recreating the most widely used open-source software once would cost about $4.15 billion, but that if every firm that used it had to build its own equivalent, the cost would be about $8.8 trillion, and that firms would spend three and a half times more on software without it. They also found that 96 percent of that value came from the work of about 5 percent of the developers.¹ The economy runs on a gift, much of it produced by a small number of people.

This essay follows how that came to be. It is a story about software, but its deeper subjects are old ones: why people give their work away, how a shared resource can be governed, whether a commons can survive the companies that profit from it, and what freedom means when it applies to code. To understand it, we need to start in a time when sharing software was not a movement but a habit.

When software was shared

In the 1950s and 1960s software was not a product. Computers were sold or leased with the programs needed to use them, and users wrote much of the rest themselves. They shared it freely. In 1955 users of IBM’s scientific computers formed SHARE, a user group whose members exchanged programs, documentation and fixes; similar groups formed around other machines. In universities and research laboratories, programmers passed source code to one another as scientists passed papers. Improving someone else’s program and sharing the improvement was normal.

At MIT’s Artificial Intelligence Laboratory, a culture of programmers who called themselves hackers, in the original sense of people who loved clever programming, treated access to code as a matter of principle. Programs belonged to the community that improved them. The journalist Steven Levy later summarised their ethic in Hackers (1984): access to computers should be unlimited, all information should be free, and authority should be distrusted.

That culture was eroded by commerce. After IBM began pricing software separately in 1969, as described in the essay on subscription software, software became a product with an owner. Companies distributed programs in compiled form only, without the source code that people could read and change, and bound users with licences forbidding copying and modification. Unix, created at Bell Labs in 1969 and licensed cheaply to universities, spread through academic sharing, but AT&T increasingly restricted it once it could sell it commercially. By the early 1980s, the programmers at the MIT lab had mostly left for companies, and the shared code they had worked on was locked away.

Free software: Stallman’s argument

Richard Stallman, a programmer at the MIT lab, experienced this as a moral loss. In a story he has told many times, the lab received a new laser printer from Xerox whose software he could not modify, as he had modified the previous printer’s to notify users of paper jams, because Xerox would not share the source code. A researcher elsewhere who had the code refused to give it to him, having signed a nondisclosure agreement. Stallman concluded that proprietary software divided users and made them helpless.

On 27 September 1983 he announced the GNU project, a plan to write a complete operating system compatible with Unix and give it away to everyone who could use it. In 1985 he published the GNU Manifesto, explaining why, and founded the Free Software Foundation (FSF).² Stallman defined free software by the freedom it gave users, not its price. In the formulation the FSF later standardised, users of free software have four freedoms: to run the program for any purpose; to study how it works and change it; to redistribute copies; and to distribute modified versions. Access to the source code is a precondition for the second and fourth. “Free,” Stallman said, as in free speech, not as in free beer.

His most original contribution was legal. Releasing software into the public domain would let anyone use it, but it would also let companies take it, improve it and sell closed versions, which would end the freedom for their users. Stallman’s solution was copyleft: a licence that used copyright to grant everyone the four freedoms, on condition that anyone who distributed the software, or a modified version, passed on the same freedoms under the same licence. The GNU General Public License (GPL), first published in 1989, turned the law that normally restricts copying into a guarantee of sharing.³ Software under the GPL could be sold, but it could never be closed.

Through the 1980s the GNU project produced many of the components of an operating system: a compiler, a text editor, libraries and tools. It lacked a working kernel, the core that manages the hardware.

Linux: a hobby that became the world’s kernel

On 25 August 1991 Linus Torvalds, a student at the University of Helsinki, announced that he was writing a free operating system kernel for personal computers, “just a hobby,” as he put it. In 1992 he released it under the GPL. Combined with the GNU tools, it formed a complete free operating system, usually called Linux (the FSF prefers GNU/Linux).

The essay on operating systems describes Linux’s technical history. What matters here is how it was built. Torvalds released new versions frequently, accepted improvements from anyone who sent them over the internet and credited contributors. Thousands of programmers around the world, most unpaid, contributed drivers, file systems and fixes. Torvalds made the final decisions, and trusted lieutenants managed parts of the system. The project had no company, no office and, for years, no budget. It worked.

In 1997 the programmer Eric Raymond described the method in an essay, “The Cathedral and the Bazaar.” Most software, including much free software such as GNU’s, was built like a cathedral, carefully designed by a small group and released when finished. Linux was built like a bazaar, in public, with early and frequent releases and many contributors. Raymond summarised one of its principles as Linus’s Law: “given enough eyeballs, all bugs are shallow.”⁴ With enough people looking at the code, someone would see the cause of any problem. The essay was widely read, including at Netscape.

Open source: a new name for business

By 1998 the free software movement had built impressive systems, but businesses were wary. The word “free” suggested amateurism or a lack of revenue, and Stallman’s moral language about freedom alarmed executives.

In January 1998 Netscape, losing the browser war to Microsoft’s Internet Explorer, which was bundled free with Windows, announced that it would release the source code of its browser. In the planning that followed, a group that included Raymond met in Palo Alto in early February, and Christine Peterson, executive director of the Foresight Institute, suggested a new term: open source.⁵ Raymond, Bruce Perens and others founded the Open Source Initiative (OSI) later that month to promote the term and to certify licences that met an Open Source Definition, based on guidelines Perens had written for the Debian project.

The rebranding was deliberate. Open source presented sharing code as a superior method of development, producing better software through peer review and collaboration, rather than as a moral obligation. Stallman objected that it hid the issue of freedom, and the FSF has continued to use “free software.” The two terms describe nearly the same set of licences and reflect different philosophies: one about rights, the other about results.

Netscape’s released code became the Mozilla project. Netscape itself was bought by AOL and faded, but Mozilla’s Firefox browser, launched in 2004, grew to challenge Internet Explorer and kept the web from being controlled by a single company’s browser.

The business of giving away

Companies soon discovered ways to make money from software they gave away. The economist Yochai Benkler would later argue that open source was a new mode of production, “commons-based peer production,” distinct from both firms and markets.⁶ Businesses found ways to work alongside it.

Red Hat, founded in 1993, packaged Linux and sold support. It went public in August 1999 in one of the dot-com era’s most successful offerings. Its durable model came in the early 2000s with Red Hat Enterprise Linux, sold by subscription: the code remained free, but customers paid for certified, tested, supported versions maintained for many years, with someone to call when things went wrong. Red Hat became the first open-source company to pass $1 billion in annual revenue, and in 2019 IBM completed its purchase for about $34 billion.

IBM itself announced in 2000 that it would invest $1 billion in Linux, because it wanted an operating system for its hardware that Microsoft did not control. Many large technology companies came to fund open source for similar reasons. A widely cited essay by the software entrepreneur Joel Spolsky in 2002 explained the logic: smart companies try to make the products that complement theirs cheap, a strategy he summarised as commoditising your complements. IBM sold hardware and services, so a free operating system made its products more valuable. Google sold advertising, so free browsers and phone software that brought more people online helped it.

Google’s Android, announced in 2007 and released as open source in 2008, was the most consequential example. Phone makers could use and modify Android freely, which made it attractive to companies that could not build their own system. But the most important parts of the Android experience, the Play Store, Gmail, Maps and Google’s search, remained proprietary and were licensed to manufacturers on Google’s terms. Android became the most widely used operating system in the world, and the European Commission later fined Google for the conditions it attached to those services.

Microsoft’s journey was the most dramatic. In 2001 its chief executive, Steve Ballmer, called Linux “a cancer” that attached itself, in an intellectual property sense, to everything it touched, a reference to the GPL’s requirement that derived works be shared.⁷ In 2014 his successor, Satya Nadella, presented a slide reading “Microsoft loves Linux.” Microsoft released much of its own developer software as open source, built Linux into Windows and its Azure cloud, and in June 2018 bought GitHub, the website where most open-source projects are hosted, for $7.5 billion. The shift, annotated on this site in Nadella’s Bold Ambition memo, reflected a recognition that developers had moved to open source and that cloud computing made revenue from running software more important than revenue from licensing it.

GitHub, founded in 2008, had itself transformed open source. It made it easy for anyone to copy a project, make changes and propose them back, through a “pull request.” Contributing became a social activity, with profiles, followers and visible histories of work. By the 2020s GitHub hosted the work of more than a hundred million developers.

The fragile foundations

As open source became infrastructure, its weaknesses became visible. Many critical components were maintained by a few people, often unpaid, in their spare time.

In April 2014 researchers disclosed Heartbleed, a flaw in OpenSSL, the encryption library that secured a large share of the world’s web traffic. The bug let attackers read the memory of servers and had gone unnoticed for about two years. Investigations revealed that OpenSSL had been receiving about $2,000 a year in donations and had one full-time developer.⁸ The technology industry responded by creating the Core Infrastructure Initiative under the Linux Foundation to fund critical projects. In 2016 the writer Nadia Eghbal published Roads and Bridges, a report for the Ford Foundation describing open-source software as unseen public infrastructure that the companies relying on it were failing to maintain.

In December 2021 a vulnerability called Log4Shell was found in Log4j, a widely used Java library for recording events in software, maintained by a small group of volunteers. It affected millions of systems, from cloud services to video games, and governments issued emergency warnings.

The most alarming case came in March 2024. Andres Freund, an engineer at Microsoft, noticed that logins to a computer running a test version of Linux were taking about half a second longer than expected. Investigating, he discovered a backdoor hidden in xz, a widely used data compression library. Over about two years, a contributor using the name Jia Tan had gained the trust of the project’s overworked sole maintainer, partly with the help of other accounts that pressured him to accept help, and had eventually become a co-maintainer and inserted malicious code designed to allow remote access to systems running a common login service.⁹ It was caught weeks before it would have reached major Linux distributions used on millions of servers. Linus’s Law had worked, but by luck: one curious engineer with unusual patience. The episode showed that the social trust on which open source runs could itself be attacked.

The cloud and the licence wars

A different conflict arose between open-source companies and cloud providers. Companies such as Elastic (maker of Elasticsearch), MongoDB, Redis and HashiCorp built businesses around popular open-source projects, selling support, enterprise features and hosted versions. Cloud providers, especially Amazon Web Services, began offering those same projects as managed services, earning revenue from software they had not built and, the companies argued, contributing little in return.

From 2018 the companies responded by changing their licences. MongoDB adopted a Server Side Public License in 2018 that required anyone offering the software as a service to release the source code of their entire service. Elastic adopted similar terms in January 2021. HashiCorp moved its Terraform tool and other products to a Business Source License in August 2023, and Redis changed its licence in March 2024. These licences allowed most users to continue using the software freely but restricted competitors, and they did not meet the Open Source Definition.¹⁰

The communities and the cloud providers answered by forking. Amazon forked Elasticsearch as OpenSearch in 2021, later moved to the Linux Foundation. A coalition of companies forked Terraform as OpenTofu in 2023, also under the Linux Foundation. Amazon, Google and others forked Redis as Valkey in 2024. Each fork took the last open-source version and continued developing it under the original licence. Several of the companies later reversed course. Elastic added the open-source AGPL licence in August 2024, and Redis did the same in 2025. IBM bought HashiCorp in 2025.

Open source and AI

The latest argument about openness concerns artificial intelligence. Much of the AI software stack is open source, including the PyTorch and TensorFlow frameworks. The question is what it means for a model itself to be open.

In February 2023 Meta released its LLaMA language model to researchers; the model’s weights, the billions of numbers that encode what it learned, quickly leaked publicly. In July 2023 Meta released Llama 2 for broad commercial use under a custom licence, and continued with later versions. Meta described these models as open source. The Open Source Initiative disagreed, pointing to licence restrictions, such as limits on use by very large companies and on certain applications, and to the fact that the training data and much of the training process were not released. In October 2024 the OSI published an Open Source AI Definition requiring that the code, the weights and detailed information about the training data be available.¹¹ In January 2025 the Chinese company DeepSeek released the weights of its R1 reasoning model under the permissive MIT licence, though without its training data, and its strong performance at low reported cost unsettled the industry, as the essay on large language models describes.

The debate has been sharpened by questions of safety. Some argue that releasing powerful model weights lets anyone remove safeguards and misuse them; others argue that openness allows independent scrutiny, prevents concentration of power in a few companies and lets researchers and smaller firms build on the technology. The old arguments about free software, freedom, method and business strategy have returned in a new form.

What open source is today

Open source today is the default way much software is built. Most new software incorporates open-source components, often hundreds of them. Large companies employ many of the most active contributors to major projects; foundations such as the Linux Foundation and the Apache Software Foundation host and govern projects with corporate funding. At the same time, many critical libraries remain maintained by individuals. Governments have begun to treat open source as infrastructure: the European Union’s Cyber Resilience Act, adopted in 2024, sets security obligations for software sold in Europe while creating a lighter regime for non-profit open-source stewards, after open-source developers warned that the original proposal would make them liable for code they gave away.

How open source changed the way software is made and used

Several shifts follow from the rise of open source.

From building everything to assembling

Most software is now assembled from open-source components and extended, rather than written from scratch. That has made development vastly faster and cheaper, and made every application dependent on a long chain of other people’s work.

From secrecy to scrutiny

Open code can be read by anyone. That made peer review of software possible at scale, though, as Heartbleed and xz showed, possible is not the same as actual.

From employment to contribution

Open source let people contribute to projects without being hired, and let their contributions be seen. Public work on GitHub became a kind of résumé. It also blurred the line between paid and unpaid work, as companies came to rely on volunteers.

From owning to depending

Companies gave up owning much of the software they rely on and gained access to far more than they could build. They also took on dependencies they rarely audit, maintained by people they do not pay.

From product to commons, and back

Open source created a commons, and companies built products and services on it. The relationship between the commons and the businesses that profit from it is now among the central questions of the software industry.

What the history suggests

Open source repeats patterns found across this site. Small working things, released early, outran grand designs: Linux overtook projects that were more carefully planned. Open systems outreached closed ones over time, from the web server to the browser to the phone. Incumbents absorbed the challenge, as Microsoft and IBM moved from opposing open source to depending on it. And who pays shaped what was built: projects that companies needed were well funded; projects that everyone used but no one owned were neglected.

But open source also shows something more particular. Its foundation is a gift: work given freely by people who expect, at most, recognition, reciprocity or the satisfaction of making something useful. The history is a long experiment in whether gifts can sustain infrastructure on which trillions of dollars depend, and what rules and institutions are needed to make them do so. That is where the philosophy begins.

Understanding the philosophy

The rest of this essay examines the ideas beneath open source, one at a time. Each is explained in plain terms, connected to the tradition of thought that has examined it, traced in the history above, tested against its strongest objection and related to how people and organisations decide today. The connections to philosophers, economists and anthropologists are interpretations offered to make the ideas clearer. The people who built free and open-source software were mostly solving practical problems, though some, Stallman above all, argued explicitly from principle. The essay on operating systems introduces the idea of software as a commons; this essay examines it in more depth.

1. Ideas that cannot be used up

The idea in plain terms

If I give you my bicycle, I no longer have it. If I give you my idea, we both have it. Software is like an idea: copying it costs almost nothing and takes nothing from the original. That simple fact makes software different from most property, and it is the starting point of every argument about whether software should be owned.

The tradition

In a letter of 1813 to Isaac McPherson, Thomas Jefferson argued that ideas are peculiarly unsuited to being property. “He who receives an idea from me, receives instruction himself without lessening mine,” he wrote, “as he who lights his taper at mine, receives light without darkening me.”¹² Jefferson accepted that society might grant temporary monopolies, such as patents, to encourage invention, but insisted that these were a matter of social convenience, not a natural right.

Economists later formalised the point. A good is non-rival when one person’s use does not reduce another’s, and Paul Samuelson’s theory of public goods showed that markets tend to underprovide such goods, because people can benefit without paying. Copyright and patents solve the problem by creating artificial scarcity: they make copying illegal so that creators can charge for copies. The cost is that fewer people use the work than could.

The opposite tradition, rooted in John Locke’s theory that people own what they mix their labour with, holds that creators have a natural claim to their work. Many defenders of strong intellectual property have drawn on it.

Where it shows up

The history of software is a history of choosing between these views. Early software was shared like ideas. After IBM priced software separately, it became property, protected by copyright and licences. Bill Gates’s 1976 letter to hobbyists made the Lockean case: programmers deserve to be paid for their work. Stallman made the Jeffersonian case: restricting copying deprives others of light at no gain to the creator, except the gain of being able to charge. Copyleft was an ingenious use of the property system for Jeffersonian ends.

The strongest objection

The objection is that without a way to charge for copies, much software would never be written. Professional software development is expensive, and the incentive of sales has produced vast amounts of valuable software. Open source itself depends heavily on companies whose revenue comes from proprietary products or services. That is fair: the open-source economy is not independent of the proprietary one. But the history shows that very large amounts of valuable software can be produced without charging for copies, which was not obvious before it happened.

What it means today

For organisations deciding whether to release software, the question is what they lose by sharing, and the answer is often less than they expect: the code itself is rarely the scarce asset; the people, data, services and customers are. For policy, the non-rival nature of software is an argument for funding shared infrastructure publicly or collectively, as with roads and research.

2. Freedom as the point

The idea in plain terms

Stallman’s argument was not mainly that free software is better or cheaper. It was that people should control the tools that control their lives. When you cannot read or change the software you use, the people who wrote it decide what it does to you. Free software is about freedom in the sense that matters to citizens, not shoppers.

The tradition

In his 1958 lecture “Two Concepts of Liberty,” the philosopher Isaiah Berlin distinguished negative liberty, freedom from interference, from positive liberty, the freedom to be one’s own master and act on one’s own purposes. The idea of autonomy, being governed by rules one gives oneself, runs from Kant through modern liberalism. Republican political thinkers, from Cicero to the contemporary philosopher Philip Pettit, defined freedom as non-domination: being free is not merely being left alone but not being subject to another’s arbitrary power, even if they choose not to use it.

Where it shows up

Stallman’s four freedoms are freedoms of both kinds: freedom from restriction on running and sharing, and freedom to understand and modify, which makes users masters of their tools. His story of the Xerox printer is a story of domination in Pettit’s sense: the company’s control over the code meant users could not fix their own problem, whatever the company’s intentions. The OSI’s rebranding set this language aside in favour of practical benefits, which is why the FSF regards it as a loss. The argument has returned with force in debates about devices people cannot repair, cloud services whose code they cannot inspect and AI systems whose workings are hidden.

The strongest objection

The objection is that very few users can read or modify code, so the freedom to do so is meaningless to most people. They need software that works, not software they could rewrite. This is true for individuals. But the freedoms matter collectively: when anyone may study and modify software, some people will, and everyone benefits from their scrutiny, repairs and alternatives. Freedom of the press matters to people who never publish.

What it means today

For organisations, the question is which of their tools they control in this sense: whether they can inspect, fix, continue to run and move them, regardless of a vendor’s decisions. For societies, as software governs more of public life, from benefits systems to elections, the case for being able to inspect it grows stronger.

3. Why people give their work away

The idea in plain terms

Standard economics assumes people work for pay. Yet millions of people write software for nothing and give it away. Why? The answers turn out to be varied: pleasure in the work, the desire to solve one’s own problem, reputation, learning, belonging to a community, belief in a cause, and, increasingly, a salary from an employer who benefits.

The tradition

In The Gift (1925) the French anthropologist Marcel Mauss studied gift exchange in societies from Polynesia to the Pacific Northwest and argued that gifts are never purely free. They create obligations: to give, to receive and to reciprocate. Gift exchange builds relationships and status in ways market exchange does not. Raymond drew on this tradition in his 1998 essay “Homesteading the Noosphere,” describing the hacker community as a gift culture in which status comes from what one gives away.

Economists offered other explanations. In 2002 Josh Lerner and Jean Tirole argued that open-source contributions can be explained by career concerns: visible work signals skill to future employers, and contributors gain from that reputation. Psychologists studying motivation, notably Edward Deci and Richard Ryan, emphasised intrinsic motivation: people do many things because the activity is interesting and gives a sense of competence and autonomy. Benkler argued that peer production succeeds because it lets people choose tasks that suit their motivations and skills, which neither firms nor markets do as well. And Mancur Olson’s The Logic of Collective Action (1965) explained the opposite problem: when a good benefits everyone, each individual has reason to let others pay for it.

Where it shows up

All of these motives appear in the history. Torvalds wrote Linux for fun and to have a system he could use. Stallman wrote GNU for a cause. Many programmers contributed to fix problems in software they used, and shared the fix because maintaining a private version was harder. GitHub made contributions visible, turning them into a public record of skill. As open source grew, companies paid employees to contribute, because they depended on the projects. And Olson’s problem appeared too: companies that benefited from OpenSSL, Log4j and xz contributed little until a crisis forced them to.

The strongest objection

The objection is that the gift framing romanticises what is now largely corporate work. Most contributions to major projects come from employees of large companies, acting for their employers’ benefit. And unpaid labour by volunteers, which companies profit from, can look less like a gift than exploitation. These criticisms are fair. The open-source economy mixes gifts, wages and strategy, and the volunteers maintaining critical code have often burned out. Eghbal’s later book, Working in Public (2020), described maintainers overwhelmed by the demands of users who expected service without paying.

What it means today

For leaders, the motives of open-source contributors are a lesson in motivation generally: autonomy, mastery and recognition can draw extraordinary effort, and money alone can crowd them out. For companies that depend on open source, reciprocity is both an obligation and a form of risk management: paying maintainers, contributing fixes and supporting foundations protects what the company relies on.

4. Many eyes and the open society

The idea in plain terms

Linus’s Law says that with enough people looking, every bug will be found. The idea is that openness produces better knowledge than secrecy, because errors can be found and corrected by anyone. It is an argument about how we come to know things, and it applies to science and politics as much as to software.

The tradition

The philosopher Karl Popper argued that knowledge grows not by proving theories true but by trying to refute them and eliminating errors. In The Open Society and Its Enemies (1945) he extended the idea to politics: open societies, which allow criticism and peaceful change, can correct their mistakes, while closed ones cannot. The sociologist Robert K. Merton described in 1942 the norms of modern science, among them what he called communism, the common ownership of findings, and organised scepticism, the expectation that all claims will be scrutinised. Science progresses, on this view, because its results are public and open to challenge.

Where it shows up

Open source applies these norms to software. Source code is published, as scientific results are; anyone may test and challenge it. Raymond’s bazaar is an open society of code. Many security experts argue that open cryptographic software is more trustworthy than secret software precisely because it can be inspected. Linux’s development, with public review of every change, is organised scepticism in practice.

But Heartbleed, Log4Shell and xz showed the limits. The eyes have to be there, and they have to look. OpenSSL’s flaw went unnoticed for two years; xz’s backdoor was planted in public, in plain sight, and found by accident. Openness makes scrutiny possible, not inevitable.

The strongest objection

The objection is that openness also helps attackers, who can read the code to find weaknesses, and that the xz attack exploited the openness of the community itself, by joining it. Proprietary software, reviewed by professional teams under contract, may be more systematically audited. These points have force. The evidence on whether open or closed software is more secure is mixed. Popper’s point survives in a modified form: openness is necessary for error correction at scale, but it must be organised and funded.

What it means today

For organisations, relying on open code is not the same as relying on audited code; the scrutiny has to be paid for, by the organisation or by someone. For anyone designing a process for catching errors, in software, research or management, openness to criticism matters only if people have the time, incentive and standing to criticise.

5. The commons and its guardians

The idea in plain terms

Open source is a commons: a resource that anyone may use and no one owns. Commons have a reputation for being neglected or overused. Yet some last for centuries. What makes the difference is not the absence of rules but the presence of the right ones, and of people willing to maintain them.

The tradition

Garrett Hardin’s 1968 essay “The Tragedy of the Commons” argued that shared resources are ruined because each user gains from taking more and bears only a fraction of the cost. Elinor Ostrom, in Governing the Commons (1990), showed from studies of fisheries, forests and irrigation systems that communities often manage commons successfully, and identified principles they share: clearly defined boundaries, rules suited to local conditions, participation of users in making rules, monitoring, graduated sanctions, accessible conflict resolution, recognition by outside authorities and, for large systems, nested layers of governance. In 2007 Charlotte Hess and Ostrom extended the analysis to knowledge commons, such as libraries and open-access science, where the problem is not depletion but provision and maintenance.

The legal scholar James Boyle described a “second enclosure movement”: just as common land in England was enclosed into private property from the sixteenth to the nineteenth centuries, the expansion of intellectual property was enclosing the commons of ideas.

Where it shows up

Software is not used up, so Hardin’s tragedy of overuse does not apply. The real tragedy of the open-source commons is under-provision: everyone uses it, and too few maintain it. The successful projects look much as Ostrom would predict. Linux has clear rules for contributions, a hierarchy of maintainers, monitoring through review, sanctions for bad behaviour and nested governance; the Linux Foundation and Apache Software Foundation provide the outside recognition and resources. The neglected projects, such as OpenSSL before Heartbleed and xz before the backdoor, lacked most of these: one or two maintainers, no funding, no monitoring. Copyleft licences are a defence against Boyle’s enclosure; the licence changes by Elastic, HashiCorp and Redis were, from the community’s point of view, attempted enclosures, and the forks were the commons defending itself.

The strongest objection

The objection is that the open-source commons is less a community resource than an industrial one, governed mainly by large companies whose interests dominate. Foundations are funded by corporations; major projects are steered by their employees. Ostrom’s communities of fishers and farmers are a poor analogy. This is an important point, and the governance of open source is more corporate than its origins suggest. But Ostrom’s principles apply to any shared resource, and corporate participants face the same problem of collective action as individual ones.

What it means today

For organisations, the open-source components they depend on are part of their supply chain, and their health is a business risk. Mapping dependencies, identifying those maintained by very few people and funding or contributing to them is ordinary prudence. For policymakers, open-source infrastructure has the character of a public good, and public funding, as some governments now provide, is a reasonable response.

6. Using the law against itself

The idea in plain terms

Copyright gives creators the right to stop others copying their work. Copyleft uses that right to require that others share. It is a legal judo move: the same law that encloses software is turned to keep it open. The licence becomes a kind of constitution for a community, defining what members may do and what they owe.

The tradition

The legal scholar Lawrence Lessig argued in Code and Other Laws of Cyberspace (1999) that behaviour online is regulated by four forces: law, social norms, markets and architecture, which in cyberspace means code. “Code is law,” in the sense that the design of software determines what people can do as effectively as legislation. Licences combine law and code: they are legal texts that govern how code can be used, enforced by courts but mostly by community norms.

Political philosophers in the social contract tradition, from Hobbes and Locke to Rousseau, imagined societies founded on agreements among their members. Open-source licences are explicit social contracts: anyone who uses or distributes the software accepts its terms, and the terms define the community.

Where it shows up

The GPL is the clearest case. Its requirement that distributed modifications be shared is what Ballmer called a cancer and what Stallman called a guarantee of freedom. Permissive licences, such as the MIT and Apache licences, impose few conditions and allow proprietary use; they produced a different kind of community, one more open to companies. The licence wars of the 2020s were fights over the social contract: companies tried to rewrite the terms to exclude cloud providers, and communities rejected the new contract by forking. The OSI’s definitions of open source and open-source AI are attempts to say which contracts count.

The strongest objection

The objection is that licences are rarely read and weakly enforced, so the real governance of open source is social, not legal. GPL violations are common and seldom litigated. And the AGPL and similar licences that try to close the loophole for cloud services are avoided by many companies. That is true in part. But licences set the outer boundaries within which norms operate, and the reaction to licence changes shows how much communities care about them.

What it means today

For organisations, licences determine what they can do with the open-source software they use, and they should be understood, not just collected. For anyone building a community, the rules that define membership and obligations, written or unwritten, are its constitution, and changing them unilaterally invites exit.

7. The right to fork

The idea in plain terms

In open source, anyone can take a copy of a project and start their own version. That right to fork is the ultimate check on those who control a project. If maintainers act against the community’s interests, the community can leave and take the code with it. Forks are rare, because they split effort, but the possibility shapes everyone’s behaviour.

The tradition

Albert Hirschman’s Exit, Voice, and Loyalty (1970) analysed how members of organisations respond to decline: they can leave or speak up. In most organisations, exit means losing what one has invested. A fork is unusual: it is exit that takes the shared asset along. John Locke argued in his Second Treatise that when a government betrays the trust of the people, they may dissolve it and form another; the right of revolution was the final check on power. The right to fork is a peaceful, routine version of that right.

Where it shows up

The history is full of forks. When the community distrusted Oracle’s stewardship of OpenOffice after Oracle bought Sun Microsystems, most developers forked it as LibreOffice in 2010. MariaDB forked from MySQL for similar reasons. The licence changes of the 2020s produced OpenSearch, OpenTofu and Valkey, and the companies that changed licences saw significant parts of their ecosystems move to the forks; two of them restored open-source licences. The right to fork is why corporate stewards of open projects must keep the community’s trust: they control the project, but not the code.

The strongest objection

The objection is that forking is costly and usually fails. Most forks wither, because the original project keeps the developers, brand and users. The right to fork is therefore mostly theoretical, available only to communities large or well-funded enough to sustain a rival. This is largely true: the successful recent forks were backed by large cloud providers. But a deterrent works even when it is rarely used, and the forks that succeeded showed that the threat is real.

What it means today

For companies that steward open-source projects, the community’s ability to fork is a constraint to respect, not a risk to suppress. For leaders of any organisation, the history of forks is a reminder that authority over shared work is held on trust, and that people who can take the work with them will do so if the trust is broken.

8. What openness means for AI

The idea in plain terms

For software, openness meant publishing the source code. For AI, it is less clear what must be shared. A model’s weights can be used and adapted but not understood like code; the training data and process that produced them may matter more and be impossible or unlawful to share. And some argue that powerful models should not be open at all, because anyone could misuse them. The meaning of openness is being renegotiated.

The tradition

The norms of science described by Merton held that knowledge should be common property, subject to public scrutiny. The free-software tradition held that users should be able to study and change the tools that govern them. On the other side, a tradition of thinking about dual-use technologies, from nuclear physics to biotechnology, holds that some knowledge is dangerous enough to restrict. The physicist Leo Szilard urged colleagues in 1939 not to publish research on nuclear fission for fear of helping Nazi Germany; biologists in the 1970s, at the Asilomar conference, paused some genetic engineering research to agree on safeguards.

Where it shows up

Meta’s Llama releases, DeepSeek’s MIT-licensed models and many others have made capable models widely available, and a large ecosystem of researchers and companies builds on them. The OSI’s Open Source AI Definition insists that openness requires enough information about training data for others to understand and reproduce the model, which most “open” models do not provide. Meanwhile, some AI companies keep their most capable models closed, citing both safety and commercial reasons, and governments debate whether to restrict the release of model weights. The language of openness is being used both as principle and as strategy, as when a company releases its models to commoditise a rival’s product, the strategy Spolsky described.

The strongest objection

The objection is that the analogy with software breaks down. Software can be inspected and fixed; model weights cannot be read in the same way, so releasing them does not give users the freedom to understand. And unlike most software, a sufficiently capable model could help people cause serious harm. Openness that was harmless or beneficial for operating systems may be dangerous for AI. This is a serious argument. The counter-argument is that closed models concentrate an extraordinarily powerful technology in a few companies, and that independent scrutiny of AI requires access. The debate is unresolved.

What it means today

For organisations choosing AI models, “open” labels need to be read carefully: what can be used, modified, inspected and redistributed, and what is withheld. For policymakers, the lessons of open source, about the value of scrutiny, the risks of concentration and the fragility of under-funded commons, are relevant, though not decisive, for AI.

Bringing the threads together

Open source rests on the fact that software, like an idea, can be shared without being lost. Stallman turned that fact into a claim about freedom, and used copyright to protect it. People gave their work away for many reasons, from pleasure and reputation to conviction and salary, and their gifts created a commons that companies learned to build on. Openness promised that many eyes would find every error, and delivered when the eyes were there. The commons survived where it had rules and guardians in the shape Ostrom described, and decayed where it had neither. Licences served as constitutions, and the right to fork as the final check on those who governed. Now the same questions are being asked of AI, where openness is harder to define and its risks harder to judge.

The gift that runs the world

When Stallman announced GNU, he promised to give software away to everyone who could use it. When Torvalds announced Linux, he called it a hobby. Neither could have imagined that their gifts would become the foundation of the world’s computing, or that the companies they distrusted would come to depend on them. Open source is one of the great collaborative achievements of the modern era: built in public, by people who mostly never met, and given to everyone.

The history also shows what the gift requires to last. The working principles are not complicated. Know which shared work your organisation depends on, and who maintains it. Give back in proportion to what you take, in money, code or people’s time, not only after a crisis. Respect the rules of the commons you use, and remember that the community can fork. If you release your own work openly, decide in advance what you expect in return, and do not change the terms once others have built on them. And when someone calls a product open, ask what you are free to do with it. Jefferson’s taper gives light without darkening its owner. Someone still has to tend the flame.

Selected bibliography

• Jefferson, Thomas. Letter to Isaac McPherson, 13 August 1813.
• Locke, John. Second Treatise of Government. 1689.
• Mauss, Marcel. Essai sur le don. 1925.
• Merton, Robert K. “The Normative Structure of Science.” 1942.
• Popper, Karl. The Open Society and Its Enemies. Routledge, 1945.
• Samuelson, Paul A. “The Pure Theory of Public Expenditure.” Review of Economics and Statistics 36, no. 4 (1954): 387–389.
• Berlin, Isaiah. “Two Concepts of Liberty.” 1958.
• Olson, Mancur. The Logic of Collective Action. Harvard University Press, 1965.
• Hardin, Garrett. “The Tragedy of the Commons.” Science 162, no. 3859 (1968): 1243–1248.
• Hirschman, Albert O. Exit, Voice, and Loyalty. Harvard University Press, 1970.
• Levy, Steven. Hackers: Heroes of the Computer Revolution. Doubleday, 1984.
• Deci, Edward L., and Richard M. Ryan. Intrinsic Motivation and Self-Determination in Human Behavior. Plenum, 1985.
• Stallman, Richard. “The GNU Manifesto.” Dr. Dobb’s Journal, March 1985.
• Ostrom, Elinor. Governing the Commons. Cambridge University Press, 1990.
• Pettit, Philip. Republicanism: A Theory of Freedom and Government. Oxford University Press, 1997.
• Raymond, Eric S. The Cathedral and the Bazaar. O’Reilly, 1999.
• Lessig, Lawrence. Code and Other Laws of Cyberspace. Basic Books, 1999.
• Benkler, Yochai. “Coase’s Penguin, or, Linux and The Nature of the Firm.” Yale Law Journal 112, no. 3 (2002): 369–446.
• Lerner, Josh, and Jean Tirole. “Some Simple Economics of Open Source.” Journal of Industrial Economics 50, no. 2 (2002): 197–234.
• Spolsky, Joel. “Strategy Letter V.” Joel on Software, June 2002.
• Boyle, James. “The Second Enclosure Movement and the Construction of the Public Domain.” Law and Contemporary Problems 66 (2003): 33–74.
• Hess, Charlotte, and Elinor Ostrom, eds. Understanding Knowledge as a Commons. MIT Press, 2007.
• Eghbal, Nadia. Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Ford Foundation, 2016.
• Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software. Stripe Press, 2020.
• Hoffmann, Manuel, Frank Nagle and Yanuo Zhou. “The Value of Open Source Software.” Harvard Business School Working Paper 24-038, 2024.
• Open Source Initiative. The Open Source AI Definition 1.0. October 2024.

Research limitations

Stallman’s account of the Xerox printer and his motives is his own. The estimate of open-source software’s value comes from a working paper sponsored in part by the Linux Foundation, and its methods have been criticised; the figures are orders of magnitude, not precise values. The figure of $2,000 a year in donations to OpenSSL was widely reported after Heartbleed and does not include consulting income. The account of the xz backdoor relies on public analyses by security researchers; the identity of “Jia Tan” is unknown. Attribution of the term “open source” to Christine Peterson is based on her own account and that of other participants. The description of the licence changes simplifies complex terms, and the companies’ later decisions had several motives. Whether Meta’s and DeepSeek’s models count as open source depends on the definition used; this essay follows the OSI’s position without endorsing it as the only view. The philosophical connections to Jefferson, Samuelson, Locke, Berlin, Kant, Pettit, Mauss, Raymond, Lerner and Tirole, Deci and Ryan, Benkler, Olson, Eghbal, Popper, Merton, Hardin, Ostrom, Hess, Boyle, Lessig, Hobbes, Rousseau, Hirschman, Szilard and the Asilomar conference are the author’s interpretation; their works are paraphrased apart from short, attributed phrases. The decisions in the decisions box are judged by the author, separating what could be known at the time (process) from what happened (call).

Footnotes

1. Manuel Hoffmann, Frank Nagle and Yanuo Zhou, “The Value of Open Source Software,” Harvard Business School Working Paper 24-038 (2024). ↩

2. Richard Stallman, “Initial Announcement”, 27 September 1983; “The GNU Manifesto”, 1985. ↩

3. Free Software Foundation, “What is free software?”; Wikipedia, “GNU General Public License”. ↩

4. Eric S. Raymond, “The Cathedral and the Bazaar” (1997). ↩

5. Christine Peterson, “How I coined the term ‘open source’,” Opensource.com, February 2018. ↩

6. Yochai Benkler, “Coase’s Penguin, or, Linux and The Nature of the Firm,” Yale Law Journal 112 (2002). ↩

7. “How Microsoft went from ‘Linux is a cancer’ to ‘Microsoft loves Linux’,” IDG; “Why Microsoft’s GitHub acquisition matters,” Axios, June 2018. ↩

8. “Heartbleed prompts chastened tech giants to fund OpenSSL,” CIO Australia, April 2014. ↩

9. Otto Kekäläinen, “What Heartbleed and XZ Utils had in common”, 2024; Wikipedia, “XZ Utils backdoor”. ↩

10. “HashiCorp adopts BSL,” InfoQ, August 2023; “Open source wins again! Redis adds GNU AGPL license,” SD Times; WZ-IT, “Open source licence change chronicle”. ↩

11. Open Source Initiative, “The Open Source AI Definition 1.0”, October 2024; OSI forum, “DeepSeek-R1: does it conform to OSAID?”. ↩

12. Thomas Jefferson to Isaac McPherson, 13 August 1813, Founders Online, National Archives. ↩