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 don't git add a native UI? (out of scope)
Git has native UI, just a bad one just like its cli UI, so it is in scope. You've just out-of-scoped better user experience.
> - Why don't excel add lua scripting? (already has visual basic)
Visual Basic is a bad/obscure language. Even real Excel didn't stop and added some JS/Python support. So you've again just rejected better user experience, very nice "project philosophy"!
Sure. Although git has a simple native UI, and there are many frontends, like Git Cola, lazygit, and so forth, although only the first is developed by git. The others are welcome. It is definitely out of scope for git itself.
> 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.
> 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.
Agreed, that's horrible. I would absolutely give credit at least for the idea behind even heavily rewritten code. And the freedom to fork is one of the essential freedoms of FOSS. Many people in certain organizations (cough GNOME cough RedHat cough) don't seem to get this. Typically the same ones who overlook key parts of the OSI definition:
> The license must not discriminate against any person or group of persons.
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
"And the freedom to fork is one of the essential freedoms of FOSS. Many people in certain organizations (cough GNOME cough RedHat cough) don't seem to get this."
Do you have any examples of this?
The entire XLibre debacle seems like the most obvious example.
So because the maintainers of Xorg does not want patches that causes regressions Gnome makes people fork projects somehow?
I said
> the freedom to fork is one of the essential freedoms of FOSS. Many people in certain organizations (cough GNOME cough RedHat cough) don't seem to get this."
and you asked for examples. XLibre is a fork (of XOrg); people from GNOME and RedHat have spoken publicly to object to the fact that the fork exists (along with more generally expressing opinions that I find incompatible with my understanding of FOSS). The GitHub for the project has a wiki page (https://github.com/X11Libre/xserver/wiki/Are-We-XLibre-Yet%3...) tracking what Linux distributions do or will include the package; several prominent developers were found (https://github.com/X11Libre/xserver/issues/346) to have defaced this page by referring to the developers in very unkind ways. Among these was Jordan Petridis who is part of GNOME as well as XOrg and wrote extensively about the effort to remove the X11 GNOME session (both on a gnome.org blog and on social media), making many contentious claims about the XLibre developer in the process.
For more, I'd have to put in considerable time collating information, or else you'd have to follow sources that I have found are better not to mention in places like HN because doing so would attract too much drama. But I only make comments like these on the basis of what I can independently verify.
I had a somewhat similar experience with libjpeg-turbo. Found a real bug, submitted a working PR, needed to argue my case that the bug was real despite providing examples, and eventually the maintainer paraphrased my PR into their own PR and landed their own fix. It's fine I suppose, but it was a weird experience.
sometimes people have a strong vision for the code they maintain. in those cases they'll usually more happily accept issues, rather than code. but GitHub doesn't let you turn off prs...
It's hard to know without looking at the datails, but in this case it would have been nice to add in the commit
> Thanks to @whoever for reporting the bug and providing a fix prototype.
(Probably prototype is not the correct word, but something like that.)
> (Probably prototype is not the correct word, but something like that.)
"... and suggesting a fix that inspired the actual change."
> 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.