A twenty-minute hallway pitch funded the first internet
Where Wizards Stay Up Late holds that open collaboration and informal standards, not nuclear panic, produced the ARPANET.
IJR · Nov 6, 2026 · 11 min read
In 60 seconds
- Bob Taylor's twenty-minute hallway pitch won a million-dollar ARPA program to link expensive university mainframes so one terminal could reach any machine.
- Larry Roberts overcame resistant principal investigators by offloading traffic onto dedicated IMPs instead of the hosts themselves.
- Small firm BBN, not a giant contractor, built the first ruggedized Honeywell IMP in under nine months and delivered it to UCLA in fall 1969.
- Charley Kline's first remote login on October 29, 1969 crashed after the letters l and o; four nodes were live by December.
- Steve Crocker's RFCs made host rules provisional documents anyone could challenge, yielding the Network Control Protocol.
- Kahn and Cerf's TCP/IP linked incompatible nets by the end-to-end principle; ARPANET cut over on January 1, 1983.
The big idea
Hafner and Lyon argue the ARPANET grew from the practical need to share costly university computers, not from a mandate to survive nuclear attack. They find that open collaboration, provisional standards, and real authority for graduate students and small engineering teams built more durable infrastructure than central planning.
The book in brief
Charley Kline typed the first two letters of login on October 29, 1969, and the UCLA-to-Stanford link crashed. Hafner and Lyon treat that glitch as the honest birth of the ARPANET: partial failure, student operators, and months of debugging still ahead.
The story opens with Bob Taylor's plainer headache at ARPA. The agency was already paying for expensive mainframes at MIT, Berkeley, and other campuses, and every research group wanted its own terminals to every machine. Taylor stopped director Charles Herzfeld in a hallway, argued that linked computers would let one terminal reach all of them, and left twenty minutes later with a million-dollar program redirected from another project. Licklider's earlier intergalactic-network vision supplied the long dream; resource sharing unlocked the money.
Taylor pulled Larry Roberts from Lincoln Lab to run it. Principal investigators feared losing cycles to other people's traffic. Roberts, with Wesley Clark, answered by placing a dedicated Interface Message Processor at each site so hosts stayed free of the networking load. ARPA bid the hardware. Small Cambridge firm BBN, led by Frank Heart with Severo Ornstein and Will Crowther, beat larger rivals, built the first ruggedized Honeywell IMP in under nine months, and delivered it to UCLA in fall 1969. Packets soon ran to Stanford Research Institute. By December four nodes were up: UCLA, SRI, UC Santa Barbara, and Utah.
Graduate students still needed common rules. Steve Crocker invented Requests for Comments—deliberately tentative notes anyone could revise. That habit produced the Network Control Protocol and locked in a culture of living standards. Packet switching itself still faced doubters at places like AT&T. Robert Kahn's 1972 public demonstration in Washington let outsiders drive real traffic across the network and shifted professional opinion. Ray Tomlinson's 1971 @ convention made email so useful it quickly dominated traffic and outgrew the original resource-sharing goal.
By the mid-1970s satellite and radio packet nets existed beside the ARPANET. Kahn, now at ARPA, and Vint Cerf at Stanford designed TCP/IP so data could cross independently administered networks without assuming anything about their internals—the end-to-end principle. On January 1, 1983 every ARPANET site cut over from the old protocol to TCP/IP. The authors land on the larger claim: durable infrastructure can emerge from loose coordination, graduate-student authority, and open revision rather than from central command or a single inventor.
Context
Katie Hafner and Matthew Lyon published the account in 1996, reconstructing events mainly from interviews with the original engineers twenty to twenty-five years afterward. The book offered an early human-scale history of how a defense research project acquired its open technical culture, appearing just as the web and commercial providers began turning the technology into a mass product.
The key ideas
1
The hallway funding fix
Taylor unlocked a million-dollar program by showing that one linked terminal could replace separate connections to every costly mainframe.
ARPA funded computer science at universities across the country in the 1960s. J.C.R. Licklider had already sketched an intergalactic network where people shared machines and ideas at a distance. His successor Bob Taylor inherited a concrete cost problem: each site wanted dedicated access to multiple expensive mainframes.
Taylor stopped Charles Herzfeld in a hallway and made the case in twenty minutes. Link the computers and one terminal reaches all of them. Herzfeld authorized a million-dollar research program on the spot and pulled the money from another project.
Later popular stories claimed the network was built to ride out a Soviet nuclear strike. Hafner and Lyon separate that tale from the record. Paul Baran's RAND research on distributed networks resistant to attack shaped design philosophy, yet it was not the direct trigger for ARPA's project.
The authors frame the real start as resource sharing among scientists. Infrastructure, they show, often begins with a small practical headache and people who can move money fast.
In practice: Taylor's twenty-minute hallway pitch that secured Herzfeld's on-the-spot million-dollar authorization.
2
The reluctant broker
Roberts mattered less as the brightest engineer than as the broker who could force proud principal investigators to cooperate.
Taylor needed a manager who understood networking and could handle ARPA-funded research directors. Those directors were independent and disliked Pentagon direction. He recruited Larry Roberts from MIT's Lincoln Laboratory, using ARPA's funding leverage over the lab to make the move stick.
Roberts hesitated. University research looked more prestigious than a bureaucratic post. Once installed he ran meetings with the principal investigators, who feared a shared network would drain their cycles for other people's traffic.
His answer, refined with Wesley Clark, was the Interface Message Processor. A smaller dedicated machine at each site would handle network traffic so the main computer stayed free. That technical fix let cooperation begin.
Hafner and Lyon treat Roberts as the broker figure big technical shifts require: enough standing among skeptics, enough backing from funders, and the discipline to turn competing labs into one distributed effort.
In practice: Roberts proposing the IMP so host computers would not carry other sites' traffic.
3
BBN beats the giants
Heart's compact BBN crew shipped the first IMP in under nine months because hands-on speed beat institutional prestige.
ARPA put the IMP contract out for bid. Much of the computing world expected IBM or a major systems contractor to win. The small Cambridge firm Bolt Beranek and Newman, known mainly for acoustics, submitted a detailed proposal drafted largely by Frank Heart's group.
BBN argued it understood hardware-software integration in ways larger bureaucratic outfits had not shown. Heart led a tight crew that included Severo Ornstein and programmer Will Crowther. They worked with unusual intensity and informality, often through the night—the image that gives the book its title.
They built the first IMP on a ruggedized Honeywell minicomputer in under nine months, a schedule aggressive even then. Delivery reached UCLA in fall 1969. Packet traffic between UCLA and Stanford Research Institute began soon after.
The authors hold that choosing an organization built for speed over one with more prestige was decisive. Without BBN's compressed build, Roberts's architecture would have stayed theoretical far longer.
In practice: BBN's first IMP arriving at UCLA in fall 1969 and quickly carrying packets to SRI.
4
Two letters then a crash
Kline's failed lo on October 29, 1969 shows early networks advance by multi-node debugging, not a flawless debut.
- October 29, 1969Kline's lo crashes the UCLA–SRI link
- Same sessionReset lets the full login complete
- December 1969Four nodes live: UCLA, SRI, UCSB, Utah
On October 29, 1969, UCLA graduate student Charley Kline tried to log in remotely to a Stanford Research Institute computer. He typed l and o of the command login. The system crashed. The connection had to be reset before the full word went through.
Hafner and Lyon refuse the triumphant retelling. They present the moment as a glitch-ridden test typical of experimental engineering. Graduate students and young researchers ran the network with minimal oversight and wide latitude for design choices—far from buttoned-down defense-contractor stereotypes.
By December 1969 four nodes were connected: UCLA, Stanford Research Institute, UC Santa Barbara, and the University of Utah. Each new node brought fresh failure modes. Daily work meant diagnosing dropped packets, wrong routing tables, and IMPs that disagreed about network state.
The larger point is that mythology of instant breakthrough hides the iterative, unglamorous labor that actually made the system durable.
In practice: Kline's login attempt crashing after two letters, then succeeding only after a reset.
5
RFCs anyone can revise
Crocker's deliberately non-authoritative RFCs let anyone challenge host rules and kept the network adaptable as sites multiplied.
As more sites joined, operators of the host computers needed shared rules for how machines would talk. Steve Crocker, a UCLA graduate student, proposed a lightweight documentation process called Requests for Comments.
He chose the name to sound tentative so no one would feel locked out of revising or challenging a proposal. The process invited contributions regardless of institutional seniority and treated specifications as living documents open to critique.
The Network Working Group used RFCs to work out the Network Control Protocol, the ARPANET's original method for establishing host connections. That protocol was later replaced by more robust 1970s designs, but the habit of open drafts remained.
Hafner and Lyon frame this informal, meritocratic, consensus-driven style as one of the network's most consequential inventions, arguably as important as any hardware piece. Because standards stayed negotiable, the system could evolve without a single approval bottleneck.
In practice: Crocker's RFC process producing the Network Control Protocol through community critique rather than decree.
6
Live demo shifts opinion
Kahn's 1972 unscripted public demonstration proved packet switching under real traffic and changed minds faster than papers.
Packet switching breaks messages into small chunks routed independently across a shared network. Telephone-style systems instead reserve a dedicated circuit. Established telecommunications engineers, including some at AT&T, doubted packets could work reliably for real traffic.
The book credits Paul Baran's RAND work and, separately, Donald Davies at the UK National Physical Laboratory with early versions of the idea. Larry Roberts and BBN's engineers turned it into working gear.
In 1972 Robert Kahn organized a large public demonstration at the International Conference on Computer Communication in Washington, D.C. Outside experts sat at terminals and moved actual research and administrative traffic across the growing network in real time.
Hafner and Lyon argue hands-on evidence under unscripted conditions shifted professional opinion more than private tests or published theory. The same stretch saw Ray Tomlinson introduce the @ addressing convention in 1971; email soon dominated traffic and outgrew the original resource-sharing justification.
In practice: Conference attendees in 1972 driving live ARPANET sessions and watching packet switching hold up.
7
TCP/IP joins the nets
Kahn and Cerf pushed reliability to the endpoints so incompatible networks could interconnect without matching internals.
- EndpointsApplications ensure reliable delivery
- TCPSequences and packages the data
- IPAddresses packets across independent nets
- Local netsARPANET, satellite, or radio keep their own internals
By the mid-1970s satellite-based and radio-based packet networks existed beside the ARPANET, each with its own protocols. Robert Kahn, who had moved from BBN to ARPA, saw that future value lay in connecting these disparate nets, not only enlarging the original one.
Working with Vint Cerf at Stanford, he designed the Transmission Control Protocol and Internet Protocol. TCP/IP let data travel across multiple independently administered networks through a common addressing and packaging scheme.
The design assumed nothing about the reliability or internal structure of the underlying networks. Responsibility for reliable delivery sat at the endpoints—an approach later called the end-to-end principle.
ARPANET formally switched from the older Network Control Protocol to TCP/IP on January 1, 1983, in a coordinated cutover at every site. Hafner and Lyon present this as the moment the ARPANET became one piece of a larger internet rather than the whole system, and as a more consequential step than the original hardware.
In practice: The January 1, 1983 cutover that moved every ARPANET site onto TCP/IP in one coordinated day.
Key terms
- ARPANET Packet-switched research network ARPA funded from the late 1960s
- IMP Interface Message Processor; dedicated machine that handled site traffic so hosts did not
- RFC Request for Comments; provisional technical note open to anyone's challenge
- Network Control Protocol ARPANET's original host-connection method, later replaced by TCP/IP
- packet switching Splitting messages into small chunks routed independently on a shared network
- TCP/IP Kahn-Cerf protocols that let separate networks exchange data with common addressing
- end-to-end principle Design choice that leaves reliable delivery to endpoints, not the network core
- BBN Bolt Beranek and Newman; small Cambridge firm that built the first IMPs
What to do
- Publish draft standards explicitly open to challenge, as Steve Crocker did with the first RFCs.
- Give implementation power to the people closest to the hardware, the way Frank Heart's night crew ran the IMP build.
- Demand a live unscripted demo before skeptics before accepting a big technical claim, following Robert Kahn's 1972 conference.
- Budget time for small crashes like Charley Kline's failed lo instead of reading first failure as proof the approach is wrong.
- Recruit a broker who can force consensus among proud experts when rival teams must share infrastructure, as Bob Taylor did with Larry Roberts.
Questions to think with
- What costly duplication in your world is large enough to justify a Taylor-style linking pitch?
- Where are final specifications locked before real users have broken them, contrary to the RFC habit?
- Who closest to the technical problem still lacks the decision power Heart and Roberts actually used?
- What would a 1972-style public demo of your current project look like in front of its toughest skeptics?
- Which separate systems need a TCP/IP-style bridge more than they need internal perfection?
The other side
The book's greatest strength—its close reliance on interviews with original engineers—is also its central limit. Hafner and Lyon reconstruct events from memories spoken twenty to twenty-five years later, and credit memories in technology history are self-serving and contested. Critics, including some of the book's own sources, say it underplays Donald Davies and the UK National Physical Laboratory's parallel packet-switching work and still leaves unclear how much Paul Baran's RAND research directly shaped ARPA engineering choices. The narrative is thin on the network's international life after the mid-1970s and on how European and other national nets later negotiated with American protocols. Written in 1996, it largely ignores commercialization, the web, and the turn into a mass consumer product. Its readable style sometimes smooths real technical disputes into tidy hero arcs and understates how contested protocol decisions were. It also has little to say about labor or exclusion; the near-total absence of women and racial diversity among its protagonists goes largely unremarked as a structural fact of who got to build this infrastructure.
Who it's for
Technology workers curious about the origins of the systems they build on, history readers who want a human account of a major infrastructure project, and students of innovation interested in how loosely coordinated teams outperform hierarchies will get the most from the full book.