13 The Maintainer Economy
In 2020 the webcomic xkcd published a drawing that the people who run the internet recognized at once as a portrait of themselves. Numbered 2347 and titled “Dependency,” it shows a tower of neatly stacked blocks labeled “all modern digital infrastructure,” the whole structure balanced on a single load-bearing piece near the bottom, drawn so thin it looks like an accident waiting to happen. An arrow identifies that piece as “a project some random person in Nebraska has been thanklessly maintaining since 2003” (Munroe 2020). It circulated as a joke. It is more accurate as documentary. The thin block is not a metaphor for fragility in general. It is a specific, common, and largely unpaid arrangement: one person, working alone and unrecognized, holding up infrastructure the rest of the economy treats as a settled fact.
That arrangement has a name once you decide to look at it, and the name is labor. The infrastructure scholars Geoffrey Bowker and Susan Leigh Star noted that few people study the maintenance of complex systems “as a kind of work practice, with its attendant financial, skill, and moral dimensions” (Bowker and Star 1999, 5), and Star, writing on the ethnography of infrastructure, gave the people who perform that work their precise description. In any system there are workers “whose work goes unnoticed or is not formally recognized,” she observed, the cleaners and janitors and parents. And she warned that “leaving out what are locally perceived as ‘nonpeople’ can mean a nonworking system” (Star 1999, 386). The maintainer of a critical library is one of those nonpeople, invisible precisely until the system stops working without him. Nadia Eghbal, who has written the most exact account of this economy, put the same fact in the language of the digital commons. Open-source code generates “trillions of dollars in economic value,” she wrote, while many of the people who produce it “are not directly paid for their work,” so that, absent other rewards, “maintaining code for general public use quickly becomes an unpaid job you can’t quit” (Eghbal 2020, 8).
The condition is visible even at the funded center of the commons, where it has been turned into a running joke. The Linux kernel records who is responsible for each part of itself in a plain-text file called MAINTAINERS; in the catch-all entry covering everything no one else has claimed, the status line read “Buried alive in email” in the 1996 file and, by 2020, “Buried alive in reporters” (Linux Foundation 2020, 8). Even there, in the best-resourced open-source project on Earth, the work concentrates in a thin layer: roughly one-third of the contributors in a given development cycle submit exactly one patch and are not heard from again (Corbet and Kroah-Hartman 2016, 10). The kernel can absorb that because it is paid for. Much of the long tail cannot. What the discovery of the backdoor forced into view, and what the researcher Evan Boehs named directly in its aftermath, was that the field had been spending its attention in the wrong place. “We must stop focusing on fuzzing and static analysis,” Boehs wrote, “and instead turn our attention to the human costs of open source” (Boehs 2024). The point overstates the case, since the automated tools mattered to the catch, but it locates the weak layer correctly. It was never only the code.
The intuitive remedy is money, and the evidence that money alone is not the lever is unusually consistent. The 2020 FOSS Contributor Survey, a study of free and open-source software developers run jointly by the Linux Foundation and Harvard, asked thousands of contributors what motivated them and found that nonmonetary reasons dominated: adding a needed feature, the enjoyment of learning, the satisfaction of creative work. “Being paid to develop FOSS was the most likely motivation to rank in an individual’s bottom three motivations,” the survey reported, “even for those who reported receiving payment for their contributions” (Nagle, Wheeler, et al. 2020, 4). This was neither new nor fragile. A 2005 study of free and open-source developers had already concluded that “enjoyment-based intrinsic motivation . . . is the strongest and most pervasive driver” (Lakhani and Wolf 2005, 3). The later survey was not a discovery so much as a confirmation of a two-decade pattern. The mechanism behind the numbers is older still. Eric Raymond described open source as a gift culture in which “social status is determined not by what you control but by what you give away” (Raymond 2001, 81), a reputation economy whose currency is the esteem of peers, not cash. Linus Torvalds, who built the largest project in that economy, stated the principle plainly: “In a society where survival is more or less assured, money is not the greatest of motivators” (Torvalds and Diamond 2001, 227).
None of which means maintainers do not want to be paid, and the argument collapses into sentimentality the moment it forgets the difference. Torvalds, who grew wealthy when his collaborators’ companies went public, was scornful of the suggestion that he had renounced money: “I’ve always hated that self-effacing monk image because it’s so uncool. It’s a boring image. And it’s untrue” (Torvalds and Diamond 2001, 190). The maintainers themselves are blunt about it. When the Tidelift survey tested “the regularly cited theory that most maintainers prefer to work on open source as an unpaid hobby,” it found the opposite: “77% of the maintainers who are not paid would prefer to get paid” (Tidelift 2023, 4). Wanting to be paid and being motivated by pay are different things, and the maintainer economy has to hold both at once. The work is not done for money, and the people doing it would still rather not do it for free.
If money is not the lever and money is still wanted, the failure lies in the channels that carry it. They reward the wrong thing. The dominant models all flow toward what can be seen: recurring donations through GitHub Sponsors, the platform where users send maintainers small monthly sums; subscription income split among maintainers by the company Tidelift; grants from foundations; and one-time cash bounties for reported bugs. The maintainers see the bias clearly. “I feel the visibility of big projects are amplified,” one told the Tidelift survey, “but the work of small but often essential maintainers is not recognized. #frustrated” (Tidelift 2023, 38). Each model reproduces the bias in its own way. Donations raise what Mike McQuaid, lead developer of the Homebrew project, called “sticker money,” enough to print swag but “not enough money to quit one’s job and work on open source full-time” (Eghbal 2020, 193). Bounties pay for a discrete, visible artifact rather than ongoing care: in the Internet Bug Bounty program, which pays cash for flaws found in widely used code, 61% of those who earned a bounty had exactly one successful submission. “These are not hackers that are necessarily going to have a long-term investment in the ongoing health and maintenance of the project,” the analysis noted (Ellis and Bollampalli 2024, 35). The optimistic model of the era, Kevin Kelly’s “1,000 True Fans,” in which a creator needs only a few thousand devoted supporters to make a living (Eghbal 2020, 201), works for a visible creator and not for an invisible dependency. Even micro-donations, researchers found, have a “limited” effect on the projects that receive them (Osborne et al. 2024, 3).
The one model that does deliver real money tends to deliver it invisibly. A maintainer in the Tidelift survey named the arrangement “benevolent employment,” the practice of companies that “subside OSS by employing maintainers for non-related work” and let the open-source maintenance happen on the side (Tidelift 2023, 38). The open-source developer Karl Fogel, describing how free software actually gets funded, observed that much of it is underwritten by employers who donate their staff’s time and bandwidth “albeit unknowingly,” organizations that “may or may not be institutionally aware of” what they are paying for (Fogel 2020, 67). The labor is real, and the subsidy is real, but it is illegible on every balance sheet, contingent on an employer’s unrelated priorities, and impossible to count on. It is the visible model’s mirror image: support that arrives by accident rather than by design.
You can watch the bias operate in real time. When Andres Freund’s disclosure made the backdoor public, the spontaneous gesture of gratitude in the comment threads was a reader announcing, “I donated $1000 to Debian for your work. Let’s all do something nice for Debian, please?” (Corbet 2024, Cyberax comment, 2024-03-29). The money moved toward the visible hero and the visible institution, ad hoc and gratitude-driven, in precisely the pattern the funding models systematize. It did not move toward the unsupported maintainer of the library that had actually been attacked.
The question of who pays for software that the world uses for free is older than open source, and it was first posed by the person least sympathetic to the answer. In 1976 a young Bill Gates, angry that hobbyists were copying his company’s software, published an open letter that framed the whole future argument in one line: “Who can afford to do professional work for nothing?” (Gates 1976). He even priced his own underpayment, complaining that royalties had made “the time spent on Altair BASIC worth less than $2 an hour” (Gates 1976). Gates meant the question as a reductio, an impossibility no rational person would accept. The commons spent the next fifty years answering it in earnest, and the answer was Lasse Collin and the thousands of maintainers beneath most of the digital economy, who did exactly the professional work for nothing that Gates said no one could afford. The instructive difference is the exit. Gates could price his underpayment and walk away from it to build a company. The maintainer of a critical dependency cannot.
Collin’s situation was not an exception to the maintainer economy. It was its clearest expression. He had carried xz and its liblzma compression library, a component used across Linux systems to unpack data, for years and without pay. Even receiving support came with friction. “Due to the Finnish money collection act, I do not accept donations from Finns or people living in Finland,” his project page read (Collin, n.d.); he set up an account to receive donations only after the disclosure brought new attention to the project. His position was not idiosyncratic, either. A 2025 study of critical open-source projects described the prevailing condition as one of maintainers “who often experience burnout and lack motivation but continue out of a sense of duty” (Przymus and Durieux 2025, 91), and the census of the most-used packages keeps surfacing the same shape. Its authors built a list of the “keystones of the FOSS ecosystem” (Nagle, Wilkerson, et al. 2020, 24) and found them carried by one or two people each, like the few thousand lines of the JavaScript utility inherits, a single committer beneath an enormous share of the software world.
The pattern has a documented prehistory. A decade before XZ Utils, the encryption library OpenSSL stood behind most of the secure web while running, Eghbal recounts, on barely enough money “to pay the salary of one developer,” so that “two-thirds of the Web relied on encryption software maintained by just one full-time employee” (Eghbal 2016, 12). After the Heartbleed flaw exposed that arrangement in 2014, Steve Marquess, who had tried to fund the project, put the condition in a single line: “The mystery is not that a few overworked volunteers missed this bug; the mystery is why it hasn’t happened more often” (Eghbal 2016, 13). Marquess also named the felt texture of the work, the strain of carrying code that is invisible until it fails: “It takes nerves of steel to work for many years on hundreds of thousands of lines of very complex code . . . knowing that you’ll be ignored and unappreciated until something goes wrong” (Eghbal 2016, 14). The condition reaches back further than that. In 1996 Eric Allman went looking for companies to fund Sendmail, the program then carrying most of the world’s email, and found that his modest proposal “couldn’t float” (Moody 2001). Every arrangement that does hold together, Eghbal concluded after talking to maintainers who had found a way to pay themselves, turns out to rest on luck: “Everybody is getting lucky. Luck lasts for a couple of months, maybe a year or two, and then it runs out” (Eghbal 2016, 106).
The maintainer economy has an optimistic answer to all of this, and the operation against XZ Utils was built to exploit it. In a widely read 2019 essay on managing software dependencies, Russ Cox offered a reassurance the ecosystem broadly shared: “if a widely used package loses its maintainer, an interested user is likely to step forward” (Cox 2019, 39). Something close to that expectation played out around XZ Utils, except that the interested user who stepped forward was the operator who used the name “Jia Tan.” The assumption that popularity guarantees a successor holds only if the volunteer who appears can be trusted, and nothing in the model checks. The pool such volunteers are drawn from is, in any case, thin and short-lived. “A generation for free-software programming is very short,” Matthias Ettrich, who founded the KDE desktop environment, told the writer Glyn Moody; “it’s between half a year and maybe two years for those more dedicated” (Moody 2001). And the work a project like XZ Utils actually needs is the opposite of what a large, churning crowd supplies: not a stream of small drive-by contributions but the sustained, high-skill stewardship of a single coarse-grained component, the kind of investment that, by its nature, only a few people can ever make (Benkler 2006, 101). A thin pool of trusted hands, no succession plan, and a published expectation that a stranger would arrive to help. The security researcher Kevin Beaumont, surveying the incident, observed that this kind of maintainer-account takeover “actually happens all the time” and that open-source developers are “largely unpaid, and face significant amounts of online abuse from users of the software” (Beaumont 2024). The handover was not a freak event. It followed the system’s ordinary assumptions.
What maintainers say they need, when asked, is not first of all money. Among those who had quit or considered quitting, the Tidelift survey found that requests for experienced help outranked requests for pay, with 64% choosing one or both of the help options, which “makes getting experienced help even more important to maintainers than getting paid” (Tidelift 2023, 32). The scarcest resource is a second trusted person, someone to share the load, review the patches, and carry the project when the first maintainer flags. That is the gap the operation found, and it is precisely the gap that funding aimed at the project, rather than at succession, does not fill.
Some models do work, and honesty requires saying so. The clearest successes share one structural feature: they pay a specific person to do specific unglamorous work, and they can do so because an organization exists to receive the money and manage the role. “One of the most impactful ways to change the security culture of an entire community is to make it someone’s job,” the Alpha-Omega security fund wrote of its strategy (Alpha-Omega 2024, 8), and its showcase case is real and named: Alpha-Omega money let the Python Software Foundation hire Seth Larson to drive its security work (Alpha-Omega 2024, 6). Django runs a comparable arrangement, a paid fellowship that does the patch review and release management no one does for free, described by one of its developers as “a direct answer” to chronic contributor churn (Eghbal 2020, 204). A Django security volunteer described what the paid help bought: “when I know that there are some people paid to do it, I trust them to be more patient than I am” (Ellis and Bollampalli 2024, 26). But the same report names the catch in the next breath: “for thinly resourced projects, developing a security team with paid support may not be possible” (Ellis and Bollampalli 2024, 26). The model that rescues Django rescues it because Django has a foundation able to receive the grant, recruit for the role, and manage it. The solo maintainer who is the entire project has no such organization, which is exactly why the model that works cannot reach him. There is, as Eghbal puts it, “no one-size-fits-all solution,” because open source no longer has one shape (Eghbal 2020, 185).
There is also a trap inside the remedy. Making maintenance legible enough to fund makes it legible enough to cut. Star saw the dilemma in the hospitals she studied: leave the work tacit and it vanishes into the wallpaper, but “make it explicit, and it will become a target for . . . cost accounting” (Star 1999, 386). A fix that turns the maintainer into a budget line solves the funding problem by manufacturing the accounting problem, and the freedom from that ledger was part of what made the commons productive in the first place.
The strongest evidence for the argument comes from the institution best placed to refute it. Alpha-Omega is one of the best-funded open-source security initiatives in the world, underwritten by the largest technology companies. In December 2022, fifteen months before the backdoor surfaced in exactly such a project, it conceded the precise gap: “we haven’t proven out a model for funding security work on single-maintainer projects” (Alpha-Omega 2022, 17). The admission only sharpened with time. The fund later wrote that “this remains a human-scale problem and many maintainers of the long-tail projects are already working nights and weekends,” and that “adding money isn’t a quick fix” (Alpha-Omega 2025, 18); that the binding constraint is “the scarcity of dedicated time” rather than funding (Alpha-Omega 2025, 13); and that the danger in any remedy is “merely shifting more unpaid work onto their shoulders” (Alpha-Omega 2025, 3). The same caution comes from the center of the subsidized world. Greg Kroah-Hartman, one of the Linux kernel’s lead maintainers, said of a 2026 round of security grants that “grant funding alone is not going to help” with the overload then arriving (Linux Foundation 2026). Even the skeptics who reject the labor framing land in the same place from the other side. The researcher Michał Zalewski argued that small foundational libraries fail not for want of cash but for want of anything engaging left to do on them: “even if you wave some cash around, it’s hard to build a sustainable community around watching paint dry” (Zalewski 2024). The money exists. The will exists. What does not exist is a fit between the shape of the funding and the shape of the work.
The law has now caught up to part of the diagnosis. A 2021 federal report stated the premise from the security side in two flat sentences: “Software that is not maintained is at greatest risk of being exploitable. Older software is at a greater risk of not being maintained” (National Telecommunications and Information Administration 2021, 18). The risk concentrates exactly where maintenance is thinnest, in the long tail the funding routes past. The European Union’s Cyber Resilience Act went further and invented a legal category for the bodies that fund the commons, the “open-source software steward,” defined as “a legal person, other than a manufacturer,” that sustains open-source projects and “ensures the viability of those products” (European Parliament and Council of the European Union 2024, art. 3(14)). But the same regulation leaves the individual contributor outside that category: it “does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility” (European Parliament and Council of the European Union 2024, rec. 18). The maintainer who is the whole project remains hard for the law to see. The instinct to fund maintenance is in the record, too. The U.S. Cyber Safety Review Board, reviewing the Log4j emergency of 2021, proposed that “funding the maintenance of critical open source software could drive a more sustainable model for security at scale” (Cyber Safety Review Board 2022, 26). Whether any such fund can reach criticality rather than visibility is the question the policy chapter takes up.
The deepest difficulty is that the same condition that left the commons unfunded is the one that made it work. David Heinemeier Hansson, who created the Ruby on Rails framework, put it sharply: open source has been “such an incredible force for quality and community exactly because it’s not been defined in market terms. In market terms, most open source projects should never have had a chance” (Eghbal 2016, 60). A repair that simply imports the market, that prices the maintainer’s labor and books it against a return, risks dissolving the nonmarket culture that produced the work in the first place. Freund, who caught the backdoor and spent the following months turning over the conditions that produced it, reached the modest version of the conclusion in a later interview: “we need to do something more about supporting some projects that are very crucial” (Freund 2024, 01:21:31). Something more, and something that fits. The maintainer economy did not fail for want of money. It failed because the money, when it came, could not find the person.
