Hm, my first though is

> A user proposes a new feature. It’s well-designed, useful, and has no obvious technical flaws. And yet, the answer is “no.”

Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software.

> This work has gotten exponentially harder in the age of LLMs.

Maybe that is more of the problem. But that's probably not really "well-designed, useful, and has no obvious technical flaws" kind of stuff …

But since this is about an MCP tool, almost reads like LLM generated and the image above definitely is … maybe you're part of the problem!

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software.

I think its quite easy to find examples by thinking of the extremes.

- Why don't git add a native UI? (out of scope)

- Why don't excel add lua scripting? (already has visual basic)

- Why don't neofetch add a built-in ascii art editor so people can more easily customize their logo display? (Bloat)

- Why don't pandas and numpy just merge? (confusing user experience)

They can be amazingly written, with impeccable docs and test suite. But they're out of scope, deviate from the project philosophy, confuse the user, add maintenance for the future, or could could be their own projects.

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software.

More features means more code to maintain. More code to maintain means more time consumed. Time is finite. Time is the only resource you really meaningfully have in life.

I’m prioritising watching my kids take their first steps over expanding the scope of my open source python package.

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software

In my experience, there is a subset of open source projects where contributions are theoretically accepted, but in practice the maintainer doesn’t actually want to accept anything from anyone else unless it’s something they’ve asked for. They view contributors as assistants who are willing to volunteer their time to handle tasks that have been delegated, but they prefer to keep it as their own project.

That’s fine, of course, if that’s what they want from their project. It’s their project. Where it starts to get frustrating is if they throw a fit when someone forks their open source project, or when they start rejecting PRs from other people but then lightly rewriting the code and resubmitting it as their own work. Both of these have happened to me in recent years. In one case I spent a long time writing a new feature that the maintainer had created an issue for and marked as open for contributions. Yet no amount of responding to his PR reviews made him happy about the structure of my solution. Eventually I didn’t respond for 30 days because I was busy and he closed it as stale.

Then a few months later I saw the release notes included the feature he claimed he didn’t want. I looked at the commit history and saw he had committed something strikingly similar to the exact PR I had been working on, with only minimal changes to function names and locations of code blocks.

That’s life, of course, but at the same time it’s getting a little frustrating to read all of the writing holding open source maintainers up on a pedestal simply because they’re holding that position. Over the years many of the projects I use have had to fork off and take new leadership and names because the old maintainer was getting in the way of progress. Again, they are within their rights to do so, but that doesn’t mean we need to praise any and every move they make.

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software.

Ooh! Ooh! I know this one!

Very often, folks want to modify a shared system, to optimize for their own application.

However, the modifications could do things that would negatively impact other users of the system, or make it difficult to customize for specific implementations.

They can also add maintenance overhead, which can impact quality and release cadence.

it may not have technical flaws, but it can be scope creep, doesn't align with the vision for a project, or just additional complexity the project doesn't want to take on.

remember that people will often drive by contribute features they want, but then it's up the maintainers to keep it working forever (until they remove it, if they even can).

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software.

If you have a vision and boundaries for what the software does, then you wouldn't want to take a feature that makes it do more than that. The project owner still has to keep the scope where they want it.

Say you're making a music player and someone opens a PR to add PDF support. Suppose the implementation is immaculate.

If it’s your project, it’s up to you to decide where the focus of the project should be. There’s lots of good ideas on the boundary of every project, and you can’t include them all. Even useful features can be a distraction.