In April 1969, Bell Labs pulled out of an OS development project it had been running for seven years. The “Multics” effort — a three-organization alliance of MIT, GE, and AT&T, hundreds of people strong — had failed to deliver a working system by any of its promised or rescheduled deadlines.
A few months after the withdrawal meeting, one of the former team members sat down at an old PDP-7 minicomputer gathering dust in a Bell Labs storeroom. Ken Thompson, 26-year-old researcher. What he wanted to write was not an OS. It was a space-navigation game.
UNIX begins here.
No approval, no budget, four or five people, initial implementation time roughly one month. Half a century later, its direct descendants and nephews run the iPhone, the AWS servers, and the Android layer through which most of humanity sends messages.
Mission: Starting from retreat
Rewind the timeline to 1964.
Multics was the most ambitious OS project in computing history. Multi-user, ring protection, dynamic linking, large-scale timesharing. It attempted to put every future-facing concept of the era into a single system. MIT, Bell Labs, and GE joined forces; Bell Labs alone contributed more than ten researchers.
The goal of Multics was to give Bell Labs engineers a shared timesharing system. When the agreement was signed in 1964, it was supposed to be working within a few years.
Five years later, it was not.
From March to April 1969, Bell Labs withdrew from Multics. Dennis Ritchie recalled it later: “By 1969, even Bell Labs management and the researchers themselves had come to believe that Multics’s promises would be fulfilled too late and at too great a cost.”
Sam Morgan, then Computing Science Research Director, put it more bluntly: “Multics was trying to climb too many trees at once.”
After the withdrawal, Thompson and his colleagues proposed developing a new OS to Bell Labs management. They were turned down. Millions of dollars in Multics expenditure had just evaporated. The very words “OS development” had become an organizational taboo.
So Thompson switched to a different motivation. He wanted to write “Space Travel,” a game for navigating a spacecraft. It had run on Multics but was expensive to compute and awkward to use. Walking around the Bell Labs storeroom, he found a PDP-7 that nobody was using — a minicomputer introduced around 1965 that was already bordering on obsolete.
To port the game, he needed a file system. To write a file system, he needed an assembler and a loader on top of it. By the time he was done writing, it was almost an OS.
Design: Extracting the best from Multics
The distinguishing feature of UNIX’s design decisions was not that it rejected Multics. It was that it extracted “the things that absolutely had to survive” from Multics and threw everything else away.
What was kept.
A hierarchical file system. One of Multics’s greatest inventions. Files organized in nested directories. Obvious today, but most OSes of the time used flat file lists.
A shell. A thin layer for dialogue between the OS and the user. Type a command, it executes.
Timesharing. Multiple users simultaneously. But not on the grand Multics scale — initially just two users.
What was discarded.
Ring protection. Dynamic linking. Sophisticated virtual memory management. Complex multi-user authentication policies. The many advanced features that had made Multics “Multics.”
And there were two decisively different things.
The first was the “everything is a file” abstraction. Hard disk contents, tape devices, printers — all appear from UNIX as the same kind of file. All operable with the same read() and write() calls. No need to learn a different command set for each device.
The second was the “pipe.” A concept Doug McIlroy had been developing since the 1960s, implemented by Thompson in 1973. Take the output of one program and connect it directly as the input to the next. Just join them with the | symbol.
ls /usr | grep ".txt$" | sort | wc -lFour small tools connected by three pipes. ls knows only how to list files. grep knows only how to filter strings. sort knows only how to sort. wc knows only how to count. None of them knows the overall intent, yet the result — “how many text files are there” — comes out.
McIlroy wrote this design philosophy into four principles in the foreword to the UNIX special issue of the Bell System Technical Journal in 1978:
- Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features.”
- Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
- Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
- Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
A further compression into three lines became the most-cited “Unix philosophy” to take on a life of its own:
Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
Placing the four principles alongside the three lines, you notice that the original uses the verb “throw away” twice. McIlroy’s philosophy may have been less about “combination” and more about “discarding.” Where Multics couldn’t shed features, UNIX was written from the start with the premise of shedding them.
Where Multics was “a giant OS that contains everything internally,” UNIX was “a space for combining small tools.” Contrasting design philosophies born in the same Bell Labs.
Execution: A one-month kernel, the patent department’s budget, and the bet called C
The first UNIX was written in the summer of 1969. Thompson implemented it in roughly four weeks in PDP-7 assembly. The cross-assembler ran on GECOS (GE’s mainframe) and was punched onto paper tape and carried to the PDP-7.
One month of implementing a file system, a shell, and an editor on a machine that loaded its OS from paper tape. Against Multics’s hundreds of people times five years: one man’s summer break.
But moving forward from here required a budget. Bell Labs had not officially approved OS development. Thompson and his colleagues needed to find a different way of describing what they were doing.
The Bell Labs patent department happened to be looking for a document-preparation tool. Patent applications at the time were typed on mechanical typewriters, requiring the entire page to be retyped for each correction. Doug McIlroy’s typesetting program “roff” came to run on UNIX on a PDP-11; Joe Ossanna then developed it into nroff and troff. The patent department was delighted. They provided the budget to purchase a PDP-11/20.
Not an OS budget. A typesetting-tool budget.
This made UNIX an officially sanctioned existence. In 1971 the first manual (V1) appeared. Inside Bell Labs, researchers had begun using UNIX to write documents. The OS existed quietly, as an appendage to the secondary purpose of document creation.
From here, the decisive bet of 1973.
Thompson had been writing a language called “B” from 1969 to 1970. Ritchie developed it further from 1971 to 1973 into a language called “C” — typed, with structures, designed to fit the characteristics of the PDP-11.
In 1973, Thompson and Ritchie rewrote the UNIX kernel itself in C.
OSes of the time were written in assembly, specific to each machine. If the machine changed, everything had to be rewritten. Writing an OS in a compiled language was a bet that traded performance for portability.
A short-term cost — rewriting what was already working.
What happened long-term: in 1976, UC Berkeley began using UNIX on a PDP-11. Because it was written in C, porting took months. In 1977, Bell Labs internally ported UNIX to the VAX-11/780 — again, months. Then IBM 370, various minicomputers, workstations, and eventually PCs.
One round of rework in 1973 made dozens of subsequent ports cheap.
Without UNIX being written in C, the 1980s workstation market, Linux, and macOS would never have existed.
People: Four researchers and a lawsuit as tailwind
Ken Thompson. Born 1943. UC Berkeley alumnus. Worked on Multics at MIT, then Bell Labs. Wrote chess programs, strong in mathematics, tinkered with hardware. Wrote the first UNIX kernel.
Dennis Ritchie. Born 1941. Physics at Harvard, then computer science. Moved from Multics to UNIX alongside Thompson. Designer of the C language. Quiet, logical, an excellent writer. Authored much of the later UNIX literature.
Doug McIlroy. Born 1932. Head of Computing Techniques Research Department (1965–1986). The person who sheltered UNIX institutionally. Proposed the idea of pipes; articulated the Unix philosophy in the 1978 Bell System Technical Journal UNIX issue foreword. A generation older than Thompson’s group, he served as a buffer against upper management.
Joe Ossanna. Born 1928. Developer of troff (typesetting). The bridge to the patent department. He died in November 1977 at 48, but he was the one who made UNIX’s “de facto budgeting” possible.
This group had gathered in the margins of the Multics withdrawal meetings. All four had watched from the inside as a grand plan ground to a halt. They had absorbed in their bodies — not in documents — what adding features made heavy and what stripping away made things run.
And then an accidental external factor intersected with all of this.
AT&T was under an antitrust lawsuit. A 1956 consent decree had effectively barred AT&T from commerce outside telecommunications. UNIX was software; it could not be commercialized.
What cannot be sold can only be given away.
In 1974, AT&T began distributing UNIX source code to universities “for educational purposes, at nearly no cost.” UC Berkeley received it, improved it, and redistributed it. This became BSD. MIT received it. Universities around the world received it.
Being unable to sell it inadvertently created an ecosystem. By 1982 when AT&T’s monopoly was broken and they began selling UNIX, Unix culture had already taken root in universities worldwide.
You could say the lawsuit saved UNIX. Ritchie, characteristically understated, wrote: “We didn’t think UNIX would become widespread. At least, that was not the goal.”
Thompson and Ritchie jointly received the ACM Turing Award in 1983. Citation: “for their development of generic operating systems theory and specifically for the implementation of the UNIX operating system.” Fourteen years after the Multics withdrawal.
Legacy: How many times per second are the four researchers’ creations running on Earth today?
Some figures for 2026.
Most of the world’s servers run Linux. Linux is the kernel Linus Torvalds, a Finnish university student, began writing independently in 1991 because he wanted “something Unix-like that runs on my PC.” No Bell Labs code is in it, but the design philosophy, the shape of the APIs, the philosophy of system calls — all of it comes from UNIX.
macOS runs on a kernel called Darwin, whose lineage connects directly to BSD (UC Berkeley’s UNIX family). That the 1973 rewrite in C runs on a 2026 MacBook is not excessive poetic license — it is literally true.
iOS shares the same lineage as macOS. Android runs on a Linux kernel. Essentially every smartphone in the world is either a direct descendant or a nephew of UNIX.
EC2 instances on AWS, VMs on Google Cloud, major virtual machines on Microsoft Azure — mostly Linux. The OS inside routers that runs the internet is usually Unix-family too.
Nobody holds the exact figure for how many trillions of times UNIX system calls are made per second around the world every moment.
Multics was sold by Honeywell into the late 1970s; new development stopped in 1985. The last Multics system was shut down in 2000.
It is not distorting history to write: the OS that four people wrote in three months outlived the OS that hundreds wrote over seven years by more than thirty years.
One more layer of numbers.
In October 1973, Bell Labs presented UNIX at SOSP (Symposium on Operating Systems Principles). According to Ritchie’s later papers, about 16 external institutions were using it at that point. By the early 1980s it had spread to most major universities and minicomputer manufacturers; from the 1990s on, “counting” itself became meaningless. When Linux appeared in 1991, the concept of cumulative installed base finally collapsed.
UNIX’s successors have absorbed, replaced, or coexisted with IBM System/360, Multics, CTSS, VMS, Windows NT — all of them, across successive generations.
The one exception is the Windows family, which evolved along a separate line. But even Windows has taken UNIX inside itself with WSL (Windows Subsystem for Linux).
Beyond the OS itself, Unix philosophy has permeated modern design thinking. Microservices architecture’s “a service should do one thing well,” REST API’s “text as a common interface,” Docker containers’ “throw it away when you’re done” — these are nearly direct translations of the four principles McIlroy wrote in 1978. The design philosophy of a small OS that ran on the Bell Labs patent department’s budget half a century ago is now a baseline assumption in discussions of Amazon and Netflix infrastructure design.
Lessons: The structure that lets unplanned projects beat planned ones
Of all the lessons extractable from the UNIX story, just one — the sharpest.
There exist projects that survive longer precisely because they proceeded without approval.
This is not an argument that approval processes are bad. Many projects require approval. Infrastructure, regulation, safety — these cannot proceed without it.
But certain software projects are poorly matched to approval processes. For three reasons.
First: approval processes make “the cost of failure” visible. Visible costs delay withdrawal decisions. Multics survived too long in the form of “we can’t back out now after pouring in millions.” The people involved sensed it wasn’t working, but consensus on withdrawal took time.
Second: approval processes constrain “the scope of agreement.” Deviations from what was written in the proposal require re-approval. Re-approval takes time. UNIX’s design decision to “extract the best from Multics and make it small” would never have emerged from an approval process. It couldn’t have been framed as a proposable proposal.
Third: approval processes distribute “responsibility.” A structure that makes clear whose fault something is when it doesn’t work is also a structure where no one makes decisive judgments. UNIX was something Thompson had written “for himself to use,” so nobody owned it. What nobody owns, nobody can stop.
Here the paradox deepens.
Nobody predicted that UNIX would dominate the world ten or twenty years later. Not Thompson himself, not Ritchie, not McIlroy, not anyone in management. So nobody treated it as “an important project.” Because it wasn’t an important project, organizational politics didn’t intervene. Because there was no intervention, the design decisions that four people thought were good got implemented as is.
And those good design decisions ended up dominating the world.
This pattern has repeated. Linux was something Linus Torvalds started writing as a university student because he wanted “a Minix replacement that runs on my PC.” AWS started as Amazon’s internal infrastructure; there was no plan to sell it externally. Git was written in two weeks as a tool for Linux kernel development.
Born outside approval processes, they ended up surpassing what was inside.
The question this yields is not a “pick the right answer” type — it’s a structural trade-off.
Does your organization have projects proceeding without approval? What budget are they running on? If you were to bring them into an approval process as “official work,” what would change?
If the Bell Labs patent department had not funded UNIX, UNIX would have vanished in 1972. To proceed without approval, you need either to find a “secondary purpose” somewhere in the organization, to use your own time off, or to borrow a different budget label — one of the three.
UNIX coexisted with the approval process in the form of “document-preparation tool for the patent department.” It didn’t negate the approval process; it fell into the gaps of the approval process.
Only the people who can find the small margins within an organization can keep an unplanned project alive.
What Multics promised is still not finished. What Thompson wrote “for himself” is still running.
Sources
- Dennis M. Ritchie, “Early Unix history and evolution,” Nokia Bell Labs — primary-source account by Ritchie himself covering the withdrawal timeline, PDP-7 implementation, and motivation for the C rewrite
- Engineering and Technology History Wiki, “UNIX” — member composition after the Multics withdrawal, relationship between PDP-7 and the GECOS cross-assembler
- Multicians.org, “Unix and Multics” — records from the Multics side, including the March/April discrepancy in the withdrawal date and Sam Morgan’s remarks
- Wikipedia, “History of Unix” — features of each version V1–V7, year of the C rewrite, BSD/System V fork
- ACM, “Turing Award — Dennis M. Ritchie” — summary of the 1983 joint award citation
- S. C. Johnson, D. M. Ritchie, “Portability of C Programs and the UNIX System,” Bell Labs (1978) — document verifying portability of an OS written in C, from inside Bell Labs
- Eric S. Raymond, “The Art of Unix Programming,” Ch. 2 “Origins and History of Unix, 1969–1995” — organization of Unix philosophy, impact of AT&T licensing on BSD/System V
- Computer History Museum, “The Earliest Unix Code: An Anniversary Source Code Release” — early code and the circumstances of the patent-department budgeting
- M. D. McIlroy, E. N. Pinson, B. A. Tague, “UNIX Time-Sharing System: Foreword,” Bell System Technical Journal, Vol. 57 No. 6, July–August 1978 — original source of the four Unix principles
