"A Political History of X" - Keith Packard (LCA 2020)
linux.conf.au
AI-assisted summary of "A Political History of X" - Keith Packard (LCA 2020) — original source. Check the original for full context.
Source published:
Key ideas
- The X Window System emerged from an urgent practical debugging need at MIT and was designed as an open standard (X11) by DEC and collaborators to dismantle Sun's proprietary desktop monopoly with SunView. (2:05)
- Mid-1980s Internet instability and TCP congestion collapses prevented distributed cross-country code syncing, forcing the centralization of X development into the pay-to-play MIT X Consortium. (21:42)
- The permissive MIT license allowed vendors to fork closed drivers and proprietary window systems, which Packard argues duplicated engineering effort and stunted the ecosystem compared to a copyleft model like the GPL. (34:18)
- Unix workstation vendors prioritized walled gardens and incompatible toolkits over a shared software commons, freezing core X for 15 years and allowing Microsoft Windows to conquer the application market. (44:09)
Detailed notes
## Background Published by linux.conf.au on YouTube on January 16, 2020, this presentation features veteran developer Keith Packard delivering a talk at LCA 2020 in Gold Coast, Australia. The session explores the 35-year political and organizational history of the X Window System, using it as a case study to examine the impacts of software licensing, corporate consortia, and community governance across the lifetime of the free software movement.
## TL;DR Keith Packard recounts the evolution of the X Window System from its mid-1980s academic roots at Stanford and MIT to its pivotal role as Unix workstation middleware. Created to unify a wildly fragmented proprietary ecosystem and neutralize platform dominance, X11 was backed by major vendors who centralized engineering within the paid-membership MIT X Consortium. However, permissive licensing enabled vendors to hoard graphics enhancements and fork incompatible toolkits like Motif and OPEN LOOK, freezing the core protocol for fifteen years and fracturing third-party application development. Packard reflects that this corporate wall-building and failure to embrace copyleft ultimately crippled the commercial Unix market, ceding the desktop computing ecosystem to Microsoft Windows.
## Atmosphere & style The presentation carries the warmth, humility, and candid humor of a legendary engineer reminiscing about the early computing trenches with an appreciative audience of peers. Speaking with self-deprecating wit about a talk prepared on just three days' notice, Packard balances technical nostalgia—like the physical realities of noisy VAX minicomputers and FedEx-based code collaboration—with frank, sober reflections on corporate compromises and missed warnings from figures like Richard Stallman. Watching it feels like pulling up a chair for an engaging fireside post-mortem, rich with institutional memory, wry admissions of industry missteps, and thoughtful philosophical lessons on software freedom.
## Bulletin - [02:05](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=125s) The X Window System emerged from an urgent practical debugging need at MIT and was designed as an open standard (X11) by DEC and collaborators to dismantle Sun's proprietary desktop monopoly with SunView. - [21:42](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1302s) Mid-1980s Internet instability and TCP congestion collapses prevented distributed cross-country code syncing, forcing the centralization of X development into the pay-to-play MIT X Consortium. - [34:18](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2058s) The permissive MIT license allowed vendors to fork closed drivers and proprietary window systems, which Packard argues duplicated engineering effort and stunted the ecosystem compared to a copyleft model like the GPL. - [44:09](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2649s) Unix workstation vendors prioritized walled gardens and incompatible toolkits over a shared software commons, freezing core X for 15 years and allowing Microsoft Windows to conquer the application market.
## Key takeaways - [00:00](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=0s) In 1984, the UNIX ecosystem was entirely proprietary and closed source, forcing developers into vendor lock-in with zero free software alternatives. - [02:05](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=125s) The introduction of dual-ported VRAM enabled viable high-resolution graphical workstations by allowing CPUs to write without conflicting with display scanout engines. - [02:05](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=125s) Bob Scheifler adapted Stanford's synchronous W Window System into the asynchronous X Window System to gain multiple terminal windows for debugging distributed Argus programs. - [05:46](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=346s) DEC's VAXstation 100 operated as a remote high-resolution terminal tethered to an office-floor minicomputer via three dedicated fiber-optic cables plugged directly into a UNIBUS card. - [08:18](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=498s) Workstation vendors heavily patched BSD Unix variants, fragmenting the platform so severely that compiling software across vendors required complex configuration scripts and endless compiler flags. - [18:18](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1098s) DEC engineers conceived X11 as an unencumbered, public sample implementation specifically to neutralize Sun Microsystems' commercial software lead with SunView. - [21:42](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1302s) Unstable transcontinental Internet links forced the X11 development team to rely on overnight FedEx shipments of magnetic backup tapes to move code between Cambridge and Silicon Valley. - [27:02](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1622s) The MIT X Consortium centralized development at Tech Square via corporate funding, but instituted a pay-to-play model that stripped voting rights from academic contributors and non-paying developers. - [28:27](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1707s) Richard Stallman regularly urged the X Consortium to adopt the GPL, an argument Packard later acknowledged as correct after observing how permissive licensing enabled proprietary vendor fragmentation. - [31:32](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1892s) Consortium-driven bureaucratic specifications like XIE and PEX failed because they were designed in vendor echo chambers without end-user or developer adoption. - [32:45](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1965s) Core X semantics were frozen for nearly fifteen years starting in 1988, preserving long-term backward compatibility at the expense of graphical evolution. - [34:18](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2058s) The permissive MIT license led to duplicative, isolated engineering, epitomized by Keith Packard and Joel McCormack simultaneously writing rival free and proprietary accelerated color frame buffer code. - [37:34](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2254s) Sun's NeWS and Adobe's Display PostScript offered superior vector rendering, but proprietary licensing and competitive hedging prevented PostScript from becoming a ubiquitous Unix standard. - [40:41](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2441s) Desktop toolkit wars between Motif and Open Look highlighted the failure of the 'mechanism, not policy' philosophy for user-facing applications, leaving Unix without a unified free toolkit. - [44:09](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2649s) Unix hardware vendors retreated into proprietary 'castle walls' instead of fostering a cross-platform commons, leaving an application vacuum that enabled Microsoft Windows to dominate the software market.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=0s) Introduction and Setting the Stage: 1984 UNIX
Keith Packard introduces the presentation as a political history of X, clarifying with a laugh that it is really a collection of tales he has told many people over the years. The talk was originally prompted by Bradley Kuhn, who encouraged Keith to submit it for CopyleftConf in Brussels. Because Keith wasn't planning on traveling to Brussels, he instead submitted it to linux.conf.au. It was accepted late in the schedule to fill a slot opened by an attendee cancellation, leaving Keith with only about three days to prepare rather than his usual two months. Keith prefaces his remarks with an explicit disclaimer: these are solely his personal opinions and memories from across thirty-five years of working on X, not the stance of his employer, and he invites veterans in the audience to raise their hands and correct him if memory has rewritten the facts.
Turning to the audience, Keith asks who was already using UNIX in or before 1984, noting that very few hands go up. He stresses that the computing ecosystem of that period was fundamentally different from today: > “For the rest of you, UNIX in 1984 was an entirely a closed source proprietary environment. There were no free software UNIXes in 1984.”
Universities had access through academic licensing granted by AT&T, which allowed students to learn and experiment on the systems, while corporations eventually acquired licenses to build commercial products. However, proprietary lock-in was absolute: compilers, operating systems, and graphics subsystems were all locked under restrictive licenses, leaving developers stranded in what Keith terms a “land of copyright hell.”
- The talk was assembled in roughly three days as a late replacement at LCA 2020 after being conceived for CopyleftConf. - Keith notes that after 35 years, human memory inevitably rewrites stories, and welcomes corrections from those who lived through it. - In 1984, free software alternatives did not exist in the UNIX space; every layer of the stack was proprietary.
---
[02:05](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=125s) Hardware Constraints and Stanford Origins: V and W
Explaining why graphics were so crude in the early 1980s, Keith points to hardware memory architecture. Before the invention of VRAM (dual-ported RAM), building a competent frame buffer was effectively impossible. Single-ported RAM forced the CPU and the display scanout engine to fight for memory access, preventing high-resolution monochrome or color displays. Once VRAM arrived—allowing the CPU to write to one port while the display controller continuously scanned out from the second—modern graphical workstations became viable.
Around that time at Stanford University, students Paul Rexache and Brian Reid were working on the V-System (V Kernel), an experimental distributed microkernel operating system developed under Professor David Cheriton. V used direct Ethernet frame message-passing rather than TCP/IP because Ethernet was fast and lightweight. Because V was designed from the ground up as a distributed system built on synchronous Remote Procedure Calls (RPC), it made no sense to tie graphics to a purely local framebuffer. They created the V Graphics Terminal System (VGTS), which evolved into the W Window System. Because the underlying operating system was inherently networked, W became a network-transparent window system.
```mermaid flowchart LR accTitle: Evolution of Early Networked Window Systems accDescr: Diagram tracing the technical progression from Stanford's V Kernel and VGTS into W, and Bob Scheifler's subsequent rewrite into the asynchronous X Window System at MIT.
subgraph Stanford["Stanford University"] V["V Kernel<br>(Distributed Microkernel, Sync RPC)"] VGTS["VGTS Terminal Program"] W["W Window System<br>(Synchronous RPC)"] V --> VGTS --> W end
subgraph MIT["MIT Laboratory for Computer Science"] Argus["Argus Distributed System<br>(Bob Scheifler / Barbara Liskov)"] X["X Window System<br>(Asynchronous RPC)"] W -->|"Ported to VAXstation 100 & rewritten"| X Argus -.->|"Need for multi-window debugging"| X end ```
The W Window System was eventually ported to the DEC VAXstation 100 (VS100) at Stanford. Even though V and W were proprietary, the Stanford researchers shared the code with friends at the MIT Laboratory for Computer Science (LCS). Bob Scheifler was an MIT master's student working under Barbara Liskov on Argus, a distributed, multithreaded programming environment written in the CLU language. Scheifler ran into a practical bottleneck: terminal debuggers like dbx could inspect only one thread or program at a time. To debug distributed Argus programs properly, he needed multiple terminal sessions on screen at once. Rather than writing a display system from scratch, Scheifler ported Stanford's W code to UNIX on the VS100. Finding that V's synchronous RPC protocol performed terribly over UNIX network connections, Scheifler spent a couple of weeks replacing the synchronous protocol with a fully asynchronous stream protocol. Moving sequentially past "W" in the alphabet, the project became "X."
- The 1984 Apple Macintosh featured a 512×342 monochrome display, reflecting the strict hardware constraints of the era. - VRAM allowed high-resolution workstations by decoupling CPU writes from display scanout via dual ports. - The V Kernel communicated directly over raw Ethernet frames rather than TCP or IP stacks. - Bob Scheifler’s original motivation for hacking on W was simply to get multiple debugging windows for his master's work on Argus. - As Keith jokingly observes regarding the name: “So you choose the first metasyntactic variable name for your window system and you think people are gonna think you are the smartest naming person ever.”
---
[05:46](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=346s) The DEC VAXstation 100 Hardware
Keith describes the physical realities of the DEC VAXstation 100 (VS100) graphics terminal, showing a slide photograph (and noting that image copyright clearances for old hardware photos are notoriously hard to find). In that era, the main compute engine was typically a departmental minicomputer like a DEC VAX-11/750. A VAX-11/750 consisted of two 19-inch equipment racks roughly four feet tall, cooled by four to six loud, eight-inch squirrel-cage blowers—a loud piece of machinery that could never sit inside someone’s actual office.
To give developers a high-resolution graphical workstation at their desk, Digital Equipment Corporation built the VS100 as an intelligent remote terminal: > “All of a sudden I have a workstation: I can run the optical fiber a long distance, I can actually have the VAX up on the seventh floor... run the optical fiber down the plenums—because MIT was extremely plenum friendly—and run the optical fibers into my floor under Bob's office on the fifth floor, so you could actually have this computer terminal, which is a full speed UNIX workstation sitting in your office.”
The VS100 terminal sat on a desk, powered by an internal Motorola 68000 processor running roughly 128 KB of dual-ported VRAM to drive a high-resolution monochrome monitor at 60 Hz. The display resolution was over 1,000 pixels wide (approximately 1024×800 or 1088×864). It connected to the distant VAX backplane via three fiber-optic cables plugged into a large UNIBUS card in the VAX chassis. Keith points out the irony that the 68000 processor inside the "dumb terminal" on the desk was often faster than the shared VAX minicomputer down the hall.
- The VAX-11/750 required dedicated machine-room space due to its massive dual-rack enclosure and high-powered squirrel-cage cooling blowers. - The VS100 used three optical fiber lines to link the office desktop terminal directly to the UNIBUS backplane floors away. - The terminal featured a high-resolution monochrome display, a keyboard, a mouse, and dedicated 68000 hardware running the display firmware.
---
[08:18](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=498s) The Fragmented Workstation Market and Vendor Divergence
By the mid-1980s, workstation companies were competing aggressively. Every major vendor took the Berkeley Software Distribution (starting from 4.1BSD, 4.2BSD, or 4.2BSD-Tahoe/4.2c) under AT&T and UC Berkeley licenses, and heavily patched the source tree to add custom features. Each company was convinced that its proprietary variant would crush all competitors and dominate the workstation market.
Because every vendor introduced incompatible system calls, header structures, and library quirks, developing cross-platform software became a nightmare. It was during this era that Larry Wall wrote the original `Configure` shell script (which later inspired GNU Autoconf). Keith highlights the famous, cynical line that Larry Wall's script printed when detecting the system: > “This was the best thing it could say: 'Congratulations, you're not running Eunice.'”
(Eunice was a UNIX compatibility emulation layer running on DEC's proprietary VAX/VMS). Outside of avoiding Eunice, developers had to rely on thousands of conditional compiler flags (`#define`) to make code build across competing BSD derivatives. Keith stresses that while code could be ported if developers were willing to constantly recompile and debug configuration flags, a true commercial binary software market remained impossible without common standards.
Keith shows two examples of the hardware from that era: 1. **The DEC VAXstation II:** A heavy, double-wide cabinet sitting on casters designed to roll under a desk, equipped with an 8-bit accelerated color display around 1986–1987. 2. **The Sun 3/60:** A popular competing machine from Sun Microsystems based on a commodity Motorola 68020 microprocessor, setting the stage for the architecture battles among mid-1980s workstation platforms.
[10:52](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=652s) Hardware Quirks: Dumb Frame Buffers vs. Early Accelerators
Keith Packard contrasts the architectural designs of mid-1980s workstation hardware, comparing the Motorola 68020-based systems with Digital Equipment Corporation's (DEC) VAXstation II/GPX. The 68020 setups relied on a simple, "dumb" frame buffer where the central CPU drew every pixel directly on the screen. In contrast, the VAXstation II featured a proprietary VAX microcontroller wired to a specialized graphics accelerator. Because the CPU was barred from touching the frame buffer directly and had to route everything through the accelerator, “that kind of sucked actually turned out to be worse than the dumb frame buffer in so many ways.”
Packard also recalls the optical mouse that came with the VAXstation. While having an optical mouse in 1986 sounded advanced, the sensor was primitive and incapable of tracking motion across standard desk surfaces:
```mermaid flowchart TD accTitle: Mid-1980s Workstation Hardware Comparison accDescr: Contrasting 68020 dumb frame buffers with VAXstation II accelerated graphics and optical input requirements.
subgraph Motorola["Motorola 68020 Workstation"] CPU1["68020 CPU"] -->|"Direct pixel access"| FB1["Dumb Frame Buffer"] MouseBall["Mechanical Ball Mouse"] -->|"Prone to desk goo & dirt"| CPU1 end
subgraph VAX["DEC VAXstation II / GPX"] CPU2["Proprietary VAX CPU"] -->|"Interacts via bus"| Accel["Graphics Accelerator"] Accel -->|"Draws to display (no direct CPU access)"| FB2["Frame Buffer"] GridPad["Custom Grid Mousepad"] -->|"Required for tracking"| OpticalMouse["Early Optical Mouse"] OpticalMouse --> CPU2 end ```
- **Custom optical mousepad:** The mouse required an engineered metallic grid mousepad to detect movement, as it could not track regular desktop surfaces. - **Reliability trade-off:** Despite the mousepad constraint, the optical design avoided the grime and physical desk goo that plagued traditional mechanical ball mice.
---
[12:00](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=720s) The 1985–1986 Unix Workstation Landscape
In the mid-1980s, workstation manufacturers offered strictly proprietary windowing environments, trapping third-party developers in walled gardens. For Packard, the gold standard at the time was Sun Microsystems’ SunView, which he encountered as an undergraduate around 1985. SunView drove a high-resolution megapixel display (1152×900) capable of running multiple terminal emulators, rich desktop widgets, and full GUI applications. However, SunView was implemented directly inside the SunOS Unix kernel: drawing a single primitive like a rectangle required an expensive system call context switch into kernel space and back, though this architecture did enforce memory isolation between competing client windows.
Other competitors offered equally isolated solutions: - **Digital Equipment Corporation (DEC):** Shipped VWS (VAX Windowing System, or UIS—User Interface Services), which was restricted solely to the VMS operating system. - **Apollo Computer:** Offered the Domain system, an idiosyncratic, network-distributed OS running a custom window system on unique planar display hardware. On an 8-bit display, Apollo separated video memory into eight distinct 1-bit planes; drawing a colored line required rendering across each plane sequentially, producing a visible cascade where colors morphed into place. - **Tektronix:** Packard's employer during this era repeatedly attempted to enter the Unix workstation arena. Tektronix made four separate entries and exits from the workstation market, crippled in part by selecting buggy National Semiconductor 32016 and 32032 processors instead of Motorola 68000 chips. While Tektronix managed to deliver notable Smalltalk graphics workstations, their management continuously misread the commercial Unix market.
---
[14:58](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=898s) Two Weeks of Hacking: The Evolution from X1 to X10
The core architecture of the X Window System traces its heritage back to a rapid prototyping effort by Bob Scheifler at MIT. “Bob Scheifler developed the early X Window System in about two weeks,” Packard remarks, placing it in the lineage of seminal tools like Perl, Python, Tcl, and JavaScript that emerged from brief bursts of ad-hoc engineering only to anchor computing infrastructure decades later.
Early iterations followed an evolutionary path: - **X1 through X6:** Kept as internal research prototypes at MIT under closed institutional arrangements, though shared informally with peer researchers at CMU, Stanford, and UC Berkeley. - **X7, X8, and X9:** Incremental refinements. X8 was a reserved version, while X9 introduced the permissive MIT License model. - **X10:** The first version approaching production utility. It introduced rudimentary color support alongside monochrome, running across IBM PC RTs, Sun-3/60s, DEC VAXstations, and surplus Tektronix units Packard had retrieved for his basement.
```mermaid flowchart LR accTitle: X Window System Early Version Trajectory accDescr: Progression from MIT internal versions X1-X6 up to the community-adopted X10.
X1_X6["X1 – X6 (MIT Internal)<br/>Closed institutional research"] --> X7_X9["X7 – X9<br/>Protocol refinements; MIT license adopted"] X7_X9 --> X10["X10 (1985–1986)<br/>Multi-vendor ports & binary driver blobs"] X10 --> X11Plan["X11 Consortium Proposal<br/>Universal open standard"] ```
The licensing model was open, yet real-world software distribution was fraught with proprietary entanglements. The MIT License was seen by Packard’s Berkeley peers as a “copy center license—take it and do whatever you want with it.” Consequently, early X10 archives were not entirely free software: - DEC’s monochrome and color display drivers were distributed as closed binary blobs. - Sun-3/60 ports acted as wrappers over the kernel-level SunView subsystem. - Only the IBM PC RT display port was open source, built by Carnegie Mellon University students while developing the Andrew Project. Because CMU had student labor and no motivation to hide the code, they simply distributed the raw C source.
---
[18:18](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1098s) The Limits of X10 and DEC's Market Reset Gambit
When Keith Packard began targeting the VAXstation II/GPX in 1986 while developing a C compiler and development environment, the operational warts of X10 became acute. X10 established an external window manager model where an independent client handled moving, resizing, and iconifying windows. However, X10 provided no mechanism for window managers to decorate client frames with title bars or control borders. To manage windows under `uwm` (Ultrix Window Manager), users relied on combinations of chorded keystrokes and pointer clicks, such as holding the left mouse button to translate or the right button to resize.
| Workstation / System | Windowing Solution | Architecture / Limitations | |:--- |:--- |:--- | | **Sun Microsystems** | SunView | Integrated in Unix kernel; required context switches; tied strictly to Sun hardware. | | **DEC VAXstation** | VWS / UIS (VMS), X10 (Ultrix) | Early Unix ports used binary-only display server drivers; GPX acceleration was awkward. | | **Apollo Domain** | Domain Window System | Proprietary networked environment; unique 8-plane frame buffer required sequential plane writes. | | **MIT X10** | `uwm` (Ultrix Window Manager) | No protocol support for window decorations; primitive line/circle math; fragmented driver code. |
Recognizing that Sun was running away with the Unix workstation market thanks to commercial software adoption—notably desktop publishing titles like FrameMaker and Interleaf running exclusively on SunView—competing vendors faced a cold reality. Competing hardware companies could not persuade commercial ISVs to port software to half a dozen proprietary window systems.
To neutralize Sun's platform advantage, Jim Gettys and Smokey Wallace at DEC’s Western Research Laboratory (WRL) conceived an audacious strategy: develop X11 as an open standard, build a vendor-neutral sample implementation written by DEC engineers and institutional collaborators, and release it completely unencumbered to the public. As Packard summarizes their reasoning: “all of a sudden the standard window system for UNIX will become X and not Sun View and all other vendors—Sun's advantage in the market of having a platform to ship software on will evaporate.”
[21:42](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1302s) The Birth of X11 and the Failure of the 1980s Internet
Remarkably, the proposal to create a standardized network window system succeeded: Digital Equipment Corporation (DEC) management bought into the plan, and Sun Microsystems was brought on board as well. A team at Digital's Western Research Laboratory (WRL) was assigned to write the initial X11 implementation. Unlike an incremental update, X11 started from a blank sheet of paper and inherited essentially no code from X10. However, it did inherit a few questionable concepts. Packard cites window borders—a constant-width region around a window to separate it from others on screen—as a prime example. While X11 introduced external window managers capable of drawing their own window decorations, the protocol retained built-in borders simply because legacy X10 applications might expect them.
The protocol design was hammered out between 1986 and 1987 in a cross-organizational collaboration involving DEC, MIT, Sun, HP, and researchers from Carnegie Mellon University (CMU). However, collaborating across the continent proved near-impossible over the mid-1980s Internet. Development was split between Cambridge, Massachusetts, and Silicon Valley in California. Even though the codebase was tiny—only a couple of megabytes—the network suffered constant timeouts and failures, making it impossible to synchronize repositories overnight. Consequently, progress relied on physical courier logistics: “No, no, no, X11 development was basically FedEx based.” Van Jacobson and Dave Clark had not yet solved the TCP congestion collapse problems plaguing the network, forcing the team to rely on tapes shipped by air rather than remote digital collaboration.
- X11 shared protocol ideas with X10 but discarded its codebase completely. - Constant-width window borders were retained in the protocol despite the advent of decorating window managers. - In 1986–1987, transcontinental code transfers of even 2–3 MB routinely collapsed due to Internet instability. - The logistical workaround relied on overnight FedEx shipments of magnetic backup tapes between East and West Coast teams.
[24:16](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1456s) Centralizing Development: The MIT X Consortium at Tech Square
Because distributed development over the network had broken down, the project shifted strategies entirely. Instead of attempting to fix the wide-area Internet, the decision was made to abandon distributed development and concentrate all paid engineering locally at MIT by creating an industry consortium. Major Unix workstation vendors pooled significant sums of cash to fund full-time staff on-site. Keith Packard was hired alongside his close friend Jim Fulton, joining Bob Scheifler on the second floor of the MIT Laboratory for Computer Science at 545 Technology Square.
Tech Square was hallowed ground for computing history. It was the birthplace of Project MAC, the MULTICS operating system (the direct ancestor of Unix), and early AI labs filled with Symbolics Lisp machines. The massive ceiling cable trays were packed with every generation of networking wire ever installed—from thicknet to thinnet—because pulling decommissioned cables out was far too labor-intensive. Packard was given an account on ITS (the Incompatible Timesharing System) on a DEC PDP-10, as well as an account on a host that held an original, un-subnetted Net 10 address. This early brush with history is the reason Packard jokes that he still configures his home network to use `10.0.0.0/8` rather than the conventional `192.168.0.0/16`.
```mermaid flowchart TD accTitle: The MIT X Consortium Centralization accDescr: Diagram showing how workstation vendors pooled money to fund in-person developers at MIT instead of distributed Internet development.
subgraph Vendors["Corporate Funding"] DEC["Digital (DEC)"] SUN["Sun Microsystems"] HP["Hewlett-Packard"] OTH["Other Workstation Vendors"] end
subgraph MIT["MIT X Consortium (545 Tech Square)"] Pool[("Pooled Consortium Cash")] Staff["Centralized In-House Engineering<br/>(Bob Scheifler, Keith Packard, Jim Fulton)"] end
DEC --> Pool SUN --> Pool HP --> Pool OTH --> Pool Pool --> Staff ```
[27:02](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1622s) "Pay to Play": Corporate Control and the Loss of Academic Collaboration
The creation of the MIT X Consortium marked an abrupt structural transition from an open, multi-university commons into a strict "pay-to-play" model. Initially backed by 10 to 15 corporate members, the roster quickly expanded to around 50 vendors, amassing an enormous budget. But this institutional wealth carried profound consequences: only paying members were granted voting rights on standards. Once workstation corporations realized that paying MIT meant MIT engineers would do the heavy lifting, vendor companies laid off their own internal shared-code developers, drying up distributed contributions.
Simultaneously, the academic and hacker communities that had incubated X were disenfranchised. Non-paying universities had no say in technical standards and were largely sidelined. Packard recalls visiting Carnegie Mellon University around 1989 to see the Andrew Project—an ambitious campus-wide distributed system built on X11: “It was fun, and we chatted with them a while, and then we went home, and that was the last we talked with these people, because again, they weren't members; they had no actual say in what I was supposed to do.” As an employee whose paycheck was directly covered by consortium revenue, Packard found his own daily priorities compromised:
> “It turns out when somebody controls my paycheck, I too can be turned to the dark side.”
- Paying member corporations obtained exclusive voting privileges on standard proposals. - Workstation vendors stopped spending internal research budgets on shared community graphics code. - Collaboration with universities, such as CMU's Andrew Toolkit team, largely evaporated because universities lacked paid memberships. - Packard reflects that despite his radical college background—attending an institution whose tongue-in-cheek motto was "Atheism, Communism, Free Love"—he prioritized answering emails from the corporate sponsors who underwrote his salary over non-member inquiries.
[28:27](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1707s) Richard Stallman, the GPL, and Vendor Misalignment
The mid-1980s also marked the emergence of copyleft. In 1985–1986, Packard had already released code under early drafts of the General Public License before version numbering or the GNU Project had fully stabilized. Up on the sixth floor of 545 Tech Square lived Richard Stallman, who had an office in the building and essentially lived there without a separate apartment. Stallman regularly came down to the second-floor X Consortium offices to challenge the team and rail against their refusal to license X under the GPL. Stallman's interpersonal intensity alienated the team at the time, leading them to disregard his advice: “We should have listened to him then, but we did not, because we knew him too well, I guess... and he really was right, we need to remember that.”
Furthermore, the workstation vendors funding the consortium had no philosophical devotion to software freedom. To them, the X Window System was the single anomaly of free software within completely proprietary product lines consisting of closed compilers, closed Unix kernels, and proprietary desktop utilities. Every vendor was locked in a brutal race to develop a hardware and OS combination so dominant that all competitors would go bankrupt. While Sun Microsystems came close to achieving total workstation hegemony, the corporate backers viewed X solely as commoditized middleware to share costs—not as a social mission to liberate users.
[31:32](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1892s) Standards Without Users: The Era of Bureaucratic Extensions
Because voting rights and participation in the MIT X Consortium were restricted to workstation vendors, the standards design process operated in an insular echo chamber. Missing from the table were independent application developers, everyday end-users, and academic researchers who understood where high-performance graphics was actually heading. Instead, a corporate delegate would pitch an elaborate concept, the consortium would spend years grinding out a political consensus, and a sprawling specification would eventually be ratified.
The result was a collection of over-engineered, heavily standardized extensions that virtually nobody in the wider software world actually adopted. Packard notes two notorious initiatives: 1. **XIE (X Imaging Extension):** A wildly complex system intended to transfer, process, and render image data over network streams. 2. **PEX (PHIGS Extension to X):** An extension designed to implement PHIGS (Programmer's Hierarchical Interactive Graphics System) in X.
Industry consortiums of that era were convinced that standard committee designs would inevitably defeat individual corporate innovations. PEX was promoted as the consortium-backed "GL killer" intended to destroy Silicon Graphics' proprietary GL language. Packard spent significant time implementing the PEX reference platform, yet both PEX and PHIGS ultimately collapsed into irrelevance when the broader developer industry decisively rejected them in favor of Silicon Graphics' technology, which evolved into OpenGL.
[32:45](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1965s) The 15-Year Freeze of the Core X Window System
Keith Packard explains that an early effort to create a low-bandwidth version of X failed to solve the real architectural bottleneck: low bandwidth was never the true issue; rather, high latency was the killer, and that initiative left latency untouched. Around the same time, X Input version 1 appeared, which Packard characterizes as an awkward bolt-on; only much later did Peter Hutterer write X Input version 2 as a complete and genuinely usable rewrite. During this late-1980s period, workstation vendors were fiercely competing to differentiate themselves and had zero interest in expanding the common baseline of functionality. Consequently, the moment X11 Release 1 shipped, the core protocol was essentially frozen in time.
```mermaid flowchart TD accTitle: Freeze of the X Window System accDescr: Diagram illustrating how workstation vendor competition led to freezing X11 semantics for 15 years while PC and Mac window systems advanced. subgraph MarketDynamics["Vendor Incentives"] V["Workstation Vendors<br>(DEC, Sun, HP, IBM)"] -->|"Compete via differentiation"| F["Refuse to expand<br>shared core standard"] end subgraph ProtocolStatus["Protocol Evolution"] F --> FR["Core X11 Frozen<br>(1988–2000)"] FR --> P["Benefit: Pristine binary compatibility<br>(1985 apps run in 2020)"] FR --> S["Drawback: Stagnant rendering model<br>(Overtaken by PC and Mac)"] end ```
Between 1988 and nearly the year 2000—a span of roughly fifteen years—the standard semantic definition of core X remained completely unaltered. While this ensured backwards compatibility, allowing programs written in 1985 or 1986 to run without issue on modern X servers, it crippled technical evolution. As Packard laments:
> “And as a result, X, which started way ahead of the PC window system, the Mac window system, and all these other proprietary window systems, it stopped. It stopped in 1988; it never got any better, and as a result, other things changed.”
- High latency, rather than raw bandwidth limitations, caused network performance bottlenecks in X. - X Input version 1 was an awkward bolt-on, later completely rewritten by Peter Hutterer as version 2. - The core protocol stayed frozen for roughly 15 years to protect backward compatibility across vendor hardware.
---
[34:18](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2058s) RISC Workstations, the DECstation 3100, and the CFB Duplication
As the Unix workstation market accelerated, the flowering of RISC processor architectures—including MIPS and SPARC—shook up traditional hardware lines. Digital Equipment Corporation (DEC) had spent years manufacturing its proprietary VAX processors in-house, watching them get marginally faster year by year. DEC responded to the RISC revolution by releasing the DECstation 3100, their first MIPS-based computer. Running a 16 MHz processor with a 60-nanosecond clock cycle, it was four to five times faster than existing VAXstations. DEC concluded that the CPU was powerful enough to dispense with dedicated graphics acceleration hardware entirely, opting instead for a simple, dumb frame buffer paired with VRAM and a scan-out engine, mirroring Sun's strategy with the Sun 3/60 and SPARCstation.
The problem lay in the software: the existing X Window System color frame buffer code for 8-bit displays was primitive and performed terribly. Instead of pooling resources with the MIT X Consortium to engineer a shared solution, Joel McCormack at DEC wrote proprietary, accelerated color frame buffer routines to give DEC hardware a commercial edge. Packard refused to accept proprietary superiority, sparking an intense six-month duel: McCormack wrote proprietary code for DEC's operating system, while Packard wrote a competing free implementation under the MIT license. The resulting codebase was the notorious `cfb` (color frame buffer) code. Keith jokes about the result:
> “How many of you have seen the color frame buffer code? Yeah, the C preprocessor is an evil tool.”
Packard's code ended up faster, though he admits taking optimizations he probably shouldn't have taken. Reflecting on the wasted effort, he observes:
> “If the X server had been released under the GPL license, we would have collaborated, right? We'd been forced to collaborate, because that's what the license does, and I'm pretty sure the result would have been better than what we came up with either individually.”
Because the MIT license allowed proprietary branching, McCormack could not share his work, Packard could not inspect it, and both engineers ended up duplicating effort in isolation.
---
[37:34](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2254s) NeWS, Display PostScript, and Fractured Rendering Models
During this same era, Sun Microsystems developed the NeWS (Network Extensible Window System), architected by James Gosling (who had earlier written Gosling Emacs, or "Gosmacs", floppy disks of which are still owned by Packard's friend Bdale Garbee) and David Rosenthal. NeWS possessed an enormous architectural advantage over X: it incorporated PostScript directly as its rendering engine. Developed by Adobe alongside professional graphics experts, PostScript provided a coherent, sophisticated page description language that could render and rasterize vector shapes far better than X ever could.
```mermaid flowchart TD accTitle: Fragmentation of PostScript in Unix Windowing accDescr: Shows how Sun NeWS and Adobe Display PostScript fractured the workstation market without establishing a universal standard. subgraph SunApproach["Sun Microsystems"] N["NeWS Engine<br>(PostScript rendering)"] X["X11 Engine"] N & X --> M["Merged X11/NeWS Server<br>(Closed source / In-server WM)"] end subgraph AdobeApproach["Adobe DPS"] DPS["Display PostScript<br>(Binary blobs sold to DEC, HP, IBM)"] NEXT["NeXTSTEP GUI"] DPS --> NEXT end M -.->|"Market fragmentation"| APP["Commercial App Developers<br>(Cannot rely on PostScript; abandon both)"] DPS -.->|"No ubiquitous platform"| APP ```
However, Sun had committed to supporting X as an industry standard while simultaneously believing NeWS was technologically superior. Sun's response was an ambitious, complicated plan: merge the X11 and NeWS servers into a single, closed-source codebase. In NeWS, the window manager ran directly inside the window server process, forcing the combined hybrid server to act as an internal X window manager as well. Sun kept this server proprietary as a competitive differentiator, relying heavily on "steaming piles of the X Window System sample implementation" without opening the derivative code back up to the community.
Concurrently, Adobe marketed Display PostScript (DPS). DPS powered the NeXTSTEP windowing system and was licensed as proprietary binary blobs to Unix workstation vendors like DEC, HP, and potentially IBM to incorporate into their X servers. However, because DPS remained an expensive, non-standard proprietary option across competing vendors, software developers could never assume its presence across the target market:
> “So, here we are, crushing the market because people want to have a proprietary advantage; we have no way of developing applications—again, if X had been developed under the GPL.”
Ultimately, no major commercial software ecosystem grew around Display PostScript on Unix, stifling the adoption of advanced 2D graphics across the Unix landscape.
---
[40:41](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2441s) The Desktop Toolkit Crisis: Athena, SunView, Motif, and Open Look
The lack of strong copyleft licensing fractured the user-facing desktop just as thoroughly as it crippled the rendering engines. While proprietary platforms offered polished interfaces, the baseline free Unix desktop was limited to twm (Tab Window Manager) coupled with the bare-bones MIT Athena Widget Set (`Xaw`). Sun shipped SunView, which offered a humane, usable, and cohesive environment. Motif and the Common Desktop Environment (CDE) soon emerged, introducing the visual innovation of using three distinct shades of gray on buttons to simulate a raised or depressed 3D appearance—a visual trick that SunView subsequently adopted.
| Desktop / Toolkit | Licensing Model | Base Tech Stack | Key Architectural / UI Characteristics | |:--- |:--- |:--- |:--- | | **Athena Widgets (`Xaw`)** | Free / Permissive (MIT) | X Toolkit Intrinsics (`Xt`) | Bare-bones visuals; lacked modern UI widgets; primitive styling. | | **SunView** | Proprietary (Sun) | Kernel / Sun-specific | Humane, cohesive interface; early adopter of 2D/3D shading. | | **Motif / CDE** | Proprietary (OSF) | X Toolkit Intrinsics (`Xt`) | Pioneered 3-shade pseudo-3D bevels for pressed button states. | | **Open Look** | Proprietary (Sun / AT&T) | Built on `Xt` (or XView) | Alternate competing standard; mutually incompatible with Motif. |
Both Motif and the various implementations of Open Look were closed-source, leaving the Unix ecosystem without any standard, high-quality, free software graphical toolkit. This drove third-party application developers to frustration: after arriving hoping to target a standard windowing system, they discovered that every hardware vendor mandated an incompatible, proprietary UI toolkit.
Even though Motif and certain Open Look implementations shared the lower-level MIT X Toolkit Intrinsics (`Xt`) library, their policy choices were entirely incompatible:
> “The free one was called the Athena widgets; you saw what that one looked like. There was an implementation of Open Look based on the same underlying toolkit, the X Toolkit, as Motif. But the way that Xt worked with Open Look and the way that it worked with Motif was essentially completely different. You couldn't mix and match bits of an Open Look app and bits of a Motif app; you had to either go all-in Motif or all-in Open Look.”
This architectural failure undermined the core philosophy of X, which famously touted "mechanism, not policy"—the principle that the window system should never dictate visual style or behavioral rules. In application toolkits, policy is mandatory. Attempting to preserve neutrality, `Xt` attempted to facilitate every conceivable policy within its framework, producing an overly complex library that failed to deliver a unified desktop experience.
[43:34](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2614s) The OPEN LOOK Toolkit Trap and Xt
Keith Packard recounts the tangled history of OPEN LOOK implementations, highlighting how vendor pressures compromised software architecture. Sun Microsystems originally ran SunView, a proprietary windowing system with its own programming interface. When transitioning toward X, Sun repurposed that existing API into an X toolkit called XView. However, customers began pushing back, demanding adherence to the official standard X toolkit architecture. In response, Sun and AT&T developed an alternate implementation on top of the X Toolkit Intrinsics (Xt), known as OLIT.
Packard laments that this concession produced an inferior developer experience. Forcing the OPEN LOOK specifications into Xt’s architecture required massive engineering effort just to yield a clunkier, less efficient framework. Combined with the competing Motif toolkit pushed by the Open Software Foundation, the Unix workstation ecosystem fragmented into incompatible camps, leaving application developers caught in the crossfire of corporate posturing rather than benefiting from a coherent, shared standard. Evaluating this compromise, Keith Packard remarks: “Sun and AT&T I believe spent an enormous amount of time creating a worse toolkit in terms of application development because they were forced to implement on top of Xt—yeah, not a great idea.”
- **SunView to XView transition:** Sun converted its proprietary SunView API into XView so legacy applications could migrate over to the X Window System. - **Customer push for standardization:** Corporate customers demanded an Xt-compliant implementation, prompting Sun and AT&T to build an Xt-based OPEN LOOK toolkit. - **Architectural compromise:** Layering the toolkit over Xt created significant development overhead and produced a demonstrably worse environment for application developers.
```mermaid flowchart TD accTitle: Evolution of Sun Graphical Toolkits accDescr: Chart showing Sun's progression from proprietary SunView to XView and the Xt-based OPEN LOOK implementation.
subgraph Proprietary ["Proprietary Era"] SV["SunView API"] end
subgraph X11 ["X11 Migration"] XV["XView Toolkit<br>(SunView API on X)"] XT["Xt-based OPEN LOOK<br>(Built with AT&T for Xt standard)"] end
SV -->|"reimplemented for X"| XV XV -->|"customer pressure for Xt"| XT ```
[44:09](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2649s) Walled Castles and the Decade of Windows
By 1992 and 1993, active development on X ground almost to a halt as the broader commercial Unix market suffered a dramatic collapse. Packard argues that this collapse was entirely self-inflicted by the workstation vendors. Rather than pooling resources into a common platform that guaranteed binary and source portability across hardware lines, every vendor attempted to lock customers into proprietary extensions and incompatible desktop environments. Packard uses the metaphor of feudal lords retreating into isolated fortresses, oblivious to the external forces mounting against them.
Summarizing the strategic blunder of the Unix vendors, Keith Packard observes: “All of them, instead of building a commons where they could collaborate and build systems that would actually allow application portability and cross-vendor development, and instead of working together they decided to build their castle walls taller, hide inside, and eventually the roving hordes outside overran the castles, and we got to the decade of Windows.” The vacuum left by Unix infighting was swiftly filled by Microsoft Windows. For software developers, Windows offered a single stable target where software could be compiled once and delivered universally to users. Reflecting on that decisive shift, Packard quips: “Windows took over because you could actually develop applications on Windows and ship them to all of your customers—it turned out to be important, who knew?” Concluding the presentation, the session chair notes there is no remaining time for formal audience questions, inviting attendees to follow up with Packard in the hallway as the room breaks into applause.
- **Stagnation of X (1992–1993):** Upstream progress slowed substantially as the underlying commercial Unix market contracted under vendor friction. - **The "Castle Wall" mentality:** Unix manufacturers prioritized vendor lock-in and differentiation over cross-platform application compatibility and shared commons. - **The rise of Microsoft Windows:** The market embraced the "decade of Windows" because independent software developers could reliably ship applications across an entire consumer and enterprise customer base without rebuilding for competing vendor silos.
## Notable quotes > [44:09](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=2649s) Windows took over because you could actually develop applications on Windows and ship them to all of your customers — Keith Packard
> [27:02](https://www.youtube.com/watch?v=cj02_UeUnGQ&t=1622s) It turns out when somebody controls my paycheck, I too can be turned to the dark side. — Keith Packard
## Mentioned Keith Packard, Bob Scheifler, Bradley Kuhn, Paul Rexache, Brian Reid, David Cheriton, Barbara Liskov, Larry Wall, Jim Gettys, Smokey Wallace, Jim Fulton, Van Jacobson, Dave Clark, Richard Stallman, Peter Hutterer, Joel McCormack, James Gosling, David Rosenthal, Bdale Garbee, MIT, Stanford University, Carnegie Mellon University, UC Berkeley, Digital Equipment Corporation, Sun Microsystems, Hewlett-Packard, Apollo Computer, Tektronix, IBM, Silicon Graphics, Adobe, AT&T, Open Software Foundation, Microsoft, X Window System, X11, X10, V-System, W Window System, VGTS, Argus, CLU, VAXstation 100, VAX-11/750, VAXstation II, Sun 3/60, DECstation 3100, SunView, SunOS, Domain, Andrew Project, NeWS, Display PostScript, NeXTSTEP, Athena Widgets, Motif, Common Desktop Environment, OPEN LOOK, XView, OLIT, X Toolkit Intrinsics, OpenGL, PEX, XIE, uwm, twm, Microsoft Windows
## Video description Keith Packard
https://lca2020.linux.org.au/schedule/presentation/186/
Stretching back over 35 years, the X Window System is one of the oldest surviving free software projects. Having its origins before the invention of the GPL, the history of X offers a slice through the whole lifetime of the software freedom movement. Using X as a lens, we can study the causes and effects of licensing, community and corporations in the world of free software.
This presentation will describe the origins of X, a discussion about the influences and interactions with the major Unix workstation vendors and early interactions with the Free Software Foundation. Also included will be a description of how internet performance bottlenecks in the mid 80s drove structural and governance changes in X that haunt the larger software ecosystem to the current day. Finally, a discussion on how software licensing choices drive community structure and affect corporate engagement will be included.
linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see https://linux.conf.au/
Produced by NDV: https://youtube.com/channel/UCQ7dFBzZGlBvtU2hCecsBBg?sub_confirmation=1
#linux.conf.au #linux #foss #opensource
Thu Jan 16 13:30:00 2020 at Room 8
[Source](https://www.youtube.com/watch?v=cj02_UeUnGQ)