Kenneth Reitz published an essay this week with a title that reads more like a balance sheet than a metaphor: Open Source Gave Me Everything Until I Had Nothing Left to Give. The piece documents a transaction that went deeply asymmetric over time, and Reitz is far from the only person this has happened to.
Reitz is the creator of requests, the Python HTTP library downloaded hundreds of millions of times per month on PyPI, and a dependency of pip, conda, and effectively every production Python application that touches the network. He also built pipenv, httpbin, the Hitchhiker’s Guide to Python, tablib, and a dozen other libraries under his “for Humans” design philosophy. That phrase was a real contribution to how developers think about API ergonomics: the idea that libraries should be designed around what users want to express, not around what the underlying protocol exposes.
That philosophy produced real value. Corporations built products on it. Startups shipped faster because of it. The Python ecosystem’s reputation for approachability owes something to the libraries Reitz wrote before anyone was paying him to do so.
The Transaction That Wasn’t
Open source operates on a contribution model that works well at the margins and breaks down at scale. When a library has a few thousand users, maintainership feels like community work: a back-and-forth between people with shared interests. When a library has hundreds of millions of monthly downloads, the asymmetry becomes visible. The number of people who depend on the library grows by orders of magnitude, but the number of people equipped and willing to maintain it stays roughly constant, or shrinks as the original maintainer’s capacity for supporting a massive user base without institutional backing eventually runs out.
Reitz has written about this before, including his documented struggles with bipolar disorder and depression during the period when pipenv had become the officially recommended tool at python.org and was simultaneously falling behind on bug fixes. The gap between how important a tool is to its users and how sustainable that importance is for its creator is not a character flaw. It is a design flaw in how ecosystems treat their own infrastructure.
Nadia Eghbal framed this most clearly in Roads and Bridges (2016), a report for the Ford Foundation that compared open source software to physical infrastructure. Public roads do not pay for themselves through the gratitude of drivers. They require tax revenue and maintenance budgets. Open source, by contrast, is expected to maintain itself on goodwill, evenings, and the occasional corporate donation. The comparison holds up, and the consequences of ignoring it are becoming harder to dismiss.
The Security Dimension
The xz utils backdoor in 2024 made the burnout problem concrete in a way that years of policy discussions had not. The actor known as Jia Tan, almost certainly state-sponsored, identified a single-maintainer project in critical infrastructure, found that the maintainer (Lasse Collin) had publicly disclosed mental health difficulties and maintenance struggles, and spent approximately two years cultivating trust before inserting a backdoor targeting sshd on systemd-based Linux systems. The social engineering explicitly exploited maintainer exhaustion: fake accounts pressured Collin about his slow maintenance pace, manufacturing urgency and receptivity to outside help.
CVE-2024-3094 was only caught because Andres Freund at Microsoft noticed a 500ms latency anomaly in SSH logins on a Debian testing system and investigated out of curiosity. The margin between near-miss and widespread compromise was narrow, and it narrowed because a maintainer was burned out and working in isolation.
The xz utils case is an outlier in its sophistication, but the conditions it exploited are not outliers at all. Research into burnout signals in open source projects has found consistent patterns: declining commit frequency, increasingly terse responses to issues, and eventual silence from primary contributors, often preceding either project abandonment or security degradation. Single-maintainer projects with high transitive dependency counts represent a structural risk that most dependency graphs do not make visible.
What Has Changed, and What Hasn’t
The ecosystem has developed responses to the sustainability problem. GitHub Sponsors launched in 2019. Open Collective enabled transparent fiscal hosting for hundreds of open source projects. Tidelift built a model where enterprises pay a subscription that flows back to maintainers of their dependencies. The Sovereign Tech Fund in Germany has funded critical infrastructure projects directly. The Open Source Security Foundation emerged from the Core Infrastructure Initiative that formed after Heartbleed revealed how under-resourced OpenSSL was despite securing a significant fraction of internet traffic.
These are real improvements, and their impact has been uneven. GitHub Sponsors works reasonably well for developers with audiences already invested in their work. Tidelift requires enterprise procurement cycles and organizational will that many companies lack. The Sovereign Tech Fund is geographically scoped and limited in scale relative to the problem. The gap between value created and compensation received has narrowed for some maintainers and remained wide for most.
Denis Pushkarev, the sole maintainer of core-js, a polyfill library that underpins a significant fraction of the web through transitive dependencies, posted a lengthy appeal in the project’s README in 2023 describing years of uncompensated work, financial hardship, and the impossibility of simply stopping without breaking things at scale. The response was mixed: some organizations sent money, many criticized the tone of the appeal, and the structural problem that produced the situation remained unchanged.
The Identity Problem Runs Deeper
The financial dimension is real, but Reitz’s essay points at something that compensation alone does not fully solve. When a library becomes central enough, it starts consuming the identity of the person who made it. The maintainer’s GitHub profile becomes a support queue. Their online presence becomes a surface for complaints from users who experience a bug as a personal affront. The creator of a widely-used tool carries a kind of ambient responsibility that does not clock out.
This is particularly acute when the tool is famous for a reason beyond its function. Reitz’s “for Humans” framing made requests into a statement about developer experience, not merely a utility for HTTP. That elevation created expectations that went beyond bug fixes: people wanted the library to keep embodying a philosophy, to keep evolving in the right direction, to remain what they had told their team it was. The weight of that representation compounds in ways that are hard to quantify and easy to underestimate from the outside.
The pipenv episode illustrated what happens when the weight becomes unsustainable. The library went months without releases, hundreds of issues accumulated, and the community’s frustration was real, but so was Reitz’s inability to sustain the work at that volume without losing something else. He eventually transferred significant maintainership and stepped back. The library survived; the cost to the person who built it is harder to account for.
There is a specific cruelty in the celebrity maintainer position that compounds this. Being famous for open source work brings more demands, not fewer. The library’s prominence means more issues filed, more users who feel their use case is urgent, more people who have staked professional credibility on the tool and therefore treat any gap in maintenance as a betrayal. The reward for building something important is a larger obligation with no corresponding increase in support.
Where This Leaves Us
Reitz’s essay documents something more systemic than individual failure to manage commitments; it is a record of what happens when a system extracts value without building in reciprocal flows, and does so consistently enough that the person generating that value eventually has nothing left.
The practical response is not complicated, even if sustaining it requires deliberate effort. Dependencies should have documented maintainer counts and funding states. Enterprises consuming open source at scale should have explicit policies for contributing back, financially or in engineering time. The FOSS Contributor Fund model, where companies systematically allocate budgets to their most critical open source dependencies, is one approach that several organizations have found tractable. Package managers could surface funding and maintainer-count metadata directly in installation output, making the health of a dependency legible at the moment of adoption.
The harder work is cultural. Open source culture still defaults to treating maintainership as an unlimited obligation. Users file issues with the urgency of customer support tickets. Maintainers who set scope boundaries are framed as abandoning the community. The license says the software comes with no warranty, but the social contract implied by bug reports often assumes the opposite.
Reitz gave a significant portion of his working life to the Python ecosystem. The requests library is, by most reasonable measures, foundational infrastructure, and it came from one person’s decision to solve a problem elegantly and share the result. What the ecosystem returned to him over the years is more complicated to trace, and his essay does some of that accounting openly. The infrastructure most developers treat as background is maintained by people who experience it very much in the foreground, and that gap between perception and reality is the thing worth addressing, not just the individuals who eventually break under it.