omewhere right now, a maintainer is reading an issue filed by a stranger. The issue is poorly formatted. It contains a stack trace pasted without code fences, a version number that's three releases behind, and a tone that oscillates between entitlement and helplessness. The maintainer reads it anyway. Not skims—reads. They hold the stranger's confusion in mind alongside the codebase's architecture, the interaction between the deprecated API the stranger is using and the migration path that was documented but apparently not documented well enough. They begin composing a response that will meet the stranger exactly where they are. This act—this specific cognitive and moral posture—is what Simone Weil called attention, and it is destroying people.

The dominant narrative around open source maintainer burnout is economic. Maintainers are not paid enough, or not paid at all, for work that constitutes critical digital infrastructure. The solution, accordingly, is compensation: GitHub Sponsors, Tidelift subscriptions, Open Collective funds, corporate contributions. When compensation alone fails—and it does, regularly, with well-funded maintainers burning out alongside unfunded ones—the narrative shifts to governance. Better codes of conduct, clearer contribution guidelines, healthier community norms. When that also fails, the discourse reaches for the concept of "gift economy," borrowed at several removes from Marcel Mauss, to explain why the social contract keeps breaking down.

All of these interventions address real problems. None of them touch the actual structure of the crisis.

Weil's concept of attention has almost nothing in common with what productivity culture means by the word. She does not mean focus, concentration, or the effortful direction of cognitive resources toward a task. She means something closer to the opposite: "Attention consists of suspending our thought, leaving it detached, empty, and ready to be penetrated by the object." Attention in Weil's sense is a posture of receptive self-negation. You do not bring yourself to the problem; you empty yourself so the problem can become fully present. The ego does not direct attention; attention requires the ego's suspension.

Weil linked this to what she called *decreation*—not destruction, but the voluntary withdrawal of the self to make room for reality. Decreation is the creature's undoing of its own creaturely assertion so that something true can appear in the space left behind. It is, in her theological framework, the highest human capacity and the most dangerous, because it requires sustaining a condition that the self naturally resists.

Now consider what deep maintenance actually involves. Not writing new features—that's creation, and it can be ego-fueled without contradiction. Maintenance. Holding the mental model of a codebase on behalf of people you will never meet. Reviewing a pull request not for whether it matches your aesthetic preferences but for whether it correctly addresses the contributor's intent while preserving the project's invariants. Triaging an issue that requires you to suppress your own first reaction ("this is a duplicate," "read the docs") in order to genuinely receive the reporter's experience of the software. Responding to a hostile message in a way that de-escalates without capitulating, which requires understanding the hostility without being captured by it.

This is not gift-giving. It is not emotional labor, at least not in the way Hochschild originally defined it, because there is no employing institution managing the feeling rules. It is not care work in the feminist-economic sense, because the relational bond is absent—the maintainer cares for strangers at scale, which is structurally different from caring for known dependents. What it most closely resembles is Weilian attention: a sustained, self-emptying receptivity directed at the reality of others' needs, held open across time, without the ego-rewards that normally sustain prolonged cognitive effort.

The maintainer who burns out has not given too many gifts. They have found it impossible to keep decreating.

Mauss's *The Gift* is routinely invoked in open source discourse, but almost always in bowdlerized form. The actual argument of the *Essai sur le don* is darker and more useful than its popularizers suggest. Mauss demonstrated that in archaic societies, gifts are never free. They carry *hau*—the spirit of the gift that demands return. Gift exchange creates obligation, establishes hierarchy, and can become a form of domination. The potlatch is not a celebration of generosity; it is a competition for status through conspicuous giving that can impoverish the giver.

This means Mauss is partially an ally to the diagnosis I'm offering, not an opponent. His framework predicts exactly the reciprocity trap that maintainers experience: you give your code freely, and the gift's *hau* generates an obligation that returns as entitlement. Users feel owed support because they received the gift. The maintainer feels compelled to provide it because the gift-relation demands reciprocity, even when no explicit contract exists. So far, so Maussian.

But Mauss's framework also misses something crucial, because it assumes that what the maintainer is doing *is* giving. The gift economy model positions the maintainer as an agent who possesses something (code, expertise, time) and transfers it to others. This preserves the ego-structure of the giver. Even in Mauss's most coercive version of gift exchange—even when the gift enslaves the giver to obligation—the giver remains a subject who *has* and *gives*. The phenomenology of deep maintenance is different. The maintainer who is genuinely attending to an issue is not giving from a position of possession. They are emptying themselves to receive. The direction is reversed. This is why the gift framing, even Mauss's sophisticated version, generates the wrong interventions: it suggests the problem is that the gift cycle is unbalanced (not enough reciprocity, not enough compensation flowing back), when the actual problem is that maintenance at its deepest is not an exchange at all.

Lewis Hyde's *The Gift*, the other text that haunts open source ideology, makes the misdiagnosis more explicit. Hyde argues that creative work circulates in a gift economy that commerce destroys. Open source advocates adopted this eagerly: code wants to be free, the gift must keep moving, commerce corrupts the commons. But Hyde's artist-as-giver is still an artist—a creator whose ego is implicated in the act of making. The maintainer is not primarily a creator. They are a *sustainer*, and sustaining requires precisely the ego-dissolution that Hyde's framework cannot accommodate because it remains organized around the figure of the inspired maker.

The result is a double bind. The maintainer is told—by the culture, the conferences, the blog posts—that they are participating in a gift economy. They should feel the glow of generosity, the satisfaction of contributing to the commons. But what they actually experience in the deep work is closer to what Weil called *affliction*: the crushing of the self under the weight of impersonal necessity. The gap between the narrative and the experience is itself a source of burnout. You cannot sustain a practice of self-emptying while being told you are engaged in self-expression.

