The Open Source Revolution

Zusammenfassung

This article traces the Open Source movement from its origins in the hacker culture of the 1970s, through Richard Stallman’s philosophical crusade for software freedom, to Linus Torvalds’ pragmatic creation of Linux and the eventual mainstreaming of open source as both an ideology and a development model. It is the story of how software written by volunteers — coordinating over the early internet, motivated by curiosity rather than salary — came to run most of the world’s infrastructure.

The World Before Open Source: Software as Property

In the early decades of computing, the question of software ownership barely arose. Computers were enormously expensive, sold to institutions, and the software that ran them was generally shared freely among users — traded on magnetic tapes at conferences, copied between universities, improved collaboratively. At MIT’s Artificial Intelligence Laboratory in the 1960s and early 1970s, the norm was radical openness: source code was left on shared machines for anyone to read, modify, or improve. The community of people writing software was small enough that informal trust governed everything.

Two developments ended this era. First, IBM’s 1969 decision to unbundle software from hardware — announced in June 1969 under pressure from a Justice Department antitrust suit filed that January — meant software was suddenly a product that could be priced, licensed, and sold separately. Second, the 1976 Copyright Act extended copyright protection automatically to software, transforming code from a shared artifact into legally protected intellectual property.

By the early 1980s, the industry had reorganized around proprietary software. Source code was a trade secret. Users received compiled binaries — machine code that a CPU could execute but a human could not meaningfully read. The informal culture of sharing that had driven the first decades of software was being replaced by license agreements, non-disclosure contracts, and locked machines.

One programmer, more than any other, recognized this transition as a catastrophe.

Richard Stallman and the GNU Manifesto

Richard Stallman had been a programmer at MIT’s AI Lab since 1971 — one of the most technically accomplished members of the hacker community that had thrived there. He was also, by temperament, someone for whom principles were not negotiable.

The breaking point came in 1980, when Stallman wanted to modify the software driving a new Xerox printer so that it would notify users when it jammed. Xerox had not provided source code. When Stallman tracked down a researcher at Carnegie Mellon who he believed had a copy, the man refused to share it — he had signed a non-disclosure agreement.

“He’d made a promise to Xerox,” Stallman later wrote, “and by accepting that promise, he’d betrayed the rest of us.”

The incident crystallized a conviction. In 1983, Stallman announced the GNU Project (“GNU’s Not Unix”) — an effort to build a complete free operating system. In 1985 he published the GNU Manifesto, arguing that software freedom was an ethical imperative: users must have the freedom to run, study, modify, and redistribute any software they used. Anything less made them subservient to their tools.

Free Software vs. Open Source

Stallman’s term was “free software” — free as in freedom, not as in price (he used the phrase “free as in free speech, not free beer”). The term “open source”, coined in 1998 by Christine Peterson and promoted by Eric S. Raymond and Bruce Perens, deliberately emphasized the practical development benefits rather than the ethical argument. Stallman has always rejected this framing: for him, the question of software freedom is moral, not pragmatic. The two camps share enormous overlap in practice — Linux, for instance, qualifies as both “free software” and “open source” — but the philosophical distinction remains genuinely contested.

To enforce software freedom legally, Stallman invented a new kind of software license: the GPL (GNU General Public License). The GPL used copyright law against itself. Because software was automatically copyrighted, a copyright holder could attach conditions to its use. The GPL’s condition was elegant and radical: anyone who distributed modified GPL software must release their modifications under the GPL as well. Freedom was self-propagating. Stallman called this mechanism “copyleft.”

By the late 1980s, the GNU Project had produced a remarkable set of tools — the GCC compiler, the Emacs editor, the Bash shell, core Unix utilities — all freely available, all copyleft. There was, however, a missing piece: a kernel.

Linus Torvalds and the Accidental Operating System

On August 25, 1991, a twenty-one-year-old Finnish computer science student named Linus Torvalds posted a message to the Usenet group comp.os.minix:

“I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.”

The understatement was spectacular.

Torvalds had been frustrated that MINIX — a small Unix-like system designed for teaching, created by Andrew Tanenbaum — couldn’t be freely modified and redistributed. He began writing his own kernel: not as an ideological project, but because he wanted to use his new 386 PC and the tools he preferred. The first Linux kernel, version 0.01, was about 10,000 lines of code and ran only on Intel x86 hardware.

What happened next had no precedent in software history. Torvalds posted the source code publicly and invited contributions. Programmers across the early internet — researchers, students, hobbyists — read the code, found bugs, added features, ported it to new hardware, and sent patches back. Within months, Linux had gained drivers, filesystem support, and network capabilities that no single programmer could have written alone.

The match between Linux and the GNU tools was obvious: Torvalds had a kernel without a full set of tools; Stallman’s GNU Project had tools without a kernel. Combined, they formed a complete operating system — typically called GNU/Linux, a naming convention Stallman insists on and most users ignore in favor of simply “Linux.”

The Kernel’s Role

An operating system has two essential parts: the kernel, which manages hardware resources — CPU scheduling, memory allocation, device drivers — and the userland, the collection of tools and libraries that programs actually interact with. Linux is the kernel. The GNU tools (shell, compiler, standard libraries) are the userland. Neither is useful without the other, which is why the naming dispute has some genuine substance behind it.

The Cathedral and the Bazaar

By the mid-1990s, Linux was working — but why it worked so well remained poorly understood. The conventional wisdom in software engineering, dating back to Fred Brooks’ landmark 1975 book The Mythical Man-Month, was that large software projects required careful coordination, clear hierarchy, and controlled development. “Too many cooks spoil the broth” applied to code as much as to kitchens.

Linux appeared to refute this entirely. Thousands of contributors, no central authority beyond Torvalds, no corporate structure, no salaries — and the result was a robust, high-performance operating system kernel.

