The Cathedral Before the Bazaar

The printer simply refused to work. It was a new machine, a sleek addition to the computer lab, boasting faster output and crisper type. Yet for one programmer at the Artificial Intelligence Laboratory at MIT, it had become a source of daily frustration.

Whenever he sent a document to print, the machine would jam. The paper would curl and catch, tearing mid-page. The problem was not mechanical; it was a flaw in the software driver, the set of instructions that told the printer how to operate.

In the culture that had nurtured this lab, the solution would have been straightforward. He would ask for the source code—the human-readable instructions written by the original programmer—study it, find the bug, and write a fix. He would then share that fix, improving the tool for everyone.

But when he requested the code from the manufacturer, the response was a flat refusal. The software was proprietary. The source code was a trade secret, the company’s property.

The driver was distributed only in “binary” form, a string of zeroes and ones that a computer could execute but a human could not read, modify, or repair. The programmer was left with a broken tool and a locked door.

This small, personal impasse—a shared machine rendered useless by withheld knowledge—was a symptom of a far larger transformation. The collaborative world of early computing was being systematically enclosed. Code, once treated as a communal artifact to be studied, tweaked, and passed along, was becoming a saleable commodity, protected by law and hidden by design. The cathedral was under construction.

To understand the force of that lockout, one must first understand the norms of the world it was sealing shut. In the 1960s and 1970s, the culture of computing, particularly within academic and research institutions, operated on a principle of open exchange. Software was seen not as a finished product but as a tool for inquiry, a collective project.

At centers like MIT’s AI Lab, Stanford’s Artificial Intelligence Laboratory, and across the fledgling ARPANET—the precursor to the internet—programmers, or “hackers” in the term’s original, positive sense, shared code freely. They were building complex systems, like the pioneering time-sharing operating systems that allowed multiple users to access a single computer simultaneously. These systems were intricate puzzles, and progress depended on collaboration. If you found a bug in someone else’s program, you fixed it and sent them the patch. If you wrote a useful utility—a text editor, a mail program, a game—you gave it away. The source code was the essential medium of this conversation.

To share only the binary, the executable end product, was to offer a monologue, not to engage in a dialogue. It was considered bad form, even antisocial.

This ethic was embedded in the very infrastructure. The ARPANET itself, funded by the U.S. Defense Department’s Advanced Research Projects Agency, was designed to share resources and research across geographically dispersed institutions. Its protocols were open specifications, published for anyone to implement.

This network of trust and technical reciprocity created a community that spanned continents. A researcher at Stanford could email a software patch to a colleague at University College London, and within days, a system on the other side of the Atlantic would run more reliably. The speed of improvement was limited only by the speed of collaboration.

The Unix operating system, developed at AT&T’s Bell Labs beginning in the late 1960s, became a powerful engine for this culture. Despite its corporate origins at a regulated monopoly, Unix’s early distribution within the academic and research world was remarkably open. AT&T, restricted by antitrust consent decrees from being in the computer business, licensed Unix to universities for a nominal fee. Crucially, it came with the source code.

Universities like the University of California, Berkeley, didn’t just use Unix; they modified it, extended it, and distributed their own enhanced versions, known as the Berkeley Software Distribution (BSD). The result was a fertile, iterative process of improvement.

As BSD was focused on increasing functionality, it would publicly share its greatest innovations with the main Unix operating system, an example of the free public code sharing that is a central characteristic of FOSS today. Before its commercialization in the mid-1980s, Unix represented many of the ideals later held by the Free and Open Source software revolution, including decentralized collaboration and a community culture of distaste towards proprietary software.

A programmer at one institution could read the code from another, learn from its architecture, adapt its solutions, and contribute back a new feature or a critical fix. This was not a charitable gesture; it was the most efficient engine for innovation they knew. The network—of people and of machines—grew stronger with every shared line of code.

This collaborative world, however, was not the only world being built. Concurrently, and with accelerating momentum in the 1970s, a different model was taking shape: software as a proprietary, packaged good. The catalyst was the dramatic drop in the cost of computer hardware, culminating in the arrival of the personal computer. Machines like the Altair 8800 kit and, later, the Apple II and the IBM PC turned computing from an institutional activity into a personal and commercial one. A market of millions of individual users was emerging, and with it, a market for software to run on those machines. The culture of sharing, rooted in small, technically elite communities, was ill-suited to serve this vast new audience.

The entrepreneurs and venture capitalists who entered the field saw not a commons to be cultivated, but a product to be sold. They brought a different logic: investment required return, which demanded control over the asset. The stage shifted from university basements and research labs to corporate campuses and retail shelves.

