11 The Cathedral Nobody Built
Pull back far enough from the release train and the ground it runs across comes into view. Beneath the distributions and their lanes, beneath the login servers and the helper libraries, stands the accumulated work of several decades: the kernel, the compilers, the compression and cryptography and parsing libraries, the thousands of small components every modern computer assumes the way a building assumes its foundation. Seen from a distance it has the proportions of a cathedral: vast, old, load-bearing, the product of generations of labor. The resemblance fails at exactly one point. A cathedral has an architect, a plan, a patron, a ledger somewhere recording who is responsible for the roof. This structure has none of those things. Bowker and Star, the sociologists of infrastructure the previous chapter consulted, wrote the honest caption for it: “In the past 100 years, people in all lines of work have jointly constructed an incredible, interlocking set of categories, standards, and means for interoperating infrastructural technologies. We hardly know what we have built. No one is in control of infrastructure; no one has the power centrally to change it” (Bowker and Star 1999, 319).
What such a structure is like to live under, they also described. Standards and infrastructures, “however imbricated in our lives, are ordinarily invisible,” and “they may become more visible, especially when they break down or become objects of contention” (Bowker and Star 1999, 2–3). For the better part of two decades xz was what they were describing: a piece of the floor, walked on by everything, looked at by no one, visible to the world for exactly one weekend in March 2024, when it nearly broke. Nicole Perlroth, after a decade of reporting on the consequences, put the general condition in one sentence: “In our brave new world, these unglamorous open-source protocols have become critical infrastructure and we barely bothered to notice” (Perlroth 2021).
The people who tried to map the structure reached for a wartime analogy. The 2020 Census II report, the Linux Foundation and Harvard effort to identify the most widely used free and open-source components, observed that critical components “may not always be the most remarkable or the most visible,” and recalled that when Allied planners in the Second World War went looking for the target whose loss would propagate furthest through the German war machine, they settled on ball-bearing factories: commonplace products, crucial to nearly everything built around them (Nagle, Wilkerson, et al. 2020, 11). The analogy and its martial register are the report’s; the structural claim is sound, and the report built its whole method around finding what it called the “hidden keystones” of the ecosystem, the small packages no audit lists because nothing depends on them directly and everything depends on them transitively (Nagle, Wilkerson, et al. 2020, 19).
The keystone position is not rare, and it is not obscure to attackers. A single open-source package “may be required by several thousands of open source software projects,” a 2020 review of supply-chain attacks observed, which is exactly what makes the layer an efficient target (Ohm et al. 2020, 2); and the chains run deep as well as wide, most of them three or four layers, by one 2025 measurement of Ubuntu’s package graph (Deng et al. 2025, 6210). liblzma beneath libsystemd beneath sshd is what a hidden keystone looks like from above. From below, as the ball-bearing analogy does not say, the factory had a staff of one.
How the structure came to exist resists its own legend, and the best vaccine against the legend is the founding document. On August 25, 1991, Linus Torvalds, then a twenty-one-year-old student in Helsinki, posted to the Usenet newsgroup comp.os.minix: “Hello everybody out there using minix - I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones” (Torvalds 1991). The post’s own postscript bounded the ambition further: “It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that’s all I have :-(” (Torvalds 1991). The misspelling and the emoticon are the document’s. Read straight, the announcement records contingency, not destiny: the author of the future substrate did not plan the substrate, and on the evidence of his own forecast did not believe in it.
The next day, answering a question in the same thread, he added the sentence that mattered most and sounded least like it: “It won’t be ready for distribution for a couple of months. Even then it probably won’t be able to do much more than minix, and much less in some respects. It will be free though (probably under gnu-license or similar)” (Torvalds 1991). Two hedges, “probably” and “or similar,” and inside them the licensing instinct on which everything afterward depends. The volunteer fingerprints stayed on the movement’s very definition: when “open source” later acquired a formal standard, it was not issued by a vendor or a standards body; the Open Source Definition “was originally derived from the Debian Free Software Guidelines (DFSG),” one volunteer distribution’s internal rules for what it would agree to ship (Open Source Initiative 2007). Debian wrote the definition of openness. Debian was also, years later, one of the distributions whose development channels carried the backdoor closest to stable release.
What the hobby became is best measured in its own units. “The original 0.01 kernel was a mere 10,000 lines of code; now it grows by more than that every few days,” the kernel’s twenty-fifth-anniversary report noted in 2016 (Corbet and Kroah-Hartman 2016, 17). By the Linux Foundation’s 2020 accounting, the 88 files and 10,239 lines of linux-0.01.tar.Z, which ran on a single hardware architecture, had become 69,325 files and more than 28 million lines running on over 30 (Linux Foundation 2020, 4), deployed by then in “products where security and safety-critical considerations are essential, from medical devices, to autonomous vehicles, and to spacecraft” (Linux Foundation 2020, 21). By the time the XZ Utils operation unfolded, that substrate was no longer only inside servers and consumer devices; it sat beneath cloud fleets, phones, and the compute stacks being assembled for AI. Torvalds, in the memoir, called the result “the largest collaborative project in the history of the world” (Torvalds and Diamond 2001, 225), a sentence written in 2001 about a project that has only grown since. And in the same pages he predicted the invisibility: “And where is Linux itself, and open source generally, in all this? You won’t even know. It will be inside those Sony machines. You’ll never see it, you’ll never know it, but it’s there, making it all run” (Torvalds and Diamond 2001, 223). Bowker and Star’s theory of invisible infrastructure, stated in the first person, in advance, by the man whose bedroom project was becoming the leading instance.
The shape of that growth had a name before the danger did. Jonathan Zittrain, a legal scholar writing in 2008 about open platforms in general, described a recurring pattern: it “begins with a generative platform that invites contributions from anyone who cares to make them,” the contributions “start among amateurs, who participate more for fun and whimsy than for profit,” and in the last stage “the generative features that invite contribution and that worked so well to propel the first stage of innovation begin to invite trouble and reconsideration, as the power of openness to third-party contribution destabilizes its first set of gains” (Zittrain 2008, 18). As the pattern ran, free code displaced the purchased kind: “The phenomenon of open source software, distributed at no cost over the Internet, has displaced many of those earlier software purchases,” Russ Cox observed in 2019 (Cox 2019, 37), and the furniture of the purchase relationship, the contracts, the warranties, the someone to call, did not survive the substitution. Eghbal compressed the whole trajectory into a sentence: “Many open source projects are experiencing a difficult transition from selfless creative pursuit to critical public infrastructure” (Eghbal 2016, 65). The dependency grew faster than anything that might have supported the people underneath it.
“The community” is the phrase that stands where that support should be, and it earns its quotation marks. The picture the phrase conjures, crowds of capable volunteers swarming over shared code, describes some projects, the kernel above all. It does not describe the layer where the risk lives. Eghbal, sorting widely used projects by who actually shows up, found that many of the most depended-upon ones are what she calls stadiums: “Stadiums are projects with low contributor growth and high user growth. . . . As a result, they tend to be powered by one or a few developers” (Eghbal 2020, 63). One performer, or a few, down on the field; a vast crowd in the stands, consuming the performance without ever joining it. And the stadium libraries sit “below the application layer, yet are still widely depended upon” (Eghbal 2020, 105), beneath the products users can see, which is why the stands never empty and the field never fills.
xz was the textbook case, and not by accident. The software-engineering study that later reconstructed the campaign stated the targeting logic plainly: “XZ Utils was appealing to attackers due to its status as a low-traffic repository managed by a single developer with a small community (around 10 active members on the project’s IRC channel)” (Przymus and Durieux 2025, 93). Ten people in the chat channel of a library embedded in major Linux distributions as basic plumbing. The condition an earlier chapter traced through Lasse Collin’s years of solo maintenance was not a weakness the operator stumbled over; it was the selection criterion, the property that made this library, among all libraries, worth two years of patient work. A bus factor of one was the specification.
Nor is the thinness confined to the basement of the long tail. The person at the apex of the model said so himself, in an interview circulating after the disclosure: “It is worth really pointing out how unusual the kernel is as an open source project. A lot of open source projects, even very central ones, are basically run by one or two or three people” (Mastery Learning 2024, 6:26). The kernel is the exception because it industrialized: it spread “the responsibility for code review and integration across 100 or more maintainers,” as the anniversary report put it, so that no one person’s limits would bound the project (Corbet and Kroah-Hartman 2016, 16). The solution exists, is well understood, and was applied where the labor and the money were. In the long tail, it never arrived.
The measurements agree with him. A 2024 study commissioned by Germany’s Sovereign Tech Fund, examining 3,707 active repositories, reported its headline finding without cushioning: “The majority of open-source projects are in a state of decline, following a similar trajectory: a decline in maintenance and activity over time” (Ellis and Bollampalli 2024, 19). One of the maintainers its authors interviewed said what the regression tables cannot: “It is almost scary that we as a community…are relying on a few people to maintain such core pieces of infrastructure” (Ellis and Bollampalli 2024, 21). The official record agrees in a government’s voice: reviewing the Log4j emergency, the U.S. Cyber Safety Review Board pointed to “the security risks unique to the thinly-resourced, volunteer-based open source community,” a community “not adequately resourced to ensure that code is developed pursuant to industry-recognized secure coding practices and audited by experts” (Cyber Safety Review Board 2022, v). The board was diagnosing the conditions for accident, neglect breeding bugs, which is not how the backdoor entered xz; but the under-resourcing it names is the same soil. Even Eric Raymond, the movement’s most confident early theorist, had conceded the category by 2019, in a phrase Eghbal preserves: there are “Load-Bearing Internet People,” each one “a person who maintains the software for a critical Internet service or library, and has to do it without organizational support or a budget backing him up” (Eghbal 2020, 198).
On the weekend of the disclosure, the condition described itself from inside. In the Debian thread demanding that the backdoored versions be purged, one developer asked the question that outlives the incident: “Will we want to keep in the archive an unmaintained low-level library - low-level as in, susceptible of getting pulled as a dependency in lots of places - and rely on it for components such as dpkg?” (Hess 2024, msg #40). The question was genuine, and the thread records no settled answer. In the discussion under LWN’s first report of the backdoor, a longtime Debian developer named the general case: “We have an enormous maintenance problem, and I’m not sure what slowing down and writing less code with more quality looks like in the face of that maintenance problem” (Corbet 2024, rra comment, 2024-03-30). These are not the voices of a community discovering a gap. They are the voices of people who had known about the gap for years and had no lever long enough to close it.
The deeper trouble with “the community” is not that it is small. It is that the phrase implies an entity with hands: something that could notice a gap, allocate against it, relieve an unsupported maintainer. No such entity exists. Fogel’s handbook, the practitioner’s manual earlier chapters consulted, says it from the inside: “even the assumption that free software projects can be ‘run’ is a stretch. A free software project can be started, and it can be influenced by interested parties. But its assets cannot be made the property of any single owner,” and as long as anyone anywhere cares to continue it, “it can never be unilaterally shut down. Everyone has infinite power; everyone has no power” (Fogel 2020, vi). What stands in place of management is the norm Moody recorded at the source, a movement with no formal hierarchy for handing out important tasks: “A kind of self-selection takes place instead: Anyone who cares enough about developing a particular program is welcome to try” (Moody 2001). Earlier chapters showed what that norm yields when the person who cares enough is an operative. The same norm, read structurally: nobody assigned xz to Collin, so nobody existed to notice that the assignment had become unsustainable, and nobody’s job was to relieve him.
The corporations that built on the structure discovered the absence early, as a contracting problem. Siobhán O’Mahony, the management scholar who studied how open-source projects came to incorporate, recorded a Fortune 100 executive in the late 1990s confronting the Apache Project with the question: “How do I make a deal with a Web page?” (O’Mahony 2005, 396). The question was exact. “Communities are not legal actors,” O’Mahony observed; they are “initiated and managed by a distributed group of individuals who do not share a common employer” (O’Mahony 2005, 395), and so they can hold no assets, sign no contracts, shield no volunteers. The nonprofit foundations that now dot the landscape were bolted on to supply the missing legal personhood, created “despite the fact that such formal structures are an anathema to the hacker ethos of technical autonomy and meritocratic decision making” (O’Mahony 2005, 393). A foundation, in origin, is the adapter that lets a corporation make a deal with a web page. Whether the adapter can also maintain the web page is a separate question.
The correction can overshoot, and it matters that it not. The commons is not a formless crowd. Gabriella Coleman, the anthropologist who spent years inside the free-software world, found a built order, not a swarm: hackers, she wrote, are “committed to productive freedom,” a term that “designates the institutions, legal devices, and moral codes that hackers have built in order to autonomously improve on their peers’ work, refine their technical skills, and extend craftlike engineering traditions” (Coleman 2013, 3), with projects like Debian developing “complex codes for collaboration along with other ethical precepts that help guide technical production” (Coleman 2013, 209). The earlier chapters depended on exactly that orderliness: the operation succeeded by following Debian’s procedures, not by evading them. “The community” is a myth only as a singular noun implying an authority. As a plural description of real institutions with rules, roles, histories, and values, it is accurate. The institutions are simply not resourced in proportion to what leans on them.
There is a precise name for what this structure is, and it comes with a literature. Elinor Ostrom, the political economist who would later share the Nobel Memorial Prize in Economic Sciences for the work, spent her career on commons: shared-resource arrangements governed, in her summary, by “institutions resembling neither the state nor the market,” which have sustained their resources “with reasonable degrees of success over long periods of time” (Ostrom 1990, 1). At the heart of every commons problem she placed one temptation: “Whenever one person cannot be excluded from the benefits that others provide, each person is motivated not to contribute to the joint effort, but to free-ride on the efforts of others” (Ostrom 1990, 6). Open-source code is a good no one can be excluded from, so the temptation she names is the standing condition of the entire ecosystem; her own 1990 enumeration of shared-resource systems, written for irrigation canals and fisheries, already included “mainframe computers” (Ostrom 1990, 30). Yochai Benkler, the legal scholar who carried the framework to the internet, called free software “the quintessential instance of commons-based peer production,” many individuals contributing to a common project “with a variety of motivations” and sharing the result without anyone “asserting rights to exclude” (Benkler 2006, 63). Under every industrial-era assumption about volunteer projects, he noted, “this was a model that could not succeed. But it did” (Benkler 2006, 66).
The word “commons” has to be used honestly, though, because it hides a distinction the whole argument turns on. The classic tragedy of a commons is depletion: the pasture overgrazed, the fishery emptied, the resource subtracted by use. Code does not work that way, and Raymond built his optimism on the difference: in open source, use does not deplete the resource but improves it, as users fold their fixes back in; “the grass grows taller when it’s grazed upon” (Raymond 2001, 125). On the code, he is right: xz was not worn down by the billions of systems that ran it. What use subtracts sits underneath the code, on the side of the problem Ostrom’s framework calls provision, the producing and sustaining of the shared thing rather than the consuming of it (Ostrom 1990, 49). A maintainer’s attention is depletable. The unpaid hours are depletable. Trust, as the preceding chapters showed in detail, is depletable, and was in fact the resource the operation consumed. The tragedy this commons risks is not the exhaustion of its grass. It is the exhaustion of its soil.
The oldest voice in the record had said so at the start. Stoll, in 1989, defending the era’s “wealth of public-domain software” against those who scorned it, located the actual vulnerability in two sentences: “Viruses and logic bombs poison this communal well. People stop trusting public software, and eventually the sources of public software dry up” (Stoll 1989). Not the code, the well: what depletes is the willingness to share and to depend. And Ostrom, whose career was spent documenting commons that work, was equally clear that commons fail: “The models . . . are not wrong,” she wrote of the tragedy theorists; where the enabling conditions are absent, the collapse arrives on schedule (Ostrom 1990, 183). A commons is governable, not self-correcting. Fogel drew the practical conclusion for this one: software now belongs with the “goods that everyone needs but no one needs to own,” the roads and sewers and electric grids, and “Just as we expect road workers to be paid, we should expect software developers to be paid as well” (Fogel 2020, 67). What the XZ Utils operation consumed was precisely the part of the commons nobody had priced.
Why so little of this was visible in time has a history, and the history runs through the most influential essay the movement produced. Raymond’s The Cathedral and the Bazaar, the founding self-description an earlier chapter quoted on reputation, set two images against each other: the cathedral, software raised the careful, closed, hierarchical way, and the bazaar, the style he found in Linux and could barely believe, “release early and often, delegate everything you can, be open to the point of promiscuity,” a community resembling “a great babbling bazaar of differing agendas and approaches . . . out of which a coherent and stable system could seemingly emerge only by a succession of miracles” (Raymond 2001, 21–22). The essay’s most consequential sentence was its security claim. The bazaar finds flaws through sheer multiplicity of attention, a principle Raymond put “less formally” as “Given enough eyeballs, all bugs are shallow,” and named on the spot: “Linus’s Law” (Raymond 2001, 30). With enough people reading the code, every flaw is obvious to someone.
The law was doubted almost as soon as it was venerated. Michael Cusumano, introducing the field’s own scholarly anthology in 2005, asked: “how many ‘eyeballs’ actually view an average piece of open source code? Not as many as Eric Raymond would have us believe!” (Cusumano 2005, xii). The Census II authors, fifteen years later, treated the limit as settled: the maxim had brought real security where contributor bases were large, while “vulnerabilities in other widely-used projects with smaller contributor bases, like OpenSSL, can slip by unnoticed” (Nagle, Wilkerson, et al. 2020, 9). And Eghbal identified the mechanism that turns the shortfall toxic: the belief in many eyes “has created the opposite problem: people mistakenly believing that more people are reviewing open source software than actually are, when in reality nobody is taking responsibility” (Eghbal 2016, 36). The law does not merely fall short in the long tail. Believed where it fails, it manufactures a diffusion of responsibility, a standing assumption that someone else is watching. That assumption is a door, and it is the door the operator walked through.
Heartbleed, the 2014 catastrophe in exactly such a project, forced the concession from the law’s author: of OpenSSL in those years, Raymond told Perlroth, “there weren’t any eyeballs” (Perlroth 2021). The XZ Utils operation then ran the experiment under adversarial conditions and returned the same result with a sharper edge. For more than two years the operator worked in the open, in a library at the base of every major Linux distribution, and the promised eyes never arrived: the commit history drew almost no qualified review, the decisive components shipped where reviewing eyes do not point, in the release tarballs rather than the repository, and the few eyes that did exist had been cultivated into trust by the operator himself. Even the refined form of the law that Raymond recounted to Moody, Torvalds’s own emendation that enough eyeballs would at least leave every bug “characterized” (Moody 2001), found no purchase: for two years the backdoor was neither fixed nor characterized nor suspected. What ended it was not eyeballs. It was one engineer, off to the side, chasing half a second his benchmarks could not explain. Linus’s Law is not false; where the eyeballs are real, it works as advertised. It is a law about the well-watched core, quietly assumed to govern the unwatched long tail, and the assumption was the vulnerability.
Raymond’s metaphor deserves one more turn, because the decades have inverted it. The bazaar, left running for thirty years, did not stay a bazaar. Its stalls fused into load-bearing masonry; the improvised became the foundational; and what the world now stands on has the mass, the permanence, and the indispensability of the cathedral in his title, with none of a cathedral’s apparatus: no architect, no blueprint, no guild of masons, no endowment for the roof. A cathedral nobody built, and therefore a cathedral nobody is paid to keep standing.
Institutions did eventually rise around the structure, and honesty about them requires both halves. Heartbleed produced the first wave: in 2014 the Linux Foundation founded the Core Infrastructure Initiative (CII), whose members provided funding and support for open-source projects “critical to global information infrastructure” (Nagle, Wilkerson, et al. 2020, 6), and the CII’s census work later passed into the Open Source Security Foundation, the OpenSSF of earlier chapters (Nagle, Wheeler, et al. 2020, 4). By 2023 the United States government had adopted the framing outright: open-source software, CISA declared, is “a public good,” one “supported by diverse and wide-ranging communities—which are composed of individual maintainers, non-profit software foundations, and corporate stewards” (Cybersecurity and Infrastructure Security Agency 2023, 3). The sentence’s grammar sets the individual maintainer beside the foundation and the corporate steward, three coequal pillars. The resources behind the three words are not coequal, and nothing in the official framing says so.
The most direct attempt to fund the gap is Alpha-Omega, an OpenSSF project “established in February 2022 with a $5 million grant made jointly by Google and Microsoft” to pursue, in its own words, “direct maintainer engagement and expert analysis” (Alpha-Omega 2022, 3). The money is real and the work is real. In 2023 its grants “helped staff security teams within the Python Software Foundation, the Eclipse Foundation, the Rust Foundation, and OpenJS” (Alpha-Omega 2024, 3); by March 2026 the Linux Foundation could cite “over 70 grants totalling over $20M across major ecosystems, package registries, and individual projects” (Linux Foundation 2026). The fund’s standing mission spans the whole spectrum, “from the largest global projects to the smallest but essential components maintained by individuals” (Alpha-Omega, n.d.). That last clause names the xz layer exactly. It is the promise to weigh.
Weighed, it shows a resolution limit, and the fund deserves credit for stating the limit in its own voice. “There is no shortage of critical projects,” its 2023 report explains, “and we aren’t convinced there’s a way to quantifiably measure the criticality of projects below a certain level of granularity. Is Node.js more or less critical to the open source ecosystem than Python? Is GCC more or less critical than React?” (Alpha-Omega 2024, 7). Consider what the hard cases are: Node.js, Python, GCC, React, every one a famous, foundation-backed project. The granularity at which the fund’s sight dissolves sits well above the layer where a solo-maintained compression library lives. The same report is candid about the remainder, hoping for solutions “that will scale to the huge bodies of open source that we cannot address directly” (Alpha-Omega 2024, 8). And in October 2023 it stopped work on the Omega Toolchain, the automated effort that was its one at-scale attempt on the long tail (Alpha-Omega 2024, 15); the year’s goal review stated the reasoning bluntly: “The long tail is a hard problem with both technical and human challenges. We are not a software engineering organization” (Alpha-Omega 2024, 12). Five months later, the long tail produced the XZ Utils disclosure.
Set the two records side by side. The leading fund: criticality cannot be measured “below a certain level of granularity.” The reconstructed targeting logic: a low-traffic repository, a single developer, ten people in the channel (Przymus and Durieux 2025, 93). The operator selected precisely the layer the funder says it cannot reliably measure or address directly at scale. The thinness of that layer was documented, not hypothetical; in the 2020 contributor survey, barely a quarter of the projects represented had a security policy of any kind in place (Nagle, Wheeler, et al. 2020, 60). And the institutional response to the human side of the problem was real and characteristically scaled: the kernel community’s 2023 maintainers’ gathering gave a session to an outside psychologist on reducing stress and burnout by building psychological safety (Chance 2023), a sincere gesture, pitched at the individual’s resilience rather than at the conditions producing the strain. The foundations are not a failure. They are an immune system that grew where the body could see itself, in the organs with names, budgets, and dashboards, and the operator attacked through the tissue below the resolution of its sight.
Two over-readings lie in wait, and the record blocks both. The first is the fall from a golden age, the story in which the commons was once whole and recently broke. Raymond, of all people, dismissed it to Moody decades ago: “There’s a certain school of historical interpretation that views today’s free software as a return to a pre-proprietary golden age. That golden age never existed. I was there and I know” (Moody 2001). The commons was assembled contingently, by argument, accident, and specific decisions, and its present thinness is likewise the product of decisions, which is what makes it changeable; Ostrom spent her career insisting on exactly that pivot, away from treating participants as prisoners of “remorseless tragedies” and toward changing the conditions that produce them (Ostrom 1990, 7).
The second over-reading is that openness itself is the vulnerability, that closed and funded software would have been safe. Zalewski answered it in a reply beneath the same disclosure-weekend essay an earlier chapter drew on: “Supply-chain attacks on closed source happened before (e.g., Solarwinds), and persisted for longer, so this doesn’t really portray OSS as worse” (Zalewski 2024, lcamtuf comment, 2024-03-30). The SolarWinds compromise ran inside commercial, well-resourced, digitally signed software from “as early as Spring 2020” to its December disclosure (FireEye 2020), roughly nine months that no bazaar can be blamed for. The argument is his, but the dates are the record’s, and the comparison survives every discount applied to it.
The most careful calibration came from inside the commons, from the engineer who caught the thing. Freund, asked afterward about the exposure, bounded it rather than dramatizing it: “there aren’t that many projects with that degree of exposure. . . . it was like I think 10 projects or something. And those are much more scrutinized and are going to be more scrutinized from now on than in the past,” and prior attempts to introduce backdoors, he added, had been caught earlier in the process; “So I think it’s not all everything is lost kind of situation either” (Freund and Roccia 2024). The estimate is his, rough and offered as such, and the register is the one the record supports. The commons is thin where it should be thick, misdescribed by its own mythology, governable but not self-correcting; and it is at the same time the system that produced the disclosure, the reverse-engineering, the forty-eight-hour response, and the repair. Both facts are load-bearing. Neither cancels the other.
Zittrain compressed the whole construction into one sentence: “The generative Internet was crucially funded and cultivated by people and institutions acting outside traditional markets, and then carried to ubiquity by commercial forces” (Zittrain 2008, 174). Built outside the market; carried to ubiquity by it. Between those two clauses sits an account that has never been settled: who maintains what commerce carried off, and who pays for the maintenance. Firms build as well as take, as Zittrain also noted, since “classical, profit-maximizing firms like Red Hat and IBM can find it worthwhile to contribute to generative technologies like GNU/Linux” (Zittrain 2008, 64), and the kernel is the standing demonstration, deep benches, distributed review, institutional attention. One floor down, liblzma ran on the unpaid hours of one man in Finland. The same economy that staffs the top of the substrate leaves its lowest courses to volunteers. Why the money pools in one layer and never reaches the one below, who is actually subsidizing whom, and what the word “open” is now being made to mean in the fight over it: that is the next question.