Open-source software

• 1. Introduction

  ›

  Open-source software is the quiet foundation under an enormous share of modern computing. A 2024 estimate placed its value to firms at $8.8 trillion, with companies projected to spend 3.5 times more on software if they had to build everything themselves. Yet most people who rely on it every day have never thought about how it works, who made it, or why anyone would give it away. The story of open-source software is actually a story about ideology, identity, and a culture of sharing that stretches back to the earliest days of computing. How did a radical idea born in university labs and hacker communities reshape the way the world builds technology? And what happens when corporations worth billions adopt a movement that once defined itself in opposition to them?

• 2. The Hacker Origins

  ›

  During the 1950s and 1960s, programmers routinely shared their work with one another as a matter of course. Early systems such as Unix gave users access to source code, treating collaboration as the default. That culture began to erode in the 1970s and 1980s as the commercial software industry took hold and proprietary models displaced open sharing.

  Richard Stallman watched this shift happen in his own laboratory at MIT. When proprietary software locked down the source code his colleagues had previously shared and improved together, he decided to act. In 1984, he resigned from MIT to build a free operating system called GNU, whose name stood for Gnu's Not Unix. The goal was not merely to replace Unix but to build something superior that anyone could use and modify. He described the kind of freedom he meant using a now-famous phrase: free as in free speech, not free beer.

  In 1985, Stallman founded the Free Software Foundation to promote these ideas and to support GNU's development. To protect his work from being absorbed into proprietary products, he invented a legal concept he called copyleft, and in 1989 he formalized it in the GNU General Public License. That license was updated in 1991, the same year Linus Torvalds introduced a kernel called Linux, which filled the gap GNU had been missing. The combined system is now commonly called Linux.

  Around GNU, the norms that define open-source practice today began to take shape: incorporating others' source code, community bug fixes, and suggestions for new features all became standard. Berkeley Software Distribution, TeX, and the X Window System were among the other projects running alongside GNU during this period, each carrying its own interpretation of what software freedom should mean.

• 3. A Name Change That Split a Movement

  ›

  Christine Peterson suggested the term open source in 1998 at a meeting of free software supporters. The group had grown frustrated that the phrase free software confused newcomers and discouraged corporate interest. They accepted the new label readily, and from that meeting came the Open Source Initiative and its own formal definition of what qualifies.

  The OSI definition drew on the Debian Free Software Guidelines, written primarily by Bruce Perens. Perens had not based his writing on the four freedoms articulated by the Free Software Foundation, which were only more widely available later. The OSI definition differed from the FSF's standard in one significant way: it permitted the inclusion of proprietary software components and allowed more flexibility in licensing terms.

  Stallman refused to accept the new terminology. He acknowledged that the two terms describe almost the same category of software, but he argued that choosing one over the other signals a person's actual goals: development pragmatism on one side, a social and moral stance on the other. The FSF considers free software a subset of open-source software, and Stallman pointed to digital rights management software as the clearest example of the distinction. DRM software can be developed as open source, but because it restricts the people who use it, it does not qualify as free software in the FSF's view.

  An executive at Microsoft called open source an intellectual property destroyer in 2001, capturing how threatened commercial vendors felt. That hostility would not last. IBM, Oracle, and State Farm all developed serious public stakes in the open source market, and Microsoft itself eventually launched a Linux-based operating system, a shift that would have been nearly unimaginable when the decade began.

• 4. The Cathedral and the Bazaar

  ›

  Eric S. Raymond laid out the intellectual framework for how open-source development actually works in his 1997 essay The Cathedral and the Bazaar. He named two contrasting models after their architectural analogies.

  The cathedral model describes traditional software development: centralized, with clearly defined roles for architects, project managers, and implementers. Work happens in relative isolation before a polished product is released. Raymond saw this as the standard approach for commercial software engineering.

  The bazaar model is its opposite. Roles are not fixed. Users are treated as co-developers who are expected to submit bug reports, code fixes, additions, and documentation. The underlying logic is captured in what Raymond called Linus's law: given enough eyeballs, all bugs are shallow. With many people reading the source code, the community will eventually find every problem and suggest solutions. Each contributor's machine also functions as a testing environment, expanding the project's capacity to catch errors.

  The bazaar model calls for early releases, frequent integration of code changes, at least two parallel versions (a feature-rich development version and a stable release), high modularization to allow parallel work on independent components, and a flexible decision-making structure that can adapt to changing user needs. Open-source projects use version control systems such as Subversion and Git to manage these code changes across contributors. Git is now the most widely used version control software in the world. Platforms like GitHub and GitLab host the repositories, while tools like Bugzilla and Redmine organize issue tracking.

