5 One Person in Finland
Lasse Collin is a software developer in Finland, and for more than a decade he was the person behind xz, the compression software whose liblzma library is folded quietly into a great deal of the Linux world (Tukaani Project, n.d.-d). Compression is plumbing. It shrinks data so that files move and store more cheaply, and liblzma is the piece other programs reach for to do it without thinking about how. Collin did the work that keeps such plumbing sound, the unglamorous upkeep that has no release-day audience: fixing reported bugs, answering mail, reviewing the occasional contribution, cutting a new version when one was due. He did it without pay, in his own time, and for most of those years without much company. The code had a longer history than its current name. The archived LZMA Utils project page described an older package of gzip-like command-line tools, helper scripts, and a small decompression library, and told its users to move to XZ Utils, which supported the legacy .lzma format and could emulate the old tools (Tukaani Project, n.d.-a). The legacy branch’s own files listed Collin among the authors and directed project contact to his Tukaani address, and by XZ Utils 5.0.0, released in 2010, the AUTHORS file stated that XZ Utils was developed and maintained by Lasse Collin (Tukaani Project, n.d.-b, n.d.-c, 2010).
He is also, by his own choice, largely absent from the story told about him. After the backdoor was found, reporters came looking, and Collin mostly did not answer. “I won’t reply for now,” he wrote on the incident page he keeps at tukaani.org. “I might reconsider after my planned article is out” (Collin, n.d.). The article was to be his own account of what had happened. “I’m writing an article how the backdoor got into the releases and what can be learned from this,” he wrote there. “This is taking much longer than I had thought. I’ve made progress but I don’t want to estimate when it’s ready” (Collin, n.d.). As of the page’s last update, in January 2025, it was still unwritten.
That silence sets the terms for any portrait of him, including this one. What can fairly be said about Collin is what he has said in public and what the documented record shows, and nothing of an inferred inner life beyond it. He did not ask to become the human face of an infrastructure failure, and the urge to read a private state into his reticence is precisely the urge the record does not license. The portrait is spare because the man kept it so, and the spareness is part of the truth.
Set the person aside for a moment and look at the arrangement, because the arrangement is the point. A compression library relied on by most of the machines that carry the internet was maintained, in effect, by one volunteer. There was no team. There was no employer assigning the work, no second maintainer to share the load or to take over when the first stepped back, no security department of the kind that comes standard with commercial software. The whole project rested on a single pair of hands, and on the continued willingness of those hands to keep at it.
Software engineers have a grim shorthand for this exposure. They call it the bus factor: the number of people who would have to be hit by a bus before a project lost the knowledge it needs to survive. The academic study of the attack by Piotr Przymus and Thomas Durieux observes that for projects like xz the figure “becomes alarmingly low” (Przymus and Durieux 2025, 91). For xz, it was one. The same paper draws the contrast that the rest of this chapter circles: “Unlike proprietary software with dedicated security teams and resources, these essential OSS projects often rely on unpaid maintainers who balance project responsibilities with full-time jobs and personal commitments” (Przymus and Durieux 2025, 91). Karl Fogel, in his long-running handbook on running open-source projects, gives the missing quality a name. He calls it survivability, “the project’s ability to continue independently of any individual participant or sponsor . . . the likelihood that the project would continue even if all of its founding members were to move on to other things” (Fogel 2020, 59). A critical library carried by one unpaid volunteer with no backup scores near zero on that measure.
A single maintainer, though, is not only a single point of failure for the work. He is a single point of trust. In a project with no second maintainer there is no one to review the maintainer’s own changes, no one positioned to vet a newcomer before relying on him, no separation between the hand that writes a change and the hand that approves it. The usual name for that control is separation of duties: the person who makes a change should not be the only person empowered to approve it. Commercial software treats that separation as elementary: a change is reviewed by someone other than its author, a release is signed by more than one party, and the departure of any single engineer is meant to be survivable by design. A volunteer project of one has none of those checks, not because anyone judged them unnecessary but because there was never a second person to perform them. The same solitude that leaves the maintainer alone with the work also quietly removes every safeguard a second set of eyes would have supplied.
It is tempting to answer that open source long ago solved this, and in places it has. The Linux kernel is maintained by a deep hierarchy of largely paid developers and a web of mutual review built up over more than thirty years: subsystem maintainers who answer to other maintainers, changes that pass through several reviewers before they land, companies and a foundation that fund the work as a matter of corporate interest. But the kernel is the well-resourced exception, not a pattern that reaches down to a project like xz, and its defenses, examined later in this book, stop well short of the small, critical dependencies stacked beneath it. liblzma had none of them. It had Collin.
The imbalance is the point. On one side, a piece of software woven into the machines the modern economy runs on, the kind of dependency whose quiet failure would ripple through banks and airlines and hospital systems before anyone could name the cause. On the other, one person, unpaid, working in the time he could spare, free to slow down or stop whenever the work stopped being worth it to him. The digital economy presents itself as industrial and automated, a thing of data centers and redundancy and uptime guarantees. A surprising amount of it rests on arrangements exactly this thin, and xz was neither the thinnest of them nor the rarest.
There is a reason the solitude had deepened over the years rather than easing. Open source had quietly changed shape. Its early romance was collaborative, many hands on a shared project, contributors who were also users mending what they themselves ran. What replaced it, as open-source code became the infrastructure everyone else builds on, was lonelier. Nadia Eghbal’s central observation is that a small number of maintainers, very often just one, now carry libraries used by millions who never contribute anything back, and that the gap between the people who consume the code and the people who tend it has only widened (Eghbal 2020). The bottleneck is no longer whether code gets written; it is whether anyone has the time and the attention to keep it alive. xz was a pure specimen of the pattern: an uncountable base of dependents, and one person at the source.
None of this was hidden, and none of it was treated as a scandal. It was simply how open source worked, and to a large extent still does. Eghbal, whose Working in Public is the closest thing the field has to an economics of maintenance, locates the difficulty in motivation. “Creation is an intrinsic motivator,” she writes; “maintenance usually requires extrinsic motivation” (Eghbal 2020, 89). The energy that builds a useful thing is not the energy that sustains a decade of its upkeep, and upkeep is most of the lifespan. Software, she notes, “once written, is never really finished . . . in order to continue running, software almost always requires some sort of ongoing maintenance” (Eghbal 2020, 117). We are used to thinking of publication as the end of responsibility, “as when a writer publishes a book, or a pianist finishes a performance,” but an open-source maintainer “is expected to maintain the code they published for as long as people use it . . . in some cases, this could be literally decades” (Eghbal 2020, 96). For xz, that was not much of an exaggeration. The developer Jacob Thornton, who cocreated the Bootstrap web framework, has a phrase for the bargain: open-sourcing a project, he says, is “free as in puppy,” free to take home and then yours to feed for the rest of its life. “Puppies grow and get old,” he told one audience, and “pretty soon . . . you’re like, ‘Oh my god, so much time is required for me to take care of this thing!’” (Eghbal 2020, 122–23). The joke lands because the cost is real and arrives late, long after the applause for building the thing has died down.
Two features of the work make it especially easy to leave unfunded. The first is that maintenance is noticed only when it stops. A library that compresses data correctly draws no attention whatever; it becomes everyone’s problem in the same instant it fails, and never a moment before. The second is the language used to describe it. Eghbal’s point is that the very framing of maintenance as a labor of love is what makes the money impossible to discuss: the vocabulary of passion and gift turns a question of resourcing into a question of character, so that asking to be paid can feel like betraying the thing one loves. She calls it the elephant in the room, the sustainability problem everyone can see and no one is placed to raise (Eghbal 2016, 57). The value, meanwhile, runs one way. Companies build on the work, ship products that assume it will keep working, and return, on the whole, neither money nor hands.
The reward structure runs the other way, and the maintainers Eghbal interviewed knew it. She quotes Eric Holscher, of the Read the Docs project, on why he keeps at unpaid work: “It’s a labor of love. I could close this project tomorrow . . . but I’ve been doing it for 5 years and I don’t want to see that happen” (Eghbal 2016, 57). The phrase is warm, and it is also a bind, because love is the one thing that cannot be invoiced. The demands, meanwhile, arrive regardless. Another developer, Daniel Roy Greenfeld, told her he gets “regular demands for unpaid work . . . by healthy high profit companies large and small,” and that if he does not respond quickly enough, or declines a poor contribution, “I/we get labeled a jerk” (Eghbal 2016, 82). And the exit, when it comes, is rarely clean. Fogel describes the slide from the inside: a swamped maintainer “usually doesn’t notice it right away. It happens by slow degrees,” the project simply does not “hear much from him for a while,” then there is a guilty burst of catching up, then quiet again, but “there’s rarely an unsolicited formal resignation” (Fogel 2020, 149). Fogel’s account assumes a community standing ready to notice the gap and recruit a replacement. The hazard, for a project of one, is what happens when the replacement arrives unbidden, from outside.
Against that arrangement, Collin’s own words read less like confession than like description. In June 2022, in a message to the project’s development mailing list, he wrote: “I haven’t lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I’ve worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we’ll see. It’s also good to keep in mind that this is an unpaid hobby project” (Collin 2022).
It is the last sentences that the rest of this book turns on, and they deserve to be read for what they say rather than for what hindsight wants them to say. Collin named a condition, not a plan. He was a single unpaid volunteer who stated that his ability to care had been limited, and who mentioned, almost in passing, that a helpful newcomer might come to do more. He could not have known what that aside would come to mean. To read it as the instant burnout opened the door is to draw a causal line the record does not support and the man himself never drew. The honest reading is narrower and more unsettling: the conditions of unsupported solo maintenance were on open display, in the maintainer’s own words, on a public list, nearly two years before anyone had reason to look. The “Jia Tan” named in the message is the subject of the next chapter; what matters here is the condition the message documents, not the figure it names.
What keeps the condition from looking like Collin’s personal failing is that it is not Collin’s alone. The engineer who caught the backdoor, Andres Freund, is himself a long-tenured open-source maintainer, and asked afterward about the people on the other side of these projects, he reached for his own experience without prompting. “I know the feeling,” he said, of being “overwhelmed, you can’t keep up, and people are . . . chiding you for . . . not doing enough in their eyes, not jumping through all the hoops that they want you to,” and then, of the whole picture, “very familiar” (Freund 2024, 01:02:01). Even ordinary friction, nothing remotely like an organized campaign, “still felt like failure,” he added (Freund 2024, 01:02:48).
The pattern surfaces wherever maintainers are asked. A 2024 study of open-source maintenance commissioned by the Sovereign Tech Fund, Germany’s public financier of critical software, drew on dozens of interviews; that a national government had set up a fund to pay for open-source upkeep at all was itself a sign the problem had outgrown the volunteers. One contributor, a research scientist the report calls Johann, described how a job and a family crowd out unpaid work: “very often this hobby, open-source projects, are the first thing to [go]” (Ellis and Bollampalli 2024, 20). Another, a longtime contributor to the Rust language the report calls Alex, described the slower erosion and the users who supply it: “the constant weight of that can become very burdensome, especially as it streams in over the span of a decade… Some folks are super rude. They’re like, ‘why have you not done this? This is ridiculous. How can anyone not do this?’ So seeing that over time can be very crushing…” (Ellis and Bollampalli 2024, 23). The thread running through these accounts is not drama but accumulation: a weight that streams in over a decade and is never quite set down. And none of it is anyone’s job. The work is done after the paid work is finished, in the hours that would otherwise be rest, which is why a busy stretch at the office or a hard season at home registers at once as a project falling behind.
The surveys put numbers under the anecdotes. In Tidelift’s 2023 survey of open-source maintainers, the most common answer to how a project is staffed, by more than two to one, was “I am a solo maintainer” (Tidelift 2023, 27): 44% had no co-maintainer at all. A majority, 58%, had either quit a project or come to the edge of quitting one, with burnout among the most common reasons they named (Tidelift 2023, 29), and the share reporting that maintenance added to their personal stress had climbed to 54%, with loneliness up to 42% (Tidelift 2023, 26). The figures come from a funding vendor’s self-selected survey and are best read as directional, but the direction is consistent, and an earlier Linux Foundation and Harvard survey of contributors found the same departures for the same reasons: people left when contributing had become “unattractive,” when “their efforts were met with unreasonable demands from end users, attacks from others, as well as ‘negative personal and professional outcomes’” (Nagle et al. 2020, 52). That survey was not idle curiosity. It had grown out of an effort, after an earlier scare over unmaintained infrastructure, to take a census of the projects the world most depended on and least supported (Nagle et al. 2020). The numbers have voices behind them. “I feel like not having enough time to implement all the ideas I have is leading me to getting burned out,” one maintainer wrote in the same Tidelift survey (Tidelift 2023, 38). Collin, on this evidence, was not an aberration. His situation sat close to a pattern the data repeatedly showed: one person doing ordinary work under ordinary conditions, in a system that had quietly made those conditions the norm.
Two kinds of pressure are worth holding apart here. Everything these maintainers describe is ordinary pressure: diffuse, unorganized, the friction of too many users and too little time, the occasional rude stranger. It is the weather of unpaid maintenance, and most maintainers weather it. The pressure that would later close around Collin was not ordinary, and it did not arrive by accident. That part of the story belongs to a later chapter; what matters here is that it worked at all, and it worked because the ordinary kind had already worn the ground down.
The culture had begun, dimly, to notice. In November 2023, four months before the disclosure, the Kernel Summit, an annual gathering of Linux’s core developers held within the Linux Plumbers Conference, set aside a session on maintainer stress and burnout and brought in an outside psychologist, Gloria Chance, to lead it. Putting “psychological safety” in front of kernel developers was itself a small landmark: the community was beginning to name the suffering rather than treat it as the weather. The session reached for plain words for what it meant. It defined being overwhelmed as the point at which “intensity of your feelings outmatches your ability to manage them,” and cataloged how that “looks like,” from “anxiety, stress, impatience” to “fatigue” and feeling “helpless, or hopeless” (Chance 2023): the lay vocabulary the kernel world was now using, in front of its own developers, for a state it had long filed under the cost of doing the work. The remedy on offer, though, kept pointing back at the person. “Resilience is a muscle,” one slide ran, quoting the musician Pink: “Flex it enough and it will take less effort to get over the emotional punches each time” (Chance 2023). Another held that resilience lets us “not only adapt ourselves to stress and disappointments” but “grow the insight to avoid actions that might lead us to face such situations” (Chance 2023), as though the maintainer’s task were to steer clear of the circumstances that overwhelmed him. Naming the strain was overdue, and the people in that room meant well. But a muscle is something the individual trains in himself, and the thing actually overloaded was not the individual. It was the arrangement: one unpaid person under a load that several paid ones would have struggled to carry. The reflex, confronted with structural strain, was to improve the resilience of the person rather than the resourcing of the work, and the book takes that mismatch up again in its later chapters.
When the backdoor became public on March 29, 2024, the strain stopped being a conference topic and became, briefly, the story. In the community FAQ that the Gentoo developer Sam James assembled in the first hours, readers were told that “Lasse regularly has internet breaks and was on one of these as this all kicked off,” and were asked to “be patient with him as he gets up to speed and takes time to analyse the situation carefully” (James 2024). The maintainer of the compromised project was away from the project when the alarm sounded, then returned to an emergency already underway. The reckoning that followed was real but unfocused. Evan Boehs, whose timeline became the most-read public reconstruction of the attack, wrote on the day of disclosure that “in the fallout, there is much to learn about mental health in open source” (Boehs 2024), and set beside it a post that had gone up that day from a developer who writes as Glyph: “I really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever” (Glyph 2024). Glyph’s phrasing is one observer’s reading, offered in heat on the day the news broke, and the book does not adopt its diagnosis of any person. But the structural half of the sentence, a product resting on one unsupported person, was exactly right, and it was the half the industry, for a few weeks, seemed prepared to hear.
Not everyone framed it as a welfare problem. The security researcher Michał Zalewski, writing the day after disclosure, described the same long arc in cooler terms: “After a while, the maintainer just isn’t all that into it anymore; they are eager to pass the baton to anyone with a pulse and some modicum of skill” (Zalewski 2024). As a claim about any one person it would be unfair, and Zalewski does not make it one. As a description of a pattern, the slow disengagement of the long-tenured solo maintainer, it names with some precision the condition that makes a handover to a helpful stranger feel not like a risk but like a relief.
For all the energy, the reckoning mostly produced talk. Attention spiked in the weeks after the disclosure and then receded, the way attention does. The one response that would have changed the arrangement, paying the people who hold the infrastructure up, was the hardest to sustain and is the subject of a later chapter. What the episode clarified, at least, was the structure. A critical piece of the world’s software had been resting on one unsupported person, in plain sight, for years, and the millions who depended on it had not been looking at the person at all.
Put the pieces together and the shape of the vulnerability is plain, and it is not, in the first instance, a technical one. The people sorting through the wreckage saw it at once. On the second day of the disclosure, a Debian contributor named Pierre Ynard, reading the bug thread, set it down in a sentence: “it is said that the whole situation started with the lack of resources from the upstream maintainer to maintain the project . . . which again, we can suspect at this point, was exploited with the same modus operandi to get a compromise vector coopted in, in the form of a new maintainer” (Hess 2024, msg #40). The hedges are honest. “It is said,” “we can suspect”: a practitioner reasoning in real time, on the strength of two days. The reading was early, hedged, and close to the shape the record now supports. The opening was the want of resources; the vector was the relief of help. The upstream maintainer he means is the person who runs the original project, the source from which the Linux distributions take their copies, which is to say Collin.
There is a sharper way to put what was exposed. In a project held up by one person, that person’s judgment is the security. Users trusted xz because they trusted Collin: his care, his caution, his sense of what did and did not belong in the code. There was little else in the way of mechanism. No committee reviewed his decisions, no second signature countersigned a release, no process existed apart from him. That is an efficient way to run a project on goodwill, and it leaves the project exposed, because winning the confidence of one unsupported person is far easier than defeating a system of checks that was never built. The attack surface, in the end, was not the code. It was the trust placed in one man, and the conditions that had left him alone to hold it.
This is the argument the chapter has been assembling, and it has to be stated with care, because the careless version is both seductive and wrong. The careless version is that a burned-out maintainer handed his project to an attacker. What the record supports is quieter and structural. A critical library was maintained by one unpaid volunteer with no backup, inside a culture that treated unsupported solo maintenance as normal; the work had no natural end and the support had never arrived; and into that arrangement, help was always going to look welcome. In such a project, accepting help could look less like risk than relief. None of that made the compromise inevitable, and none of it is a verdict on Lasse Collin, who did, for years and without pay, work that much of the digital world depended on and almost none of it funded. What the conditions did was make the compromise possible. The vulnerability was structural before it was technical, and it was in place long before a line of the backdoor was written. What it needed next was someone willing to be the help. He had already begun to appear.