Posted by jlowin 9/13/2025
I like the "core" plus "contrib" model myself, but it does require a lot of upkeep which is often the reason to say "no" in the first place.
The project mono-repo is the way to go. Long-term maintenance is the primary software challenge, and distributed maintenance is strictly more difficult. If the project truly has hundreds of motivated contributors, then forks or plugins might be worthwhile, but most projects struggle to keep more than one motivated contributor.
(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.)
I am of the opinion that we only theme the components and provide snippets for how to use them for larger UI elements; the rest are of the mindset that we should be building more components in addition to the library for simple things like: a button that has a chevron in it for dropdown menus; a specific component for combining a tooltip with an info icon; a dialog with just an okay button, in addition to the dialog with both cancel and okay buttons; etc. etc.
Just the other day I got flak for saying no to accepting another version of a tooltip that had a different icon -- what's hard about using the tooltip with the icon you want...
I totally disagree. I don't owe them anything at all. If anything, they're using my work, for free.
> After all, if you don’t want those interactions, keep your code to yourself!
Because I'm giving my code for free (generally under a copyleft licence) does not mean at all that I want interactions.
> The goal in open-source must always be to create a positive, compounding community.
Again, no. It may be one of your goals if you want to, but it's perfectly fine to open source your code without wanting to create a community at all.
I don't agree; some maintainers just want the code to be /used/ somewhere and possibly in modified form, but are nto interested in upstreaming anything.
For instance the SQLite project operates like this.
This is how open source was back in the day:
- Someone puts code out there
- You fork, then use code. Maybe you change it, put it out there
- Someone forks it back if they like the changes
That's it. No one owes anyone a single thing except following the terms of the license.
Want a change? Do it your self, pay up, or fuck off and wait for someone else to maybe do it, or not do it at all, depending on how they feel.
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.
If the author experience a shift in the nature of PR and discussions, then at the very least it's been inverted in the projects they maintain. Even if there were contributors that did so in the past, if the ratio increased it's an issue worth discussing.
> Code "discusses itself" with you as write it
Perhaps (though i lean towards disagreement), but that discussion is not with the maintainer or rest of the team. "I thought about it and this is the best approach trust me bro" is not a great push request. All those questions the contributor answered and "discussed" are un-resolved for everyone else, and the burden of proof should be on the contributor.
If you have to think it through in front of an IDE to think about it properly, script it out in some quick python and return to the issue thread to discuss the approach. Perhaps post the python prototype even.
indeed, but that is no different now that it was before.
> If you have to think it through in front of an IDE to think about it properly, script it out in some quick python
Again, that is not possible; or rather, it is meaningless. It's like telling an author to sketch out a few chapters ahead. It doesn't work like that: The story has its own life and nature - even if, to an extent, drawn out from the author's psyche and unconscious - which develops through the process of writing. The sketches are very often just not what the story works itself out to be. In fact, not unlike literature - sometimes, truths reveal themselves only on the first or second rewrite.
I'm not sure what I'm missing, but that sounds very similar to the idea that the parent comment says about reflection happening before, during, and after writing the code. It's not at all uncommon for me to explain some code I pushed for review with something like "Originally, I planned to use approach X, but then I ran into complication Y, so I switched to approach Z to handle that". At least to me, this fits the pattern of reflecting beforehand (selecting an initial approach), during (deciding on how to handle a complication during the process of development), and after (literally the explanation itself to describe how the final state was reached), but it doesn't sound anywhere close to "trust me bro".
I don't read the parent comment as arguing against these sorts of explanations, just against the idea that the explanation could be sufficiently written entirely up front before any of the code was written.
> 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.
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"!
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.
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.
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.
Do you have any examples of this?
> 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.
> Thanks to @whoever for reporting the bug and providing a fix prototype.
(Probably prototype is not the correct word, but something like that.)
"... and suggesting a fix that inspired the actual change."
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.
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.