Gatekeeping as a Feature: The Case for Principled Refusal in Open Infrastructure

There is a particular kind of meeting that happens in open infrastructure projects with uncomfortable regularity. A contributor arrives with a feature request that is, by most reasonable measures, genuinely good. The use case is real. The implementation is technically sound. The person asking is thoughtful and engaged. And yet, accepting the feature would be a mistake.

Knowing that—and being willing to act on it—is one of the rarest skills in open-source development.

The Flattery Trap

Feature requests are, in a meaningful sense, expressions of trust. When a researcher asks a platform to support a new data format, or a developer proposes an integration with a third-party service, they are signaling that they believe the platform is worth extending. That signal feels good. For projects that have struggled for adoption, for maintainers who have poured evenings and weekends into infrastructure that sometimes feels invisible, the request is validating.

This is precisely why feature creep is so insidious. It does not arrive looking like a threat. It arrives looking like momentum.

The pattern is well-documented in software development broadly, but it carries particular weight in open infrastructure, where the mission is typically narrow by design. A platform built to give independent researchers access to shared compute resources is not, at its core, a project management tool. A protocol designed to enable federated data sharing is not a publishing platform. The moment a project begins absorbing adjacent functions—even useful ones—it begins diluting the clarity that made it valuable in the first place.

What Bloat Actually Costs

The consequences of unchecked expansion are rarely dramatic. That is part of what makes them so difficult to address. No single feature breaks a platform. Instead, the costs accumulate quietly: codebases that become harder to reason about, documentation that grows longer without becoming more useful, onboarding experiences that require new users to navigate layers of functionality they will never touch.

For open infrastructure specifically, the downstream effects reach further. Maintainers—already stretched thin—must now support features that serve edge cases. Security review becomes more complex as the attack surface widens. Forks proliferate as communities that preferred the original, leaner version of the tool build their own stripped-down variants. The project that tried to serve everyone ends up serving no one particularly well.

There is also a subtler cost: the erosion of identity. Platforms that stand for something specific attract contributors who share that specificity. When the scope expands without a coherent rationale, the community that built around the original vision begins to feel displaced. Not hostile, necessarily—just no longer at home.

Projects That Held the Line

The open-source landscape offers instructive examples of projects that resisted the pull of expansion and benefited from doing so. SQLite is perhaps the most cited: a database engine with an almost fanatical commitment to its original design constraints, maintained by a small team that has repeatedly declined to absorb features that would have complicated its core use case. Its longevity and ubiquity are not despite that restraint—they are products of it.

In the infrastructure space, projects built around specific research workflows have demonstrated similar durability when they resist scope expansion. Platforms that serve genomics researchers or climate scientists with tightly scoped tooling tend to maintain deeper community trust than generalist alternatives that attempt to serve the entire scientific computing ecosystem. The tradeoff is reach; the benefit is relevance.

Contrast this with projects that accepted every reasonable-sounding contribution and found themselves, five years later, maintaining sprawling systems that no single person fully understood. The contributors had moved on. The documentation was aspirational at best. The original users had migrated to newer, simpler alternatives.

The Mechanics of Principled Refusal

Saying no well is not the same as saying no reflexively. The distinction matters enormously, both for the health of the project and for the experience of the contributor on the other end of the decision.

Projects that manage this successfully tend to share a few characteristics. First, they have written down what they are. Not just what they do, but what they are for—and, critically, what they are not for. A clearly articulated scope document is not bureaucracy; it is a tool for making consistent decisions at scale, especially as contributor bases grow and institutional memory becomes less reliable.

Second, they treat rejection as a form of contribution. Explaining why a feature falls outside the project's scope, pointing toward alternative projects or forks where it might fit, and acknowledging the quality of the proposal while declining to merge it—these are acts of stewardship, not gatekeeping in the pejorative sense. The contributor who feels respected in rejection is far more likely to remain engaged with the project than one who receives a terse close with no explanation.

Third, and perhaps most importantly, they invest in the person or group responsible for making these calls. In many open infrastructure projects, no one is explicitly empowered to say no. Feature requests accumulate in issue trackers because no individual maintainer feels authorized to close them unilaterally. The result is a kind of passive acceptance: features that were never formally approved but were also never formally rejected, eventually implemented by contributors who interpreted silence as consent.

Assigning clear editorial authority—whether to an individual, a small committee, or a documented governance process—transforms refusal from a personal act into an institutional one. It distributes the social cost and makes the decision legible to the community.

Curation as Infrastructure

There is a useful analogy in the work of academic journal editors, museum curators, and urban planners. Each of these roles is defined not by what is included, but by what is excluded—and by the coherence that exclusion makes possible. A museum that accepts every donated artifact eventually becomes a storage facility. A city that permits every proposed development eventually loses the character that made it worth developing in the first place.

Open infrastructure is not so different. The platforms that endure are those that understand curation as a core function, not an afterthought. They recognize that the ability to reject good ideas—not bad ones, but genuinely good ideas that belong somewhere else—is what keeps a project's original purpose alive long enough to matter.

For builders and researchers who rely on open infrastructure, this has practical implications. When evaluating platforms for long-term use, scope discipline is a meaningful signal of project health. A tool that has grown in ten directions over five years may be less reliable as a foundation than one that has grown carefully in two.

And for those maintaining open infrastructure: the next time a well-meaning contributor submits a feature that is good, useful, and clearly outside your project's scope, consider that declining it may be the most valuable thing you do that week. The projects that last are not the ones that said yes to their communities most generously. They are the ones that loved their original purpose enough to protect it.