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!

> ... articulate the project’s philosophy, setting expectations before a single line of code is written... Historically, we could assume that since writing code is an expensive, high-effort activity, contributors would engage in discussion before doing the work, or at least seek some sign that time would not be wasted. Today, LLMs have inverted this. Code is now cheap.

No. We could n ot assume that contributors would engage in such discussion, in the past; nor has this been inverted today.

Let's start with the second point: Good code, that reflects, or even evolves, a project's philosophy - is "expensive". LLMs can't write it (will they ever? I don't know), so they have not made it less expensive.

As for the first point: The order of things has never been quite like that. Code "discusses itself" with you as write it, and once you've written a piece, your perspective on what you're writing and what you should be writing in the future - and even on what you had already written. Your own reflection happens before writing any code, during writing, as well as afterwards.

> we recently tried to nudge this behavior by requiring an issue for every PR

I've not maintained or worked much with open source. But i would have assumed this was already common? It reflects how (from my experience) companies work internally with code. Discussion about a feature or a bug is done before writing any code (over lunch, or in a issue thread). We don't want to pay someone to write a feature we don't agree we need, or that collides with future maintenance.

Even before AI, i'd argue the vast majority of code is cheap and simple. But that is what makes it more important than ever to decide what code should exist before someone (well paid) wastes a day or week writing it.

More OS projects need to be willing to stop adding features and just focus on the occasional bugfix or security update. Look at say GIMP. They have no market force demanding they add features every year in the way Adobe does. And while it's good and cool to add basic functionality like new image standards when they are published, many projects get stuck in this cycle of adding "stuff" for no reason.

(Back in the day that's why I liked Firebird^H^H^H^Hfox -- you could bolt on extensions if you wish, but the core product was light.)