Orhun Parmaksız doesn’t sleep much. The Turkish-born software developer, best known for maintaining widely used Rust projects like git-cliff and ratatui, recently published a sprawling, deeply personal essay titled “Code Responsibly” on his blog that reads less like a tech manifesto and more like a distress signal from the engine room of modern software infrastructure. His central argument is deceptively simple: the open source model, as currently practiced, is burning through human beings at an unsustainable rate.
And almost nobody is paying attention.
Parmaksız’s essay arrives at a moment of growing unease across the software industry about the fragility of the open source supply chain — not from a security standpoint, though that concern persists, but from a human one. The people who maintain the libraries, frameworks, and tools underpinning billions of dollars in commercial software are overwhelmingly unpaid, understaffed, and psychologically strained. The essay, published in June 2025, catalogs the author’s own descent into what he describes as burnout so severe it affected his physical health, his relationships, and his ability to write code at all.
The numbers alone are staggering. Parmaksız writes that he maintains or contributes significantly to dozens of projects, responds to hundreds of issues and pull requests, and fields a constant stream of demands from users who treat free software as a paid service with an SLA. He describes waking up to GitHub notifications that read like customer complaints — urgent, entitled, and devoid of any acknowledgment that the person on the other end is a volunteer.
This is not a new story. But the texture of Parmaksız’s telling is unusually granular and unsparing.
He documents specific patterns of behavior that erode maintainer well-being: users opening duplicate issues without searching first, demanding features that serve narrow use cases, responding with hostility when told a request won’t be implemented, and — perhaps most insidiously — treating silence as abandonment. A maintainer who takes a week off finds their inbox full of messages asking if the project is dead. A maintainer who takes a month off finds forks and public complaints. The implicit contract, never signed but ruthlessly enforced by community expectation, is total availability.
“I felt like I was drowning,” Parmaksız writes. Not metaphorically. He describes anxiety attacks triggered by the sheer volume of unprocessed notifications, a backlog that grew faster than any single person could manage. He tried strategies — batching responses, setting office hours, writing contribution guides — and found that none of them addressed the fundamental asymmetry: thousands of users, one maintainer.
The structural problem is well understood in economics. Open source software is a public good. It is non-excludable (anyone can use it) and, in practical terms, non-rivalrous (one person’s use doesn’t diminish another’s). Classic free-rider dynamics apply. Companies worth hundreds of billions of dollars build their products on top of libraries maintained by individuals earning nothing, or next to nothing, for the work. The value capture happens entirely downstream.
Parmaksız doesn’t frame it in those terms. He’s a developer, not an economist. But his essay implicitly makes the case that the current arrangement is a market failure of the first order. He points to the emotional toll, the opportunity cost, the way maintainers internalize a sense of obligation that no one explicitly imposed but everyone implicitly reinforces. “You created this project, so you owe us support” is the unspoken logic. It’s corrosive.
The essay also addresses something less frequently discussed: the guilt. Parmaksız describes feeling guilty for not responding quickly enough, for not reviewing pull requests thoroughly enough, for not writing enough documentation, for not being available enough. This guilt, he argues, is the mechanism by which the open source community extracts labor from maintainers without compensation. It is social pressure dressed up as community norms.
So what does “coding responsibly” actually mean?
For Parmaksız, it means several things. First, setting boundaries — real ones, not aspirational ones. He describes learning to say no to feature requests, to close issues without guilt, to mark projects as unmaintained when he can no longer give them adequate attention. Second, it means asking for help, which in the open source world often means asking for money. He discusses his experience with GitHub Sponsors and other funding mechanisms, noting that while some users contribute financially, the vast majority do not. The ratio of users to sponsors is typically hundreds or thousands to one.
Third, and most provocatively, he argues that users bear responsibility too. Not just to be polite — though that would help — but to contribute meaningfully. File better bug reports. Read the documentation before opening an issue. Offer to help triage. And if you’re a company profiting from a project, fund it. Not as charity. As a business expense.
This last point has gained significant traction in recent months. The Open Source Security Foundation (OpenSSF), a Linux Foundation project backed by major tech companies, has been pushing for more systematic corporate investment in open source maintenance. Their argument is partly about security — the XZ Utils backdoor incident of 2024 demonstrated what can happen when a critical project has a single, exhausted maintainer who accepts help from a malicious actor — but increasingly it’s about sustainability in a broader sense.
The XZ Utils case looms large in any discussion of maintainer burnout. Lasse Collin, the sole maintainer of the compression library used in virtually every Linux distribution, was so overwhelmed that he welcomed a contributor named “Jia Tan” who turned out to be a sophisticated attacker, likely state-sponsored, who spent years building trust before inserting a backdoor. The incident was a wake-up call. But wake-up calls have a way of fading.
Parmaksız references this episode and others like it. His point isn’t that burned-out maintainers will necessarily introduce security vulnerabilities. It’s that the conditions producing such vulnerabilities — isolation, overwork, inadequate support — are the default state of open source maintenance, not the exception. The XZ Utils incident wasn’t an anomaly. It was the system working exactly as designed, just with consequences that finally became visible.
Recent developments suggest the industry is at least beginning to grapple with these dynamics. In May 2025, the European Union’s Cyber Resilience Act began imposing new obligations on software manufacturers regarding the security of open source components they incorporate into commercial products. The legislation has been controversial — some maintainers fear it will increase their legal exposure — but it has also forced companies to think more carefully about their dependency chains and who maintains them. If you’re liable for the security of your product, you suddenly care a great deal about whether the person maintaining a critical library is doing okay.
Tidelift, a company that pays open source maintainers to meet enterprise standards for security and maintenance, reported in its most recent maintainer survey that over 60% of maintainers describe themselves as unpaid hobbyists, and nearly half have considered abandoning their projects due to burnout. The company’s co-founder, Donald Fischer, has argued repeatedly that the industry’s reliance on volunteer labor for critical infrastructure is untenable. “We wouldn’t accept this in any other domain,” Fischer has said. “We don’t expect the people who maintain bridges to do it for free on weekends.”
The bridge analogy is imperfect but instructive. Software infrastructure is invisible until it breaks. Bridges are at least visible. You can see when they’re crumbling. A maintainer in crisis looks like a quiet GitHub profile.
Parmaksız’s essay also touches on the psychological dynamics within open source communities themselves. He describes a culture that valorizes overwork, that treats 24/7 availability as a sign of dedication rather than a symptom of dysfunction. Contribution graphs — those green-square heatmaps on GitHub profiles — become a public performance of productivity. Gaps are noticed. A maintainer who takes a sabbatical risks being perceived as unreliable.
This culture is self-reinforcing. New maintainers see established ones working constantly and internalize the expectation. They push themselves to match it. Some thrive for a while. Many don’t. The ones who leave rarely do so loudly. They just stop committing. Their projects go quiet. Forks appear. The cycle continues.
There’s a counterargument, of course. Nobody forces anyone to maintain open source software. It’s voluntary. If it’s too much, step back. This argument has a surface plausibility that collapses under examination. Many maintainers started projects as small personal tools that unexpectedly became widely adopted. They didn’t sign up to support thousands of users. The project grew around them, and by the time the burden became unmanageable, they felt responsible for a community that depended on their work. Walking away feels like abandonment — not of code, but of people.
Parmaksız captures this tension with particular clarity. He writes about the joy of building something useful, the satisfaction of seeing his tools adopted, and the gradual realization that adoption creates obligation. The more successful the project, the heavier the weight. Success, in open source, is a trap.
Not always. Some projects have found sustainable models. The Linux kernel has extensive corporate sponsorship and a large distributed maintainer base. Rust, the programming language Parmaksız works in, has a foundation and paid contributors. But these are exceptions — large, visible projects that attract institutional support precisely because they’re too important to ignore. The long tail of open source is a different story entirely. Thousands of smaller projects, each with one or two maintainers, each critical to some subset of the software supply chain, each operating on goodwill and caffeine.
GitHub, which hosts the vast majority of open source projects, has taken steps to address the funding gap. GitHub Sponsors allows users to financially support maintainers directly. The company has also introduced features like “funding.yml” files that let projects surface donation links. But adoption remains low. Most users scroll past the sponsor button without a second thought. The friction isn’t technical. It’s cultural. People don’t pay for things they’ve always gotten for free.
Parmaksız’s essay resonated widely when it was published, accumulating thousands of reactions on Hacker News and social media. The response was a mix of solidarity from fellow maintainers, guilt from users who recognized their own behavior in his descriptions, and the inevitable contrarians arguing that maintainers should just toughen up. The contrarians, predictably, were not maintainers.
What makes the essay more than just another burnout narrative is its specificity and its practical orientation. Parmaksız doesn’t just describe the problem. He offers concrete suggestions for both maintainers and users. For maintainers: automate what you can, delegate aggressively, use bots to manage routine interactions, write clear contribution guidelines, and — critically — give yourself permission to ignore things. For users: read the README, search existing issues before filing new ones, include reproduction steps in bug reports, and consider that the person responding to your issue is a human being with finite time and energy.
These suggestions are not revolutionary. They’re obvious. And that’s precisely the point. The fact that they need to be stated, repeatedly, by maintainers on the edge of collapse, is itself an indictment of the culture.
The broader technology industry faces a reckoning on this front. As software supply chain security becomes a board-level concern, as regulatory frameworks like the EU’s Cyber Resilience Act impose new obligations, and as high-profile incidents continue to expose the fragility of volunteer-maintained infrastructure, the question of how to sustain open source is moving from the margins to the center of industry discourse. But discourse is cheap. What matters is money, institutional support, and cultural change — in that order.
Parmaksız, for his part, is still coding. Still maintaining his projects. Still responding to issues. But he’s doing it differently now, he writes. With boundaries. With the understanding that his health matters more than his contribution graph. Whether the industry will meet him halfway remains an open question.
The code doesn’t write itself. Neither does it maintain itself. Someone is on the other end of every dependency in your package manager, every library in your stack. They’re probably tired. They’re probably unpaid. And they’re probably wondering how much longer they can keep going.
That should concern everyone who ships software for a living.
WebProNews is an iEntry Publication