This shift required new legal and technical foundations. Legally, the status of software remained ambiguous. Was it a machine part? A form of text? A mathematical algorithm? A series of court rulings and policy decisions in the 1970s and early 1980s began to crystallize the answer: software constituted a form of intellectual property, protectable under copyright law.

In 1974, Congress established the U.S. Commission on New Technological Uses of Copyrighted Works (CONTU) to resolve the uncertainty. The commission’s 1978 report concluded that computer programs exhibited the “authorship” required for copyright protection, recommending explicit statutory coverage. Congress adopted these recommendations in the 1980 amendments to the Copyright Act. This legal framing proved decisive.

It meant that writing software automatically conferred upon the author exclusive rights to reproduce, distribute, and prepare derivative works. The default position moved from sharing to control. The community norm of “take it, use it, improve it” now stood in direct tension with the law’s grant of “exclusive right.” A programmer sharing source code with a friend was, in the eyes of the law, potentially infringing a copyright unless the owner permitted it.

Business practices hardened this legal shift. Companies began distributing software only in binary form. They held back the source code, the blueprint, as a corporate asset. Licenses, printed on the shrink-wrapped boxes of software disks, became restrictive legal agreements rather than invitations to collaborate. They forbade reverse engineering, limited the number of machines on which the software could run, and prohibited sharing copies with a friend. These End-User License Agreements (EULAs) transformed the user from a participant in a community into a passive consumer of a copyrighted work. The most famous and consequential example of this new model was Microsoft.

The logic of this enclosure was not merely commercial; it was increasingly codified in the very architecture of computing systems. The designers of proprietary operating systems like MS-DOS actively discouraged user modification or peer-to-peer improvement. Unlike the modular, tool-oriented philosophy of Unix, where small, interchangeable utilities could be piped together, these commercial systems were often monolithic black boxes. Their internal APIs (Application Programming Interfaces) were either undocumented or subject to change without notice, a practice that ensured third-party developers remained dependent on the platform owner’s goodwill and official development kits. This architectural closure mirrored the legal closure; both served to centralize creative control and economic reward. Innovation now channeled through corporate product plans rather than emerging organically from a distributed network of users. The “Cathedral” was not just a business model but a technical reality—a centrally planned edifice where a single authority determined the placement of every brick.

This tightening grip was felt acutely on the frontier of the new personal computing industry.

The saga of Altair BASIC, Microsoft’s first major product, illustrates the rapidity of the transition. In 1975, the Altair 8800 microcomputer kit shipped without software. Its early adopters, many of them Homebrew Club members, shared machine-language code for simple programs via hobbyist magazines and club meetings.

When Paul Allen and Bill Gates developed a version of the BASIC programming language for the Altair, they adopted a starkly different approach. They sold it on pre-punched paper tape, and their 1976 “Open Letter to Hobbyists,” widely published in the Homebrew Computer Club newsletter, accused sharing enthusiasts of theft. Gates wrote: “As the majority of hobbyists must be aware, most of you steal your software.” The letter demanded that users pay for software they were using, asserting that unpaid copying threatened the viability of the industry. The tone was accusatory, the stance unyielding.

Where earlier programmers had seen sharing as a natural extension of the craft, Gates framed it as piracy. The letter marked a public declaration of war against the ethic of open exchange. It also marked the beginning of Microsoft’s dominance.

The metamorphosis of Unix from an open, communal toolkit into a proprietary product vividly demonstrated the mounting pressure.

In 1983, AT&T, released from the consent decrees that had constrained its entry into the computer market, announced that future versions of Unix would become a commercial product, moving from a nominal licensing fee to a full-scale, binary-only distribution model for most users. This decision sent shockwaves through the academic and research communities that had come to depend on the operating system’s openness.

Institutions like Berkeley, which had built their own robust BSD variant, suddenly faced a future where the shared foundation might no longer remain accessible.

The move was a stark signal that even corporate projects born in a spirit of technical collaboration could be abruptly enclosed when commercial incentives shifted. It underscored a growing reality: no software ecosystem was safe from the logic of proprietary control if its owner perceived sufficient market value. The loss of open Unix was not merely an inconvenience; it represented the closure of a vital shared workshop, a space where the iterative, peer-reviewed style of software development had thrived for over a decade.

This encroaching reality manifested not only in grand corporate strategies but in the daily experiences of programmers and users.

The locked printer driver at MIT was one of countless minor mutinies by inert technology. Every time a user encountered a bug they could not fix, a feature they could not add, or a system they could not adapt to a novel purpose, the principle of the cathedral was reinforced. The user’s role was reduced to that of a supplicant, dependent on the distant priesthood of the software vendor to issue an official patch or upgrade—if they deemed it a priority.

