Linus Torvalds

Linus Torvalds created Linux as his own version of Unix and released its source code to the public. His decisive move was not simply to make software available, but to invite other programmers to improve it. The resulting system grew through thousands of unpaid contributions from around the world, while Torvalds remained part of the small group that reviewed proposed changes. His role thus embodies a central tension in the book: decentralization can multiply knowledge and solutions, but its results still require a way to be assessed and brought together.

Creating Linux and Opening Its Source

In 1991, Torvalds wrote a version of the Unix operating system and named it Linux. Rather than keep the code to himself, he released it so that anyone able to read computer code could examine what he had made. He accompanied the release with an invitation: “If your efforts are freely distributable, I’d like to hear from you, so I can add them to the system.” The note turned a personal project into an open invitation to collaborate, setting a principle for Linux’s development: useful work could come from outside the project’s originator, and could be incorporated into the shared system.

The response appeared almost immediately. Of the first ten people to download Linux, five returned bug fixes, improvements to the code, or new features. What began as an invitation became an established process: over time, thousands of programmers worked without pay, contributing changes both large and small. Their continuing work made the operating system more reliable and robust. Linux’s growth therefore did not rest on a single burst of authorship; Torvalds’s initial release made it possible for an expanding group to keep revising the system.

A Decentralized System

Linux differs from Windows, which is owned by Microsoft and developed by Microsoft employees. Linux, in the book’s account, belongs to no one. When a problem arises, it is fixed only if someone independently offers a good solution. There are no bosses directing contributors, and no organizational chart assigning each person a defined responsibility. Programmers choose what interests them and leave other problems alone. The arrangement may look haphazard, but it has proved effective: Linux became Microsoft’s most important challenger.

The absence of a formal organization also lets Linux draw on contributors spread around the world. In a conventional corporation, top management hires employees, pays them to work full time, and gives them some direction about which problems to tackle. That structure can mobilize people for a particular task and help a company become skilled at established work. But the company’s potential solutions are limited by the number of workers and the time they have, as well as by organizational and bureaucratic politics. Linux is less constrained by those limits. The supply of programmers willing to contribute is large, and their variety expands the range of possible responses: for any given bug, someone may devise a fix, and someone else may notice the bug in the first place.

Review, Authority, and Aggregation

Decentralized participation does not mean that every proposed change enters Linux automatically. A small number of coders, including Torvalds, vet changes to the operating-system source code. Programmers may contribute from all over the world, but, as the book puts it, “eventually all roads lead to Linus.” His position is therefore not that of a distant founder whose contribution ended with the initial release. He remains among those who assess whether new code belongs in the system.

The book treats this review function as a necessary form of aggregation. If autonomous contributors had no way to combine or evaluate their judgments, the outcome would be limited to whatever solution the smartest person produced, which might not be the best. With a means of bringing different opinions together, a group may produce a solution better than any individual’s. The arrangement is paradoxical: aggregation can resemble centralization, yet it can enable decentralization to work. The analogy is not to central planners assigning production from above, but to a process in which independent contributions remain widely distributed while a decision about what to retain is made.

The account leaves open whether Linux’s code decisions must remain with so small a group. A larger body of programmers, even if its members were less skilled than Torvalds and his close collaborators, might also assess code effectively. But the argument insists that some means of deciding what to include is important to Linux’s success. Torvalds’s dual role—as a participant in an open, dispersed effort and one of its reviewers—makes the distinction visible: distributing the work and aggregating its results are different tasks, and both matter.

Collective Work and Its Significance

Linux’s development serves as an example of how openness and diversity can reveal and repair faults. The book invokes Eric Raymond’s formulation, “Given enough eyeballs, all bugs are shallow.” The saying captures a practical consequence of a broad contributor base: numerous programmers can bring varied attention to a system, making it more likely that a defect will be seen and that someone will offer a remedy. It does not mean that each contributor has the same role or that no one evaluates the code. Linux’s history combines dispersed initiative with review.

The account also places Linux within a broader question about how knowledge can remain local yet become useful collectively. A crowd needs both: individual knowledge must be made available to the whole, without erasing the specific contributions from which it arose. Linux’s open source code lets programmers examine and improve a shared system; its review process helps determine which contributions to incorporate. Torvalds’s significance lies in his part in establishing that pattern. He opened the project to work beyond himself, and remained one of the people through whom the system’s many contributions could be gathered into a functioning whole.