Yes to Everything, Sustainable to Nothing: The Boundary Problem Quietly Killing Open Source

There's a particular kind of exhaustion that sets in when you've said yes one too many times. Not the tired-after-a-long-day kind, but the kind where you wake up and realize the thing you built for love has become a second job you never applied for — one with no salary, no vacation days, and a customer base that keeps growing.

That's the reality for thousands of open source maintainers across the US and beyond. And the pressure driving it isn't malicious. It's cultural.

The Infinite Generosity Myth

Open source has always carried a certain ethos with it — share freely, collaborate openly, welcome everyone. Those are genuinely good values. But somewhere along the way, the community developed an unspoken extension of that philosophy: maintainers should never say no.

Feature request? Add it. New use case the project was never designed for? Figure it out. Dependency that introduces security risk? Well, someone needs it, so maybe just this once.

The result is what some in the developer community have started calling the sustainability trap — a cycle where the cultural expectation of infinite openness makes it nearly impossible for maintainers to protect the integrity, scope, or long-term health of their own projects.

It's not a niche problem. Some of the most widely used infrastructure in American tech — tools that power fintech platforms, healthcare apps, and government services — are maintained by one or two people who've quietly absorbed years of scope creep because saying no felt like a betrayal of the open source ideal.

When Every 'Yes' Has a Cost

Here's what people outside the maintainer role often miss: every accepted feature isn't just a line of code. It's a commitment. It's a test case that needs writing, a documentation update that needs publishing, a compatibility issue that will surface in six months when someone upgrades a dependency. It's a support thread when the feature breaks in an edge case nobody anticipated.

Multiply that by dozens of accepted requests over a year, and you start to understand why maintainer burnout isn't just about time. It's about the compounding weight of obligations that never had an expiration date.

The open source model, at its best, distributes that labor across contributors. But in practice, the distribution is rarely equal. Research consistently shows that the majority of maintenance work — the unglamorous, non-headline stuff — falls on a small core group. Often just one person.

And when that person sets a boundary — closes a pull request, declines a feature, pushes back on a use case — the community response can be swift and unkind. GitHub threads turn hostile. Twitter (or whatever we're calling it this week) piles on. Forks get announced dramatically. The maintainer, who volunteered their time and expertise, becomes the villain.

The Governance Gap

So what's the fix? It's tempting to say "just say no more often," but that advice ignores the structural vacuum that makes saying no so costly.

Most open source projects, especially smaller ones, have no formal governance model. There's no documented scope, no decision-making framework, no process for evaluating feature requests against the project's stated goals. Without that structure, every decision becomes personal. And personal decisions are easy to attack.

Projects that have managed to build sustainable boundaries tend to share a few common traits. They've written down what the project is for — and what it isn't. They've established clear contribution guidelines that set expectations before someone submits a pull request. And they've created some mechanism for community input that doesn't require the maintainer to personally absorb every opinion.

The Apache Software Foundation model, for example, distributes decision-making across a Project Management Committee, which means no single person is the target when a request gets declined. The Linux kernel has a tiered maintainer structure that creates clear ownership without requiring Linus Torvalds to personally evaluate every patch. These aren't perfect systems, but they illustrate something important: governance isn't bureaucracy. It's protection.

Saying No Without Slamming the Door

One of the more promising approaches gaining traction in the open source community is what some maintainers are calling "scope documentation" — essentially, a public, living document that defines the project's intended use cases, non-goals, and decision criteria.

When a feature request comes in that falls outside the documented scope, the maintainer isn't making a judgment call. They're pointing to a pre-established agreement. It depersonalizes the rejection and, more importantly, it invites contributors to engage with the scope document itself rather than just lobbying for their specific request.

Some projects have gone further, adopting a model borrowed loosely from product management: a public roadmap with explicit criteria for what gets prioritized. Want your feature on the roadmap? Here's what it needs to demonstrate. That kind of transparency doesn't eliminate disagreement, but it channels it productively.

Sponsorship tiers with influence (not control) over roadmap priorities are another emerging model — one that acknowledges the economic reality that companies extracting value from open source projects should contribute something back, while keeping ultimate decision-making authority with the maintainers.

The Culture Shift That Has to Come First

All of these governance tools are useful. But none of them work without a broader shift in how the open source community thinks about boundaries.

Right now, there's a gap between what people say they believe — that maintainers deserve respect, autonomy, and sustainable working conditions — and how they behave when a specific request gets declined. Closing that gap requires individual accountability, not just structural reform.

It means treating a closed issue as a reasonable decision rather than a personal affront. It means reading the contribution guidelines before submitting a pull request. It means recognizing that a project with a clear, defended scope is more valuable than one that does everything poorly.

At NetBux, we talk a lot about collective progress — the idea that open technology advances when communities build together rather than extract from each other. That principle applies just as much to how we treat the people maintaining the tools we depend on as it does to the tools themselves.

Generosity is a core value of open source. But generosity without limits isn't virtue — it's a path to collapse. The projects worth building are the ones that last. And lasting requires the ability to say, clearly and without apology: this is what we do, and this is what we don't.

That's not a betrayal of the open ethos. That's what keeping it alive actually looks like.