Part IThe Story
A Post to a Newsgroup
On August 25, 1991, a twenty-one-year-old computer science student at the University of Helsinki posted a short message to comp.os.minix, a Usenet newsgroup for users of a small teaching operating system. He had been working on something since April, he explained, and it was starting to get ready. He wanted to know what features people liked and disliked in MINIX. He had ported a couple of common tools, and they seemed to work. He added that he would take suggestions but would not promise to implement them.
— Linus Torvalds, comp.os.minix post, 1991I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.
A postscript warned that the system was not portable and probably never would support anything other than AT hard disks, because that was all he had.
Nearly every prediction in that message turned out to be wrong. The hobby became Linux, the operating system kernel that now runs every one of the five hundred fastest supercomputers in the world, a large share of the servers behind the public internet, the Android phones in billions of pockets, and a vast number of routers, televisions, cars and industrial devices. It was ported to dozens of processor architectures. It became one of the largest collaborative software projects in history. And the student, Linus Torvalds, went on to write a second piece of software, a version control system called Git, that became the standard tool for tracking changes in source code around the world.
This is the story of how an engineer with little interest in leadership theory built one of the most successful organizations in the history of technology, largely by email, and of what he learned when his own style of running it became a problem.
By the Numbers
The Kernel and the Tool
10,239Lines of code in Linux 0.01, released September 17, 1991
176,250Lines of code in Linux 1.0, released March 1994
500 of 500TOP500 supercomputers running Linux, every list since November 2017
4 daysFrom starting Git (April 3, 2005) to Git managing its own source code
93%Share of developers using Git, Stack Overflow survey, 2022
9–10 weeksTypical cadence of a new mainline kernel release
A VIC-20 and a Sinclair QL
Linus Benedict Torvalds was born in Helsinki on December 28, 1969. His parents, Anna and Nils Torvalds, were journalists who had been campus radicals at the University of Helsinki in the 1960s. One grandfather, Ole Torvalds, was a poet; the other, Leo Törnqvist, was a statistician. According to the family, he was named after Linus Pauling, the Nobel Prize-winning chemist, though he later joked that he was named equally for the blanket-carrying character in the Peanuts comic strip.
His interest in computers began in 1981, at the age of eleven, with his grandfather's Commodore VIC-20. He started by programming it in BASIC and moved on to writing machine code directly for its 6502 processor. He later bought a Sinclair QL, an unusual British home computer, and modified it extensively, including its operating system. Software for the QL was hard to find in Finland, so he wrote his own, including an assembler and a few games, among them a Pac-Man clone.
The QL experience set a pattern. Torvalds did not wait for tools to be provided. If the software he needed did not exist, he wrote it, and if the software that existed was not good enough, he took it apart to understand why.
He entered the University of Helsinki in 1988 to study computer science. After his first year he did his compulsory military service in the Finnish Navy's Nyland Brigade, choosing the eleven-month officer training program and finishing as a second lieutenant. He returned to his studies in 1990 and encountered Unix for the first time, on a DEC MicroVAX running Ultrix. He also bought Andrew Tanenbaum's textbook Operating Systems: Design and Implementation, which described MINIX, a simplified Unix-like system Tanenbaum had written for teaching.
Freax, Linux and the GPL
On January 5, 1991, Torvalds bought a PC built around Intel's 80386 processor. He installed MINIX on it and quickly found its limits. MINIX was designed to be read and understood by students, not to be a full working system, and its license restricted how it could be modified and distributed. Torvalds wanted to use the 386's features properly and to connect to the university's Unix machines from home.
He began by writing a terminal emulator that ran directly on the hardware, without MINIX underneath. To download files he needed a disk driver. To store them he needed a file system. Gradually the terminal emulator turned into the beginnings of an operating system kernel. By late summer he had something he could describe to the newsgroup, and on September 17, 1991, version 0.01 appeared on a university FTP server in Finland. It was about 10,000 lines of code.
Torvalds had wanted to call it Freax, a mix of "free," "freak" and the letter X that marked Unix-like systems. Ari Lemmke, a friend who administered the FTP server, named the directory linux instead. The name stuck.
The first release carried a license that forbade commercial distribution. That changed within months. In the autumn of 1991, a fellow student, Lars Wirzenius, took Torvalds to hear Richard Stallman, the founder of the GNU Project and the free software movement, speak at the Helsinki University of Technology. Stallman's GNU General Public License allowed anyone to use, modify and distribute software, including for money, provided they passed on the same rights and the source code. Under pressure from early contributors, and influenced by Stallman's talk, Torvalds announced with version 0.12 that Linux would move to the GPL, effective February 1, 1992. He later said that making Linux GPLed was definitely the best thing he ever did.
The license choice mattered more than any single technical decision. Linux could be combined with the GNU tools, including the compiler, shell and utilities, which Stallman's project had been building since 1984 but which still lacked a working kernel. The result was a complete free operating system, which Stallman and his supporters argued should be called GNU/Linux. The GPL also guaranteed that companies who improved Linux and distributed their versions had to share their improvements. That rule later turned the largest technology companies in the world into contributors.
Linux Is Obsolete
In January 1992, Tanenbaum himself weighed in. In a newsgroup post titled "LINUX is obsolete," he argued that Linux's design was a step backward. Linux was a monolithic kernel, in which the core functions of the operating system ran together in a single program. The academic consensus favored microkernels, which kept the core small and ran most services as separate programs. Tanenbaum wrote that writing a monolithic system in 1991 was a truly poor idea, and he criticized Linux for being tied to the Intel 386.
Torvalds, still a student, responded sharply. He conceded that microkernels might be more elegant in theory, but argued that Linux worked, that it was free while MINIX was not, and that it had been built for the hardware people actually owned. Tanenbaum later said he was not angry and wished Torvalds success. The exchange, preserved in full and published years later in the O'Reilly book Open Sources, became one of the most famous arguments in the history of computing.
It also set out a philosophy Torvalds would hold for decades. He preferred designs that worked now to designs that were theoretically superior. He cared more about how code behaved on real machines than about how it looked on a whiteboard. And he was willing to be told that he was wrong, but only by an argument that survived contact with a working system.
Linux did become portable, and the monolithic design proved flexible enough to support loadable modules and hundreds of hardware platforms. Version 1.0 appeared on March 14, 1994, with about 176,000 lines of code. By then Linux had thousands of users, and early distributions such as Slackware and Debian were packaging it with GNU software for a wider audience.
The Maintainer
The most important thing Torvalds built in the 1990s was a way of working. From the beginning, Linux development took place in public, on mailing lists, with contributors sending patches, small sets of changes to the source code, by email. Torvalds read them, commented on them and decided which to merge into his own tree, which became the official version.
As the project grew, he could no longer review everything himself. A layer of trusted maintainers emerged, each responsible for a subsystem such as networking, file systems or particular hardware drivers. They collected and reviewed patches in their areas and sent them to Torvalds in batches. He trusted their judgment on details and concentrated on the overall structure and on disputes between subsystems. The arrangement was informal at first and later became codified.
The model was described by Eric Raymond in his 1997 essay "The Cathedral and the Bazaar," which contrasted the traditional, closed development of software by small teams with the open, apparently chaotic style of Linux. Raymond coined what he called Linus's Law: given enough eyeballs, all bugs are shallow. The essay influenced Netscape's decision to release the source code of its browser in 1998 and helped popularize the term open source.
Torvalds himself remained wary of grand theories about what he was doing. He described himself as an engineer, and he defended decisions on technical grounds. His authority came from two things. He owned the name, and his tree was the one everyone treated as the real Linux. More important, he had a long record of making sound decisions about code, which gave contributors a reason to accept his calls even when they disagreed.
In August 2000, in a message to the Linux kernel mailing list, he wrote a short line that became a motto for the project.
— Linus Torvalds, Linux kernel mailing list, 2000Talk is cheap. Show me the code.
Transmeta, Trademarks and the Money Question
Torvalds completed his studies at the University of Helsinki in 1996. His master's thesis was titled "Linux: A Portable Operating System." After visiting the company in late 1996, he took a job with Transmeta, a secretive chip start-up in California, and moved to the United States in February 1997. He worked there until June 2003 on software for the company's low-power processors, while continuing to run Linux development in his spare time. Some free software advocates criticized him for working at a company that made proprietary products. Torvalds said he used the best tool for the job.
Around the same time, the project faced its first serious legal threat. In 1994, a Boston attorney named William Della Croce Jr. filed a trademark application for the word Linux, which was granted in 1995. In 1996 he began sending letters to Linux distributors demanding royalties of 10 percent on their sales. Torvalds and four companies and organizations petitioned to cancel the registration. In August 1997 the case was settled, and the trademark was assigned to Torvalds on behalf of the community. It is now administered on his behalf by the Linux Mark Institute.
The late 1990s also made Linux a business. Red Hat and VA Linux, two of the most prominent Linux companies, gave Torvalds stock options in 1999, and both went public that year during the dot-com boom. Torvalds never started a Linux company of his own and never sought to control the commercial ecosystem growing up around his kernel. In 2000, according to Torvalds, Steve Jobs invited him to work at Apple on its new Mac operating system, an offer that would have required him to stop working on Linux. He declined.
The most important commercial validation came from IBM, which announced in December 2000 that it would invest $1 billion in Linux over the following year. For a company that had long sold its own version of Unix, it was a strong signal that Linux was ready for corporate data centers. Other hardware and software companies followed, hiring kernel developers and contributing code. Within a few years, most Linux kernel development was being done by people paid by companies.
Microsoft took the opposite view for more than a decade. In June 2001, its chief executive, Steve Ballmer, told the Chicago Sun-Times that Linux was 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. After Satya Nadella became chief executive in 2014, Microsoft reversed course. It presented a slide declaring that Microsoft loved Linux, joined the Linux Foundation as a top-tier member in 2016, and came to run large numbers of Linux workloads on its Azure cloud.
BitKeeper and the Ten Days
For most of its first decade, the Linux kernel had no formal version control system. Torvalds managed patches with email and archives of source code. Many developers wanted him to adopt a proper tool, but none of the free options, such as CVS, met his requirements for speed and for supporting a distributed group of maintainers.
In 2002, to the dismay of many free software advocates, Torvalds chose BitKeeper, a proprietary system made by Larry McVoy's company BitMover. BitMover offered free licenses to open source developers under restrictive terms. The arrangement worked technically, but it was politically fragile. In 2005, the Australian programmer Andrew Tridgell, creator of the Samba file-sharing software, tried to reverse-engineer BitKeeper's network protocol to build a free client. McVoy had warned that he would withdraw the free license if anyone did this, and he did.
Torvalds suddenly had no tool, and none of the alternatives would do. So he stopped working on the kernel, for the first time since 1991, and wrote his own. He started on April 3, 2005. He announced the project on April 6, and the next day Git was managing its own source code. On April 18 it performed its first merge of multiple branches. By the end of the month it could apply patches to the kernel at a rate of several per second. On June 16, 2005, the kernel's 2.6.12 release was managed with Git.
Git reflected Torvalds's priorities. It was fast. Every developer had a full copy of the project's history, so work did not depend on a central server. It made branching and merging cheap, which suited a project in which thousands of changes flowed in from many directions. It used cryptographic hashes to identify every version of every file, making it hard for history to be silently corrupted. The first commit described it, as a joke, as "the information manager from hell."
He did not stay to run it. On July 26, 2005, he handed maintenance to Junio Hamano, a major contributor, who led it to version 1.0 that December and has maintained it ever since. Torvalds went back to the kernel.
The tool spread far beyond Linux. In 2008 a start-up called GitHub launched a hosting service built on Git, adding a web interface and social features that made it easy to publish, share and contribute to projects. GitHub grew into the central meeting place of open source software and was acquired by Microsoft in 2018 for $7.5 billion. By 2022, 93 percent of developers responding to Stack Overflow's annual survey said they used Git.
The Rhythm of Releases
In 2003 Torvalds left Transmeta for the Open Source Development Labs, an industry consortium set up to support Linux, which paid him to work on the kernel full time. In 2007 it merged with the Free Standards Group to form the Linux Foundation, which has employed him ever since. The arrangement gave him an unusual independence. He was paid by a neutral body funded by many companies, not by any one of them, and he could make technical decisions without a corporate employer's interests in mind.
The kernel's development process settled into its modern form in the years after Git arrived. Each cycle begins with a merge window of about two weeks, during which Torvalds pulls in new features from subsystem maintainers, often at a rate approaching a thousand changes a day. When the window closes, he releases the first release candidate, and the following weeks are devoted to fixing bugs, with a new candidate about once a week. When the code is stable, he makes the final release, and the cycle starts again. A new mainline kernel appears roughly every nine to ten weeks.
The predictability of this rhythm is one of Torvalds's least celebrated achievements. Releases are driven by the calendar, not by features. A feature that is not ready waits for the next cycle, which is never far off. Companies can plan around the schedule, and contributors do not have to fight to get their work into a release that might not come for years.
The version numbers themselves became a sign of his pragmatism. After years in the 2.6 series, Torvalds moved to 3.0 in July 2011, for the project's twentieth anniversary, and later made major version changes whenever the minor numbers grew unwieldy, rather than to mark significant technical breaks. In December 2022, with Linux 6.1, the kernel accepted its first support for code written in Rust, a newer language designed to prevent many kinds of memory errors, alongside the C in which the kernel had always been written.
The Apology
Torvalds's style on the mailing lists was famous and, for many, notorious. He could be blunt to the point of cruelty, and he sometimes directed profanity and personal insults at contributors whose code or arguments he thought were bad. He defended this for years as a necessary way of making his technical points clear and of protecting the quality of a system that billions of people depended on. Critics, including the kernel developer Sage Sharp, argued that the tone drove people away and made the community hostile to newcomers. An academic quoted by The New Yorker in 2018 suggested the emails may have contributed to the male-dominated culture of kernel development.
In September 2018, events came to a head. The New Yorker had approached Torvalds with questions about his conduct for an article it was preparing. On Sunday, September 16, the kernel's brief Code of Conflict was replaced by a Code of Conduct based on the Contributor Covenant, a template used by tens of thousands of open source projects. The same day, in the announcement of the Linux 4.19-rc4 release candidate, Torvalds wrote that people in the community had confronted him about his lifetime of not understanding emotions, and that his flippant attacks in emails had been unprofessional and uncalled for.
— Linus Torvalds, Linux 4.19-rc4 release announcement, 2018I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely.
He said he would take time off to get help on how to behave differently, and he compared the break to the one he had taken in 2005 to write Git. Greg Kroah-Hartman, one of the senior maintainers, finished the 4.19 release. Torvalds returned to maintaining the kernel after it was released on October 22, 2018.
The episode was widely covered and was interpreted in different ways. Some saw it as overdue recognition that technical excellence did not require abuse. Others worried that the new code of conduct would be used to settle scores. What was notable was that the project continued without interruption, with the same release rhythm, through the absence of its founder. The structure he had built was strong enough to run for a time without him.
The Long Middle
In the years since, Torvalds has continued to do the same job he has done since 1991. He merges code, arbitrates disputes, writes long explanations of why particular changes are right or wrong, and sets the tone of the project, now in more measured language than before. He said in 2012 that he wrote little code of his own any more, and that his work consisted mostly of merging other people's.
He has received many honors. He was named one of Time's most influential people in 2004 and was inducted into the Computer History Museum's Hall of Fellows in 2008 and the Internet Hall of Fame in 2012. In 2012 he shared the Millennium Technology Prize, awarded by Technology Academy Finland, with the Japanese stem cell scientist Shinya Yamanaka; each received 600,000 euros. The IEEE Computer Society gave him its Computer Pioneer Award in 2014. He also co-wrote an autobiography, Just for Fun, with the journalist David Diamond, published in 2001.
His habit of writing his own tools has carried over into his hobbies. After taking up scuba diving in the early 2000s and earning a series of certifications, he started Subsurface, an open source program for logging and planning dives, and worked on it alongside the kernel. It was the same pattern as the Sinclair QL and Git: when the available software did not do what he wanted, he wrote something that did, released it publicly and let other people improve it.
He has resisted most invitations to become a spokesman for open source as a movement. He has said open source is the only right way to do software, but he has avoided the ideological arguments about freedom that animate Stallman and many others. He prefers to talk about code.
The project he started has outgrown him in every measurable way. Thousands of developers contribute to the kernel, most of them paid by companies that compete fiercely with one another in other markets. Its code runs in data centers, phones, cars and factories. And the principles Torvalds applied from the beginning, public review, working code over theory, trusted delegation and a steady release rhythm, have become the default way of building large software projects in the open.
Part IIThe Playbook
Torvalds rarely talks about management, and he would reject the idea that he has a leadership philosophy. But the Linux kernel is one of the most successful long-running engineering organizations in the world, and its methods, most of them set by Torvalds, can be studied like those of any company. The principles below are drawn from how he built and ran the project, including the parts he later came to regret.
The principles
- 1.Scratch your own itch.
- 2.Release early and ask for feedback.
- 3.Choose the license that turns rivals into contributors.
- 4.Prefer what works to what is elegant.
- 5.Judge the patch, not the pitch.
- 6.Delegate by subsystem and trust your lieutenants.
- 7.Build the tool when no tool exists.
- 8.Hand off what you have finished inventing.
- 9.Ship on a calendar, not a wish list.
- 10.Stay neutral among the companies that pay.
- 11.Protect the name as well as the code.
- 12.Fix the maintainer, not only the code.
Principle 1
Scratch your own itch.
Linux began because Torvalds wanted a better system for his own new PC. He needed a terminal emulator to connect to the university's machines, then a disk driver, then a file system. Every early feature solved a problem he personally had. This gave him a clear standard for judging what to build, since he could test each piece by using it himself.
The same was true of Git. He wrote it because the kernel needed a version control system and nothing available met his needs. Because he was the most demanding user, the tool was designed around the hardest real case, not an imagined one.
Tactic: Start new projects by solving a problem you face every day. You will understand the requirements better than any outside customer could describe them, and you will know immediately whether your solution works.
Principle 2
Release early and ask for feedback.
Torvalds announced Linux to the MINIX newsgroup before it was really usable and asked people what features they wanted. He released version 0.01 a few weeks later, with a hardcoded Finnish keyboard and support for very little hardware. The early users who downloaded it found bugs, sent fixes and suggested improvements. Within months other people were making real contributions.
This habit, later described by Eric Raymond as release early, release often, turned users into collaborators. It also gave Torvalds constant evidence about what mattered, because the people using the system told him.
Tactic: Share work in progress with the people most likely to use it, before it feels ready. Ask specific questions about what they need, and treat their bug reports as a gift rather than a criticism.
Principle 3
Choose the license that turns rivals into contributors.
Torvalds's original license banned commercial distribution. Switching to the GPL in 1992 opened Linux to companies while requiring them to share any improvements they distributed. This turned out to be the key to the kernel's growth. Firms that competed bitterly with one another, such as chipmakers, server vendors and phone makers, all found it worthwhile to improve Linux, and the license ensured that each company's improvements flowed back to the others.
The choice shows how the rules of a system determine who participates. An open platform with the right sharing rules can attract far more investment than any single owner could provide, and the resulting network effects make it steadily harder to displace.
Tactic: When you create a shared resource, design the rules so that each participant's contributions benefit everyone else. The right incentives can turn competitors into co-investors.
Principle 4
Prefer what works to what is elegant.
When Tanenbaum argued in 1992 that Linux's monolithic design was obsolete, Torvalds did not claim it was theoretically superior. He argued that it worked on the machines people actually had and that it was free. Over the following decades, the monolithic kernel proved adaptable enough to run on everything from phones to supercomputers, while the microkernel-based GNU Hurd, the kind of system Tanenbaum had recommended, never reached wide use.
Torvalds consistently judged technical choices by their behavior in practice. He adopted BitKeeper despite ideological objections because it did the job, and he mixed Rust into a C code base when it offered real safety benefits. He was pragmatic rather than doctrinaire.
Tactic: When choosing between approaches, prototype both where you can and compare their behavior on real workloads. Give theoretical elegance weight only when it produces measurable benefits.
Principle 5
Judge the patch, not the pitch.
Talk is cheap; show me the code. Torvalds's motto set the standard for contributions to Linux. A proposal was not taken seriously until it came with working code that could be read, tested and merged. Contributors could not win arguments by seniority, credentials or eloquence. They had to demonstrate that their change worked.
This had several benefits. It kept discussions concrete, it rewarded people who did the work, and it made the project open to anyone who could write good code, regardless of where they came from. It also created a public record of every decision, since the patches and reviews were archived on the mailing lists.
Tactic: In technical discussions, ask for a prototype or a working example before debating a design in the abstract. Evaluate proposals on what they demonstrate, not on who proposes them.
Principle 6
Delegate by subsystem and trust your lieutenants.
As Linux grew, Torvalds could no longer review every patch. He relied on subsystem maintainers who each owned an area of the kernel and sent him collected changes. He trusted their judgment in their domains and focused on cross-cutting issues and final decisions.
The structure let the project scale from a handful of contributors to thousands without Torvalds becoming a bottleneck. It mirrors the modular design of the kernel itself, in which subsystems communicate through defined interfaces. The organization's shape matched the architecture of the code it produced.
Tactic: Divide large projects along the natural boundaries of the work, and give each area a clear owner with real authority. Review the owners' output in batches rather than every individual decision.
Principle 7
Build the tool when no tool exists.
When BitMover withdrew the free BitKeeper license in 2005, Torvalds did not settle for an inadequate alternative. He stopped kernel development and spent a couple of weeks writing Git, designing it around the specific demands of the Linux project: speed, distributed history, cheap branching and protection against corruption.
The investment paid off far beyond Linux. A tool built to meet the hardest real requirement turned out to meet everyone else's requirements too. Git's design choices became standard across the software industry.
Tactic: When your team's work is blocked by inadequate tools, estimate the cost of building a better one against the cost of living with the limitation. For core workflows, building your own can be the highest-return investment you make.
Principle 8
Hand off what you have finished inventing.
Torvalds wrote Git in the spring of 2005 and handed it to Junio Hamano in July of the same year. He had solved the problem he needed to solve, and he recognized that the long work of refining and maintaining the tool was a different job, better done by someone who wanted to do it. Hamano has maintained Git for two decades.
Letting go allowed Torvalds to return to the kernel, which was his real responsibility. It also gave Git a dedicated steward rather than a distracted founder.
Tactic: When you have built something that works, ask whether you are the best person to maintain it over the long term. If not, find a capable successor early, and give them real ownership.
Principle 9
Ship on a calendar, not a wish list.
The kernel's release process is based on time rather than features. A two-week merge window is followed by several weeks of stabilization, and a new release comes out roughly every nine to ten weeks. Features that are not ready simply wait for the next cycle.
This rhythm reduces pressure to rush unfinished work and makes the project predictable for the companies that depend on it. It also sustains iteration velocity: a steady flow of small releases, each one tested, rather than rare large ones that accumulate risk.
Tactic: Set a fixed release cadence and hold to it. When a feature is not ready, move it to the next release instead of delaying everything else.
Principle 10
Stay neutral among the companies that pay.
Most kernel developers are paid by companies that compete with one another. Torvalds has worked for the Linux Foundation, a neutral body funded by many members, since 2007, and for its predecessor since 2003. He has never started a Linux company or tied himself to one vendor.
That neutrality is central to his authority. Contributors can trust that his technical decisions are not made to benefit any particular employer. It also allows competitors to collaborate on shared infrastructure without fearing that one of them controls it.
Tactic: If you lead a shared project, structure your own position so that you do not depend financially on any single participant. Your perceived independence is part of what makes others willing to contribute.
Principle 11
Protect the name as well as the code.
The GPL protected the Linux code, but it did not protect the name. When a stranger registered the Linux trademark and demanded royalties, Torvalds and several community groups fought to cancel it, and the settlement assigned the mark to Torvalds on the community's behalf. He has since administered it through the Linux Mark Institute.
An open project can still be captured through its name, its domain or its brand. Protecting those assets keeps the community's work from being turned against it.
Tactic: For any project you want to keep open, secure the trademarks, domains and other identifiers early and put them under trusted control. Openness in the code does not guarantee control of the identity.
Principle 12
Fix the maintainer, not only the code.
For years Torvalds treated his harsh style as a feature of his job. In 2018 he acknowledged publicly that it had hurt people and possibly driven them away. He apologized, took time off to learn to behave differently, and supported the adoption of a code of conduct.
The episode showed that a project's culture is as much a part of its infrastructure as its tools. A leader's behavior sets norms for everyone else, and those norms determine who is willing to join. Torvalds's change of approach helped the project maintain trust among a wider group of contributors.
Tactic: Periodically ask people you trust how your behavior affects the team, and take the answers seriously. Treat problems in your conduct with the same rigor you would apply to a bug in your code.
Free playbook
Get The Business Model Playbook
58 business models, one visual page each: how the money flows, the metrics that matter, and who runs it. Free when you join the Faster Than Normal email.
Free. No spam. Unsubscribe anytime.
Part IIIMaxims
-
Small beginnings hide large outcomes. Linux started as a student's side project with a postscript apologizing for its limits. Predictions about what a project will become are usually wrong in both directions.
-
The best licenses are incentive systems. The GPL did more to grow Linux than any single piece of code. Rules about sharing shape who participates and why.
-
Authority comes from a record, not a title. Torvalds leads because contributors have seen decades of sound decisions. Every good call adds to the credit a leader can draw on in disputes.
-
Arguments end where benchmarks begin. The monolithic-versus-microkernel debate was settled by what ran well on real hardware. Measure before you argue.
-
Tools shape habits. Git made branching cheap, and a generation of developers changed how they work. The right tool can change a culture faster than any policy.
-
Neutral ground attracts rivals. Competing companies will collaborate on shared infrastructure only if no one of them controls it.
-
Predictability is a gift to contributors. A regular release rhythm lets thousands of people plan their work without asking permission.
-
Culture scales like code. Norms set by a founder spread to every corner of a project. Bad habits are copied as readily as good ones.
-
Some of the best leaders never meant to lead. Torvalds wanted to write an operating system and ended up running one of the largest collaborations in history. Responsibility often arrives through the work.
In Their Own Words
I was looking for something to do, a project. And I thought, 'OK, I'll write a terminal emulator.' It grew from there.— Linus Torvalds
I'm not a visionary. I'm an engineer. I'm happy with the people who are wandering around looking at the stars, but I'm looking at the ground, and I want to fix the pothole that's right in front of me before I fall in.— Linus Torvalds
Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.— Linus Torvalds
Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect.— Linus Torvalds
The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it.— Linus Torvalds
The fact that somebody can replicate what you did, or at least try to replicate what you did, is what makes it science. Otherwise it's just voodoo.— Linus Torvalds
I often compare open source to science. To where science took this whole notion of developing ideas in the open and improving on other peoples' ideas and making it into what science is today and the incredible advances that we have had. And I compare that to witchcraft and alchemy, where openness was something you didn't do.— Linus Torvalds
The nice thing about standards is that there are so many of them to choose from.— Linus Torvalds
I'm not a people person. I'm a technology person. But I do realize that Linux is not just about the technology, it's about the people.— Linus Torvalds
Bad programmers worry about the code. Good programmers worry about data structures and their relationships.— Linus Torvalds
I like to think that I've been a good maintainer. That I respond to people, that I'm fair, and that I make good technical decisions.— Linus Torvalds
The way to do good basic design isn't actually to be really smart about it, but to try to have a few basic concepts that work well together and then apply them very broadly.— Linus Torvalds
Software is like sex: it's better when it's free.— Linus Torvalds
I want my programs to be readable. I want to be able to understand what the program does by looking at it.— Linus Torvalds
The memory management on the PowerPC can be used to frighten small children.— Linus Torvalds
Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it.— Linus Torvalds
I'm generally a very pragmatic person: that which works, works.— Linus Torvalds
My name is Linus, and I am your God.— Linus Torvalds
I don't expect to go hungry if Linux becomes obsolete.— Linus Torvalds
I'm sitting in my home office wearing a bathrobe. The same way I'm not going to start wearing ties, I'm also not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords.— Linus Torvalds
See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too.— Linus Torvalds
Intelligence is the ability to avoid doing work, yet getting the work done.— Linus Torvalds
Further reading
- Just for Fun: The Story of an Accidental Revolutionary by Linus Torvalds
