One of the most challenging aspects of maintaining an open-source project is learning to say “no” — even to a well-crafted, seemingly valuable feature request. A user submits a pull request that’s technically sound, clearly written, and solves a real problem. Yet, the answer is still “no.” To the user, this can feel confusing or even dismissive. To the maintainer, it’s a vital act of stewardship. Over years of building and leading open-source projects like Prefect, FastMCP, and contributing to Apache Airflow, I’ve come to understand that the true measure of a project’s success isn’t the number of features it accumulates, but its coherence and alignment with a clear vision. As Prefect’s CTO Chris White puts it, people choose software when its abstractions match their mental model. Your job as a maintainer is to define that model and then build relentlessly toward it. A feature that’s useful but doesn’t fit the project’s soul can be more damaging than helpful — it risks diluting focus, increasing complexity, and confusing users. The key to defending that vision lies in documentation. Beyond explaining how the project works, you must articulate why it exists. Clear statements of purpose, design principles, and developer guidelines set expectations early. They create a flywheel: the more clearly a project communicates its philosophy, the more contributors it attracts who share that vision. Their work reinforces the project’s direction, which in turn strengthens the philosophy. Over time, process becomes a tool for alignment, not bureaucracy. You can confidently reject a PR not because it’s bad code, but because it’s misaligned — and the burden of proof is on the contributor to show why it belongs. This task has grown harder in the era of large language models. In the past, writing code was expensive, so contributors usually discussed ideas before coding. Today, LLMs make code cheap and fast. We now see fully formed PRs arriving with no prior conversation — well-written, functional, but generated without context. The objective was to satisfy a user’s request, not to uphold the project’s deeper purpose. This doesn’t mean all unsolicited contributions are unwelcome. A perfect, on-point PR that fixes a bug or adds a small, thoughtful feature is always welcome. But the balance has shifted. The signal-to-noise ratio has declined. Many PRs now represent high effort for low value — a polished artifact without meaningful alignment. To address this, FastMCP introduced a rule requiring an issue for every PR. But the result was predictable: single-sentence issues opened just before the PR. More effective than rules is a simple, direct response: “We’re not convinced this is something the framework should do.” This shifts the burden to the contributor to justify not just the feature, but its fit within the project’s philosophy. The effort to argue the case is valuable — it strengthens the project’s clarity. Another important consideration is long-term maintenance. Merging a PR means taking on responsibility for it — fixing bugs, handling edge cases, and supporting future changes. If a feature introduces complexity or invites further enhancements, the maintainer is usually the one left holding the bag. FastMCP addresses this by using a contrib module for functionality that’s useful but not core. These modules are maintained by their authors and come with no guarantee of compatibility. In many cases, such features are better off as standalone projects, but this allows them to exist in a more communal, low-pressure way. I’ve also noticed a personal shift. In the early days of Prefect, we aimed for a 15-minute response time. That level of engagement reflected the value we placed on user interaction. Today, if a user sends a wall of LLM-generated text with no effort to clarify their problem, I’m more likely to respond in kind — not because I’ve lost care, but because I’ve seen the pattern. I still prefer a clear, concise question with a minimal reproducible example. This approach may seem old-fashioned in an age of rapid, AI-assisted development. But in my experience, thoughtful stewardship separates utility tools from truly great software. It’s not about rejecting change — it’s about protecting the project’s identity. I was reminded of this recently during meetings with the MCP Committee in New York. MCP is a young protocol under intense pressure to expand. Every day, it’s asked to solve new problems, support new use cases. Yet, the team consistently asked a crucial question: “This is a good idea. But is this what a protocol should do?” That discipline — the courage to say no to good ideas that don’t belong — is what gives a project longevity. It’s not about being rigid. It’s about being intentional. I left those meetings hopeful. The future of open source isn’t just about speed or scale. It’s about care, clarity, and the quiet, essential work of saying no.