The platforms make this worse, and not accidentally. GitHub's contribution graph quantifies output as a visible, identity-linked metric. npm download counts attach the maintainer's name to a measure of impact. Twitter and conference circuits require the maintainer to perform as a public figure—to have opinions, a brand, a persona—as the condition of attracting contributors, funding, and corporate support. GitHub Sponsors literally requires a profile page where the maintainer narrates their own value proposition.

This is not a cultural problem that better norms could fix. It is an architectural contradiction between two incompatible modes of being. The work demands decreation; the infrastructure demands ego-assertion. You must empty yourself to attend, then refill yourself to fundraise. You must suppress your preferences to review fairly, then perform your preferences to maintain a public identity. Every day, maintainers oscillate between these two postures, and the oscillation itself is exhausting in a way that neither posture alone would be.

The obvious counterexample is Linus Torvalds, who has maintained Linux for over thirty years while being flamboyantly, sometimes abusively, ego-driven. Doesn't his longevity refute the thesis? It does not, but it complicates it in a way that's worth taking seriously. Torvalds does not do the kind of maintenance I've been describing. He has, over decades, constructed an architecture—both social and technical—that delegates the attentional labor to lieutenants. The kernel's subsystem maintainer hierarchy exists precisely to distribute the decreative work across many people so that no single person must sustain it indefinitely. Torvalds himself operates primarily as a decision-maker and taste-arbiter, roles that are ego-compatible. His sustainability is not evidence against the thesis; it is evidence that the Linux project accidentally solved the attention problem through structural delegation, while the single maintainer of a popular JavaScript library has no such luxury. The pathology of ego-driven maintenance, meanwhile, is visible in the kernel community's well-documented culture of hostility, which Torvalds himself eventually acknowledged required intervention. Ego-assertion sustains the maintainer but damages the community's capacity for the very receptivity that maintenance requires at every other level.

Here is a falsifiable prediction, stated as precisely as I can make it: projects that adopt structural features protecting the attentional mode—features I'll specify below—will show lower maintainer attrition than projects matched for scope, user base, and demand intensity that rely instead on improved compensation or governance. The key control is demand intensity, not project size. The simple hypothesis "small projects have less work" doesn't explain cases where high-demand projects with certain structural features retain maintainers, and I am predicting that such cases exist and can be identified.

The structural features I mean are specific. First: *attentional rotation*. Not just "take a break" policies, which merely interrupt burnout, but formal rotation of the reviewing-and-triaging role among a pool of maintainers on a cadence short enough (weekly, biweekly) that no single person must sustain the decreative posture for long enough to be crushed by it. The Linux subsystem hierarchy achieves something like this at scale; the proposal is to make it explicit and available to smaller projects.

Second: *identity separation*. Not anonymity—the xz utils backdoor demonstrated that pseudonymous trust without accountability creates catastrophic security risks. Instead, a separation between the maintainer's *reviewing identity* and their *public identity*. Concretely: code review and issue triage happen under a role-based account (maintainer-on-duty, not jane-doe), while the public-facing work of advocacy and fundraising is handled by a different role or a different person in the rotation. This doesn't require anonymity; it requires that the platform stop collapsing the attentional role and the performative role into a single profile. The xz attack exploited a situation where a lone maintainer under pressure accepted a pseudonymous contributor's escalating access. Identity separation as I'm describing it does the opposite of that: it increases the number of real, accountable people in the reviewing role while preventing any one of them from being individually targeted by social engineering or individually crushed by the attentional demand.

Third: *intentional de-metrification of the maintenance function*. Not abolishing metrics—funders need them, and pretending otherwise is fantasy—but partitioning them. Measure the project's health (response times, bug closure rates, release cadence) without attributing those metrics to individual maintainers. The funder sees that the project is well-maintained. The maintainer is freed from the quantified-self apparatus that forces ego-assertion into the heart of the attentional practice.

None of this is easy. All of it cuts against current trends, which move toward greater individual visibility, personal branding as a funding mechanism, and metrics-driven accountability. The trend is toward making every maintainer a micro-celebrity, which is precisely the architecture designed to make sustained attention impossible.

There is a deeper reason why compensation-based fixes will keep failing, and it is not that maintainers don't deserve money. They do. Pay them. But payment operates on the logic of exchange: I give you money, you give me maintenance. This logic requires that what the maintainer does is a *thing that can be given*—a service, a product, a measurable output. Attention in Weil's sense is not a thing that can be given, because it is constituted by the withdrawal of the self that would do the giving. You cannot compensate someone for decreation, because compensation is addressed to the very ego that decreation suspends.

This does not mean money is irrelevant. Money removes material desperation, which Weil herself recognized as a precondition for attention—you cannot attend to others' code when you're worried about rent. But money framed as compensation for the attentional work itself converts that work into a commodity and thereby destroys its structure. The maintainer who is paid to review pull requests now reviews pull requests as a job. The ego is present as employee. The attentional posture changes from receptive self-emptying to professional service delivery, which is sustainable in the way that all jobs are sustainable—adequate, often soul-deadening, and fundamentally different from what open source maintenance was at its best.

The crisis of maintainer burnout is, finally, a crisis of what a technological civilization does with practices that require self-negation. We have no institutions for this. Monasteries once provided it; hospitals in their original sense; certain forms of teaching before assessment metrics colonized them. Open source maintenance emerged as an accidental site of genuine attention—people holding complex systems in mind on behalf of strangers, for no reason that exchange logic can capture—and our inability to sustain it is not a bug in the funding model. It is a revelation about the poverty of every framework we have for understanding why someone would empty themselves for a codebase, and what it costs them, and what we owe to that cost that is not, and cannot be, repayment.