> 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.
criemen · 7m ago
> 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 wastes a day or week writing it.
This 1000%. In my opinion, the biggest part of my job is figuring out what should be built at all, not building what we all eventually agree should be built - that's often pretty easy, AI or no AI.
firefax · 9m ago
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.)
zygentoma · 14m ago
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!
aDyslecticCrow · 3m ago
> 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 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.
arccy · 10m ago
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).
johnny22 · 11m ago
> 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.
clickety_clack · 9m ago
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.
einpoklum · 14m ago
> ... 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.
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.
This 1000%. In my opinion, the biggest part of my job is figuring out what should be built at all, not building what we all eventually agree should be built - that's often pretty easy, AI or no AI.
(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.)
> 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!
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.
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).
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.
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.