In 1997, programmer and writer Eric S. Raymond published an essay — later a book — titled “The Cathedral and the Bazaar” that attempted to explain the paradox. Raymond contrasted two development models:

The Cathedral: software built by a small team in private, released when finished — the model of traditional commercial and academic software.
The Bazaar: software developed openly, with many contributors, continuous releases, and public bug reporting — the Linux model.

Raymond’s key insight was Linus’s Law: “Given enough eyeballs, all bugs are shallow.” The more people who could read the source code, the faster any given bug would be found and fixed. The apparent chaos of open development was actually a more efficient error-correction mechanism than private review.

The essay circulated widely and became one of the foundational texts of the open source movement. It also landed at a critical moment: Netscape Communications, facing collapse against Microsoft’s Internet Explorer, read it and made a decision that would reshape the industry.

Netscape, Mozilla, and the Browser That Rose from the Ashes

In January 1998, Netscape announced it would release the source code of its Navigator browser — the product that had once dominated the web and was now being crushed by Microsoft’s bundling of Internet Explorer with Windows.

The release was chaotic. The initial code was a mess of legacy components and licensing complications. The Mozilla project that emerged from it spent years rebuilding the browser from scratch. Navigator itself was effectively dead by the time the work was complete.

But the rebuild produced Firefox (2004), a fast, standards-compliant browser that recaptured a significant share of the browser market and broke the near-monopoly Internet Explorer had achieved. The open source model had, after years of struggle, delivered a commercially competitive product in one of the most visible software categories on earth.

Netscape’s gambit also demonstrated a new business model: a company could open-source its software, build community and trust, and generate revenue from services, support, or complementary products rather than from software licenses. This model — which Red Hat had been pioneering with Linux since the early 1990s — would eventually become the dominant commercial structure for infrastructure software.

Dead End: The Unix Wars

The rise of Linux cannot be fully understood without the wreckage it built upon: the Unix Wars of the 1980s and early 1990s.

Unix, originally developed at Bell Labs by Ken Thompson and Dennis Ritchie, had been licensed to universities and corporations throughout the 1970s. From this single root grew a proliferating forest of incompatible variants: BSD Unix (Berkeley), SunOS (Sun Microsystems), AIX (IBM), HP-UX (Hewlett-Packard), Solaris, SCO Unix, IRIX (Silicon Graphics). Each variant added proprietary extensions, diverged from the others, and resisted interoperability.

The industry attempted to solve this through standards bodies — POSIX, X/Open, OSF — which produced specifications that vendors selectively implemented. The “standards” multiplied as fast as the variants they were meant to unify.

The legal dimension was catastrophic. In 1992, AT&T’s Unix Systems Laboratories (USL) sued the University of California, Berkeley, over BSD Unix — claiming that BSD code infringed on AT&T’s proprietary Unix. The lawsuit froze BSD development for two years. By the time it settled in 1994, with most of BSD’s code cleared, Linux had filled the vacuum. The programmers who might have rallied behind a free BSD had instead built their ecosystem around Torvalds’ kernel.

The Unix Wars ended not with a winner among the commercial variants, but with all of them losing to a free alternative that had entered the market while they litigated each other.

The Fragmentation Trap

The Unix Wars illustrate a pattern that recurs throughout computing history: a technically excellent platform, owned by competing commercial interests, fragments into incompatible variants, each optimized for vendor lock-in rather than ecosystem growth. The resulting fragmentation creates the opening for a unified, freely available alternative — not because the alternative is technically superior at the outset, but because it offers what the fragmented ecosystem cannot: consistency. Compare the similar dynamic in Early Networking Failures, where proprietary networking protocols gave way to TCP/IP.

The Halloween Documents

By 1998, Linux had become serious enough that Microsoft felt compelled to analyze it internally. In October of that year, two internal Microsoft memos — quickly dubbed the “Halloween Documents” after their leak — were published by Eric Raymond.

The memos were remarkable for their frankness. Linux, they acknowledged, was technically competitive with Windows NT in server workloads. Its development model — open, distributed, driven by reputation rather than salary — was difficult for a commercial company to replicate. The memos proposed a strategy: “FUD” (Fear, Uncertainty, and Doubt) — casting doubt on Linux’s legal status, support quality, and long-term viability.

The leak backfired spectacularly. Rather than intimidating the open source community, the documents served as validation: if Microsoft was writing internal strategy memos about Linux, Linux had clearly arrived. The Halloween Documents became a rallying artifact, read at conferences and cited in arguments for years afterward.

Legacy: The Infrastructure of Everything

The open source movement’s victory, measured by infrastructure, is nearly total. As of the 2020s:

The majority of the world’s servers run Linux.
Android — running on billions of smartphones — is built on a Linux kernel.
The cloud infrastructure of AWS, Google Cloud, and Azure runs predominantly on Linux.
The languages, databases, and frameworks that power modern web development — Python, PostgreSQL, MySQL, Node.js, React — are open source.
The AI research explosion of the 2010s and 2020s was enabled by openly published research, open source frameworks (TensorFlow, PyTorch), and open datasets.

The economic model that Stallman considered irrelevant — companies building businesses on free software — turned out to be enormously successful: Red Hat sold to IBM for $34 billion in 2019.

What Stallman could not have predicted, and what Raymond’s bazaar model did not fully capture, is that openness also creates new concentrations of power. A handful of large technology companies now employ the majority of Linux kernel contributors. The “open” infrastructure of the web runs primarily on servers owned by three corporations. Open source won the technical argument; whether it won the freedom argument remains, as Stallman would insist, unresolved.

For the software environment that open source helped create, see The Evolution of Language and The Connected World.