• 5. The Legal Architecture

  ›

  Two broad categories of license govern nearly all open-source software: permissive licenses and copyleft licenses. Both differ fundamentally from proprietary licensing in that they allow more people to access the software and to create derivative works, though the specific conditions of each license vary.

  Permissive licenses such as the BSD, MIT, and Apache licenses allow recipients to implement the author's copyright rights without being required to use the same license when distributing their own work. Copyleft licenses work differently. Strong copyleft licenses, including the GNU family, require all derivative works to use the same license. Weak copyleft licenses apply that requirement only under certain conditions. The Mozilla Public License and the Eclipse Public License are examples of weak copyleft. Across both categories, licenses share common features: they grant broad copyright rights, require preservation of copyright notices, and mandate that a copy of the license accompany the code.

  A legal case in 2008 gave open-source licensing significant new force. In Jacobson v Katzer, a court enforced the terms of the Artistic License, including its requirements around attribution and the identification of modifications. The ruling established that violating the conditions of an open-source license is enforceable under copyright law. Because of the Artistic License's similarity to other open-source licenses, the precedent reached broadly across the ecosystem.

  Several unresolved questions still create uncertainty. Whether software counts as a good or a service, what constitutes a modification, and how governance through contract differs from governance through license remain contested. Copyright law became the standard framework for software protection, with computer programs treated as a form of literary work, but jurisdictions continue to interpret this differently. The European Court of Justice, for instance, defines a computer program as excluding its functionality, its programming language, and the format of its data files, a stance that favors open approaches to software use.

• 6. Who Builds It and Who Is Left Out

  ›

  In 2021, the countries with the highest open-source software contributions were, in order, the United States, China, Germany, India, and the UK. Measured by OSS developers per capita, Iceland, Switzerland, Norway, Sweden, and Finland led the world that same year.

  Despite the global reach of online collaboration, open-source contributors cluster geographically. Most tend to be located in dense hubs like Silicon Valley, collaborating primarily within those clusters rather than across borders. Language barriers, cultural differences, and the influence of local professional and social networks all play a role. Studies have also found that most countries show higher acceptance rates for code from contributors within their own country; India is an exception to that pattern.

  Gender representation is a persistent problem. In 2002, women made up only 1.5% of international open-source developers while holding 28% of roles in the broader tech industry. A more recent figure covering 2005 to 2021 puts female participation across OSS internationally at 9.8%, with most of those contributors being recent arrivals to open-source work. The gap is not a matter of productivity; studies have found that women and men contribute at comparable rates when measured by output. The barriers are social. Women in open-source communities report that sexually offensive language is common and that their identity as women tends to receive more attention than their technical contributions. Explicit biases include longer feedback times, heavier scrutiny of code, and lower acceptance rates. The community's prevailing belief that gender should not matter makes structural change difficult, since many contributors frame inclusion efforts as unfair special treatment rather than as corrections to measurable disparities.

  Funding pathways have grown in parallel with the contributor base. Groups like Open Collective allow individuals to contribute monthly to projects they rely on. The Sovereign Tech Fund in Germany directs substantial money toward the software infrastructure the German government depends on. The United States National Science Foundation established its Pathways to Enable Open-Source Ecosystems program to support innovation in the field.

• 7. What the Future Holds

  ›

  A survey found that 78% of companies report running all or part of their operations on free and open-source software. Android and Ubuntu are the examples the community most often cites when arguing about what that success actually means.

  Both are widely regarded as milestones of open-source prominence. Both are also contested within the community. Critics point to Google and its partners downplaying the open-source center of Android, to the Apache license used in Android allowing forks that reduced opportunities for collaborative development, and to features within Ubuntu that track users for marketing purposes. The debate over whether these projects represent victories or compromises captures a tension that has run through the movement since Christine Peterson coined the phrase open source in 1998.

  Government involvement has added another layer of complexity. The UK issued a policy in 2004 directing the government to actively and fairly consider open-source solutions alongside proprietary ones, restating that commitment in 2009. The United States has approached open-source software primarily through the lens of national security, with the Department of Defense evaluating OSS against criteria that include the trustworthiness of its sources, its likely maintenance trajectory, the security of its sub-components, and the degree of foreign governmental influence over it. After Huawei was prevented from using Google's Android system in 2019, the company began developing its own alternative operating system, Harmony OS, illustrating how open-source dependency has become intertwined with geopolitical strategy.

  The Apache web server, which began in 1995 as a group of developers patching frustrations with a pre-existing code base and within a year became the worldwide leading web server, remains one of the clearest demonstrations of what the bazaar model can produce. The question the community is still working through is not whether open-source software works. The question is what it stands for now that the companies once most hostile to it have made it central to their own operations.