This dependency bred a pervasive sense of frustration and impotence, a stark contrast to the agency that had defined the earlier hacker culture. The very act of learning was stifled; a curious programmer could no longer open the hood of a system to see how it worked. This pedagogical loss had long-term consequences, creating a generation of technicians trained to operate closed systems rather than to understand and reshape them.

The ethic of open exchange was being supplanted not just by a business model, but by a diminished conception of the user’s relationship to their own tools.

Legally, the abstract concept of software copyright began to produce concrete, chilling effects. As companies grew more aggressive in asserting their rights, the threat of litigation became a shadow over the collaborative landscape.

A programmer who shared a clever algorithm he had written, if it bore any superficial resemblance to a routine in a commercial product, could face a cease-and-desist letter from a corporate legal department. This created a climate of uncertainty where the default response to a request for code shifted from “here it is” to “I’d better not.”

The law, designed to incentivize creation by granting temporary monopolies, was now actively disincentivizing the type of informal, cumulative innovation that had characterized the early ARPANET and academic labs. The legal framework assumed a lone author creating a discrete work, not a community refining a shared, living artifact. This mismatch between copyright doctrine and software’s collaborative nature would become a central tension for decades to come.

Nowhere was the friction between these two worlds more palpable than within the meetings of the Homebrew Computer Club. The club’s newsletter, a mimeographed chronicle of technical tips and shared discoveries, served as a circulatory system for the ethic of open exchange. Members would publish schematics, debugging solutions, and snippets of assembly code for the benefit of all.

Yet during the same period, club attendees like Steve Jobs and Steve Wozniak were navigating the transition from hobbyists to entrepreneurs. When Jobs, in a now-legendary club meeting, first demonstrated the Apple I, he was showcasing a product born from that tinkering culture, but one he intended to sell as a completed, proprietary good.

The tension was not merely theoretical; it sometimes erupted in heated debate. Members who believed fervently in the free sharing of all technical knowledge would openly challenge peers who announced plans to commercialize and close off their creations. The club became a microcosm of the larger revolution, a living argument about whether the personal computer would fulfill its promise as a tool of individual empowerment or become merely a new delivery channel for closed, consumer-grade software.

These internal debates were crystallized by specific incidents that took on symbolic weight. On one occasion, a member arrived with a stack of freshly copied floppy disks containing a utility he had written, offering them freely to anyone who wanted one. The very next presentation might be from a startup founder detailing plans to sell a similar, though improved, program in a shrink-wrapped box, protected by copyright. The physical contrast was telling: the loose, hand-labeled disks versus the sealed, professionally printed retail package.

Each represented a different vision for the future. The shared disks assumed a community of equals, collaborating and improving. The shrink-wrapped box assumed a market of consumers, passively purchasing.

For many in the room, the commercial path was not inherently villainous—it was how one built a sustainable business—but it necessitated a rupture with the club’s founding ethos. This daily, practical negotiation between community norms and commercial imperatives prepared the ground for the more formal, ideological responses that would follow.

The sense of something valuable slipping away was not a vague nostalgia; it was the direct experience of watching a peer choose a proprietary path, severing a line of collaborative development. The cathedral was not just being built by faceless corporations in Redmond or Armonk; its foundations were being laid, brick by brick, in the decisions of fellow hobbyists in a Silicon Valley auditorium.

Its pivotal deal in 1981 to provide the operating system for the IBM PC, PC-DOS (and its virtually identical twin, MS-DOS), was a masterpiece of proprietary strategy. Microsoft did not sell the operating system; it licensed it. IBM, and later other PC clone manufacturers, paid Microsoft a fee for every machine shipped. Microsoft kept the source code a closely guarded secret.

This created what economists call “lock-in.” Once millions of users and thousands of software application developers had committed to the DOS platform, they were dependent on Microsoft for upgrades, fixes, and compatibility. The company’s control over this foundational layer of software—the operating system—became the cornerstone of its empire.

Other companies followed suit, protecting their applications—word processors, spreadsheets, databases—with the same binary-only, copyright-asserting model. The entire software stack, from the operating system kernel up through applications, was becoming a sequence of proprietary, closed layers.

There was no strategic “openness stack” because openness offered no perceived commercial advantage. There was only a closed, monolithic cathedral, built and owned by a single architect at each layer.

This collision of cultures was physically embodied in places like the Homebrew Computer Club, which met in the San Francisco Bay Area beginning in 1975. Its members were the archetypal early personal computing enthusiasts: hobbyists, engineers, tinkerers, and visionaries. The club’s newsle.