I’ve had some experience developing an infrastructure-level system for use around the world.
I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away.
One of the most important things I did, in that decade, was say “no” a lot.
Some folks were not happy about it, and Godwin’s Law was invoked on my ass, multiple times.
A lot of requests were ones that would optimize for a specific use case, but it was a generalist system, so it had to remain “imperfect.”
In the end, it all worked out well, if not “perfectly.” It’s now a worldwide system, being run by hundreds of organizations, and used daily, by thousands of people.
> I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away.
No you didn't.
Younger folks reading this, you don't owe anyone free labor. If you want to donate your time to open source that's ok but just know there are thousands of people in this industry that don't care about your mental health and will continue to take advantage of you because you enjoy coding and don't understand how valuable your time is yet.
Sometimes, we do stuff for reasons that folks, these days, can't relate to. I'm truly sorry that you've never had a Cause to which you could dedicate that kind of effort.
No one ever "took advantage" of me. I'm actually kind of hard to hoodwink.
But it’s true, nonetheless. I’ve had it said to me, and it applies.
If you are unable to comprehend that people will do something for altruistic or deeply personal reasons, then we live in entirely different worlds, and it’s a waste of time, trying to explain ourselves.
I get the impression the OP isn’t saying they “had to” in the sense of “being forced to by outside forces” but rather “wanted to for personal satisfaction and pride”. I understand the feeling: you create something you’re proud of and which means a lot to you, and before you let it go you want to ensure it’s in good competent hands which will care for it and make it flourish the same way you would.
That is very different from being exploited or taken advantage of.
I agree with the quoted commenter's point that sometimes shit matters enough to put up with the suck, but I also agree with your point that people need to understand that walking away might be the right thing to do.
This is true. I knew what I was getting into. I didn't expect it to be ten years, but I did expect at least five, before I could get folks to pitch in. I knew the character of the folks that would be trying to force the system into shapes that would not last, and how they would react to me.
In this case, it was for an organization that I've been involved in, for decades. I'm incredibly Grateful for what it's done for me, and I'm simply paying it back a bit.
The system was required to help them improve their discoverability, which could be life-saving.
It's not hyperbole to say that the system has probably saved many lives, and will continue to do so, for the foreseeable future.
It's also pretty much worthless, monetarily. No one would be willing to pony up a fraction of what it would have cost to build, if it were paid.
I'd do it all over again, if I had to. Fortunately, I don't have to. The team that took it over have done great things with it. It's a ship of Theseus type of thing. There's probably not much code I wrote, left. I write apps that now leverage it.
I don’t really mention it in public, but it’s no secret. It’s managed by a team, these days, and it’s not really appropriate for me to draw much attention to my role. They are doing a great job.
Seems like you are saying the same thing as OP, but with a more cynical framing. He set boundaries because he did not in fact have to accept those PRs.
One might argue that programmers owe something to all those maintainers who so nonsensically donated their time and money to furthering a free software ecosystem that every single one of us - humans, not just programmers - benefit from. Maybe it's money, as you seem to imply, but maybe it's more time and labor to continue to further that cause.
If someone has a “readfile” cli app on gh it’s just a moment away from a issue being open:
> thanks for a great project, in our org we have a requirement that we only write files, not read them. Can you please add —-write flag so this app works for us?
The fact that someone clones your repo or uses your software doesn’t mean that you owe them anything. Every person with open source code should realise this before they start responding to feature requests.
I await the first LLM generated PR to my JS canvas library with eager anticipation.
I can't wait to ask them if they've run the PR branch against all of the test demos, so they can prove that the PR doesn't break existing functionality. Currently there's just under 200 test demos, each of which needs to be tested manually (because: hell = canvas library + animation) across the three main browsers to make sure nothing breaks. Bonus points for going the extra mile for testing on mobile device browsers.
Over the last 6 months this has been my experience with new engineers at work, absolutely awful. I wish people didn't feel the need to throw out SDLC once the LLMs came along.
It's not rare for me to ask if they tested it. They can lie, but if they say they did and it crashes on me right when I start it, then I may never trust this contributor ever again.
Also I don't hesitate to be frank in my review, it's okay to say "I won't merge your feature because I don't think I can maintain that, but you're free to keep your fork". Or "I can merge it if you change this and this", but in that case I need to actually merge if they do what I asked for.
> They can lie, but if they say they did and it crashes on me right when I start it, then I may never trust this contributor ever again.
If it’s obvious without a shadow of a doubt that someone has lied, either on an issue or a PR, I’m very much inclined to block them. I have a lot of patience for people who are still learning or make silly mistakes but are genuinely making an effort; but if someone doesn’t even help me help them, that’s disrespectful and such behaviour shouldn’t be rewarded.
> 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.
Requiring an issue per PR makes sense for significant bugs and features, but taken to the extreme it feels arbitrary and pedantic.
I occasionally submit documentation fixes when I find broken docs (outdated commands in the docs, incorrect docs). I’ve had these rejected before because someone insisted I create an issue and have it go through some process first just to submit an obvious 1 line fix.
At the extremes it clouds the issue backlog. You try searching for something and find pages and pages of arbitrary issues that didn’t need to exist other than for someone to get past the gatekeeper.
I forget the episode its been years but the Talk Python podcast had someone I think from the Django team mention tips on contributing to open source and one of them was start by volunteering to document things, most devs dont do it or want to do it. It forces you to know and understand the codebase and by the time you want to contribute more you know the library better.
I actually don’t encourage this. If you find broken docs then contributing a fix is good.
However, writing docs as the starting point for someone’s entry to a project doesn’t produce good results much of the time. You need someone who is more familiar with the project to write the docs. Having the docs written by someone new to the project can lead to some really frustrating docs.
This is even more true now that projects attract junior devs who want to build their resumes and think that documenting can be done by pointing Claude Code at the codebase and demanding it write some docs.
It also encourages bad behavior from devs who think they’re doing a favor for new contributors by leaving the documentation as an exercise for someone else.
You could easily say that docs, comments, and formatting changes don't need issues. The core problem the author is trying to cope with is code changes or features that could deviate the project or scope. I feel it's quite reasonable to set a blanket "issue first" rule for any change beyond like 5 rows of code.
This was / is not my experience. I worked mainly on frontend code, web and mobile app.
As a developer, I got the task, an “order” that something needs to be added. Best case scenario, my product owner / manager came up with it, because they talk to customers and noticed it would be helpful. Worse case scenario, someone else above them told them to do it because “we need it”, and I just hope the product person on my team properly vetted the request. Worst case scenario, the “order” came down to our team, and the managers push to the individual contributors and there is no room for discussion at this point anymore and an arbitrary (made up) deadline that is somehow always unrealistic.
Oof, ye i have heard about this kind of company culture. I think front-end and app development is particularly prone to cheap and dirty iteration. Bugs are cheap and non-consequential. New features are visible, fast to add, and make higher-ups happy.
I work in industrial embedded C. So perhaps i have weird expectations about the level of pedantry. A 10 row code change may take week to discuss, and likely require an open issue and test-case to get through.
At worst, a small 100 row code-change may require a 8000$ independent re-certification of the device before being fully pulled into master.
Yeah frontend don't care about correctness. I've seen entire websites go entirely blank because I clicked somewhere and that triggered a js error and that means delete the whole DOM.
> 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.
I made a lot of PR for Chez Scheme (and indirectly Racket). For me it's easier to write the code, perhaps because I'm not an English native speaker, but my Spanish is bad too.
Most of my PR are like 30-50 LOC (including comments and tests), with a few very related features, and I have probably a 90-95% merge rate. Sometimes writing the explanation takes a long time. Many times while writing the code I get a lot of small surprises and unexpected corner cases. So most of the time a previous discussion would be too generic to be useful for me and inteligible for the maintainers.
Anyway, my idea is to take only a few hours (4?), perhaps distributed in a few slow days. So if it's not merged it's not a big deal, not hard feelings. Also a short feature is easier to review and modify if necessary.
I have worked at a company that required an issue for every PR. It was dumb though. It just meant you made the PR, got shouted at by some checker for not having an issue, create an issue, copy & paste the PR title into the issue, submit the PR, and then the issue gets closer again.
Totally pointless.
> Discussion about a feature or bug is done before writing any code.
Not always. Not all PRs are significant enough to warrant discussion. For example I fixed a copy/paste bug recently where they had `foo_a = foo_b + i;` where it should have been `foo_b = foo_b + i;`. Obvious mistake. One character fix. Why on earth would I bother creating an issue and discussing how to fix it?
> We don't want to pay someone to write a feature we don't agree we need
We're talking about open source here, and saying "no" to unpaid, external contributors.
The way I approach it as an external contributor is that if the project is useful to me, I fork it, make my changes, and then open a PR in case the maintainers want to adopt them upstream. They don't have to, it's fine. But I don't have to ask for their opinion in an issue because I will just do what I want in my fork anyway.
I think the stereotypical open source way is that you modify the code in private to what you want it to be and then upstream that in case it might be useful for others.
When I was a teenager I submitted a random/unsolicited pull request to something in the spree ecosystem, got a very nice message from the maintainer/author saying that he appreciates it but it wasn't in the direction he wanted to take the library, but I could collaborate with him in some other way.
Glad for the patience in that message, if it were spicy I might have been put off programming.
> There is nothing more delightful than the drive-by PR that lands, fully formed and perfectly aligned, fixing a bug or adding a small, thoughtful feature.
I'm actually generally not a fan of "drive-by" PR's.
Unless the drive-by PR is fixing a simple bug in a simple way, then the contributor really should've opened an issue first. Doing otherwise is rude imo.
This is actually open source etiquette that I'd like to see encouraged more in the future. Something like "If you've never contributed to this project before, then open an issue first". I understand that this can be explicitly placed in a CONTRIBUTING.md file, but I think that this should just become common etiquette that we all follow and understand.
> Unless the drive-by PR is fixing a simple bug in a simple way, then the contributor really should've opened an issue first. Doing otherwise is rude imo.
I kindly disagree. If the project is open source, it means that I can fork it. If I find an open source project and want to add a feature to it, I will fork, implement my feature, and then open a PR to the original project. A couple things there:
1. I have no need to open a PR to upstream, it's totally right to keep my changes in my fork (as long as I honour the licence).
2. If the maintainers don't feel like merging my PR, they don't have to. It's their right. They may request changes, and I may choose not to implement them.
It's not the only way to do it: it's perfectly fine to open an issue and ask for guidance. But I don't see the problem in opening a PR saying "look what I did with your project: you can merge it if you want".
I understand, but my experience with open source projects on Github basically says the opposite. It doesn't really matter how detailed my issue is or if I point to the actual bug in the code, if there isn't a PR it simply gets ignored.
This grinds my gears regularly but I try to let it go because I have no power to solve this issue.
A year ago I changed my CONTRIBUTING document to say that I don't accept pull-requests on my very modest open source project (a special purpose DNS server)
I like coding, but am not fond of reviewing other people's code.
Also, the few PRs I received weren't up to snuff: for example, they included code changes but not tests. If they included tests, they weren't comprehensive. And they never included documentation changes.
> "“In writing, you must kill all your darlings.” - William Faulkner [0]
This quote is becoming a cliche. Perhaps because it provides such helpful dramatic motivation to the act of maintaining creative quality through active negative selection. When have the freedom to create things we want, that can be hard.
Given how many improvements are ignored or rejected in so many of the open source projects, it doesn't seem like "one of the hardest parts" is hard at all.
Especially when "burden of proof is on the contributor, never the repo" and the repo is hiding behind immeasurable principles such as "ultimate success of a project isn’t measured by the number of features it has, but by the coherence of its vision and whether it finds resonance with its users." with the perfect example
> This threat can take many forms. The most obvious is a feature that’s wildly out of scope, like a request to add a GUI to a CLI tool
Indeed, a threat to the project that can transform a niche tool into a widely used one of at least reduce the usability barriers for a wider user base. Shoo the "incoherent vision" of a drive by Trojan horse bearing gui contribution gifts!
> there is a significant transfer of responsibility when a PR is merged. ... maintainer who is suddenly on the hook for it.
> we’ve introduced and documented the contrib
Oh, so all you had to do to get off the hook was add a comment that you're not responsible?
Scope creep destroys projects and software. Most software is bad because it does too much, so most of it barely works and of the parts that do kind of work, they don't work together.
Writing code is easy. Not writing code is much harder. Know what code to write, and what not to, is hardest.
Not really. That solution only works if you are willing to maintain your fork forever just for your one patch, and you're happy to build the software yourself every time you need it and it's a "leaf" project (e.g. it's not good if you want to add a feature to Linux and it only exists on your machine).
This answer is very much like "well if you don't like Trump you're free to live in another country!". Technically true.. ish. Practically dumb as hell.
The "willing to maintain your work" forever is the crux here - the open-source contributor is doing some amount of work to bring their contribution in line with the expectations of the repository, but it's up to the repository's maintainers to decide if they want to take on the work of maintaining that contribution forever. And that asymmetry exactly what TFA is about.
If there's great features missing form a library which are out of scope for the library, you have options - fork it, make a new library depending on the other one, launch a new linux distribution, and so on. These options require taking on the long-term work that the other library is saying (implicitly) that they don't want to do.
Libraries /should/ be tightly scoped and think hard about serving broad use-cases with simple API's: Otherwise maintenance, documentation, and discoverability of features become nightmares. It's also completely OK for composition to happen, as new libraries serve new sets of features for their own specific use cases, with dependencies on existing work. It's an ecosystem! It's ok!
Maintainers really do need to say no more often, and teach users to be way less entitled. helping maintain a big project you see all sorts of users trying to push features just for themselves onto you.
I see a solution to this for both sides: encourage published forks. This allows the contributor to shoulder the burden of packaging and support. If you support the patch, adopt the fork and advocate on the issue. If you find issues, help refine it in the fork’s issue tracker.
There will be pressure to make it easier to discover plugins, install plugins, install plugin dependencies, manage plugin options, uninstall plugins, verify and validate plugins, etc. It's all well and good to punt these problems to 'someone else' but that usually means either no one, someone who does a one-shot that becomes immediately out-of-date, or someone nefarious.
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.
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.)
Maintainers should understand that saying no and closing an issue is polite. Much better than ignoring, stalling conversations, demanding yak-shaving, bike-shedding or pretending that a feature request could be added if only someone else contributes it, then never accepting the PR once it arrives.
Struggling with this right now at my current job as one of four lead devs tasked with implementing our design system with using a React component library.
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...
> As an open-source maintainer, you should be ecstatic every time someone engages with your project. After all, if you didn’t want those interactions, you could have kept your code to yourself!
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.
IMHO a better example is: "Can we make a teeny tiny change to CURL that would allow me to use it as a fetch engine for the GUI web browser I'm making? I can't think of anything else that might use that change, but pretty pretty please?"
This could have been a good example, except curl is not only a CLI, it builds on top of libcurl, one of the most popular libraries for doing HTTP in C. If building a web browser, it’s one of the first candidates for a fetch engine I would reach for.
> ... 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.
> No. We could not assume that contributors would engage in such discussion, in the past; nor has this been inverted today.
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.
> 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.
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.
- 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.
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."
> 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...
> 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.
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.
I strongly disagree with the premise of the article and content being reiterated here by a number of commenters.
An incredibly common pattern is a maintainer thinking they know better in an area they are inexperienced in, and rejecting change because they don't like the sound of something or are unable to see past their cultural biases.
We know this by another name - not invented here.
Common, practical areas this occurs in boring open source business CRUD applications:
- Address models aren't thought out. "Why would anyone want geocoding? What addresses don't fit the US style?"
- Phone numbers get modelled as plain strings and all of a suddenly "but changing them to be standardised is really hard"
- Company, brand, account structures rarely add URLs or links to external datasets. What possible use is a wikidata ID?
- Why would I put in vCard/CSV/Schema.org/any other import/export?
All of these areas are often ancillary to the primary purpose of whatever the application is, so get rejected out of hand.
But the use cases they enable for users - who don't use the application in isolation - are then completely blocked.
- Map, route or visualise spatial data mashed up with other datasets. Send people to remote locations without formal addresses.
- Hook up phone systems to make your system run for teams with centralisation, integrate SMS based messaging, etc.
- Join to public datasets to understand more about your customers (food safety, licencing registers, corporate entity registers, contract management systems, etc)
A typical maintainer is going to say "wait, what; my accounting system is all about finance, none of this is relevant!"; but they miss out on what users really want in many cases: interoperability or data portability.
The problem is the maintainer's frame is in their world view; and if they aren't dogfooding their project they aren't running into their users problems - how likely is it the maintainer is the BI analyst, or the low level data entry person, or from a country where QR code payment is the norm, or a million other considerations?
I used to think the same way. Why does xyz developer refuse to do this? Don't they know that feature will be of great use to people like me?
Then I made something for myself. It took a lot of time and iterations because my needs were evolving. After it was perfectly tuned for me, I put it out there so someone else can find it useful directly or indirectly.
I started receiving feature requests and changes. I accepted a few, but rejected a a lot. This is mine. I made it for myself. I didn't step out there to build something for the world, I made it for myself and it was perfect for myself. If someone wants my stuff to do things their way and not mine, they're completely free to do so, that's why I shared it.
If I put my paintings out there and the steps I took to draw it, people are free to follow those steps and recreate mine or do it in their own way. You don't demand changes on my original painting.
> A typical maintainer is going to say "wait, what; my accounting system is all about finance, none of this is relevant!"; but they miss out on what users really want in many cases: interoperability or data portability.
I think you are the one missing the point.
Users can want whatever they want to want. They're receiving, generally, et gratis et libre software which depends on someone else's time and effort. If they aren't getting what they want from the project, they are free to fork that project — and when they do, they're still getting more than they would otherwise be entitled to (i.e. the ability to start from scratch).
Further, a maintainer by definition is normally someone not charged with implementing new functionality (that's a "developer"), but simply with bugfixes.
I’ve had some experience developing an infrastructure-level system for use around the world.
I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away.
One of the most important things I did, in that decade, was say “no” a lot.
Some folks were not happy about it, and Godwin’s Law was invoked on my ass, multiple times.
A lot of requests were ones that would optimize for a specific use case, but it was a generalist system, so it had to remain “imperfect.”
In the end, it all worked out well, if not “perfectly.” It’s now a worldwide system, being run by hundreds of organizations, and used daily, by thousands of people.
> I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away.
No you didn't.
Younger folks reading this, you don't owe anyone free labor. If you want to donate your time to open source that's ok but just know there are thousands of people in this industry that don't care about your mental health and will continue to take advantage of you because you enjoy coding and don't understand how valuable your time is yet.
Sometimes, we do stuff for reasons that folks, these days, can't relate to. I'm truly sorry that you've never had a Cause to which you could dedicate that kind of effort.
No one ever "took advantage" of me. I'm actually kind of hard to hoodwink.
Yes, I did "have to."
If I have to explain, you wouldn't understand.
I think folks these days can relate just fine. That particular guy a bit less so.
> If I have to explain, you wouldn't understand.
It's not that I don't agree with you, but this sentence is very strange. It can be used to "support" anything and everything at all.
But it’s true, nonetheless. I’ve had it said to me, and it applies.
If you are unable to comprehend that people will do something for altruistic or deeply personal reasons, then we live in entirely different worlds, and it’s a waste of time, trying to explain ourselves.
I get the impression the OP isn’t saying they “had to” in the sense of “being forced to by outside forces” but rather “wanted to for personal satisfaction and pride”. I understand the feeling: you create something you’re proud of and which means a lot to you, and before you let it go you want to ensure it’s in good competent hands which will care for it and make it flourish the same way you would.
That is very different from being exploited or taken advantage of.
I agree with the quoted commenter's point that sometimes shit matters enough to put up with the suck, but I also agree with your point that people need to understand that walking away might be the right thing to do.
Finding that balance can be very hard.
This is true. I knew what I was getting into. I didn't expect it to be ten years, but I did expect at least five, before I could get folks to pitch in. I knew the character of the folks that would be trying to force the system into shapes that would not last, and how they would react to me.
In this case, it was for an organization that I've been involved in, for decades. I'm incredibly Grateful for what it's done for me, and I'm simply paying it back a bit.
The system was required to help them improve their discoverability, which could be life-saving.
It's not hyperbole to say that the system has probably saved many lives, and will continue to do so, for the foreseeable future.
It's also pretty much worthless, monetarily. No one would be willing to pony up a fraction of what it would have cost to build, if it were paid.
I'd do it all over again, if I had to. Fortunately, I don't have to. The team that took it over have done great things with it. It's a ship of Theseus type of thing. There's probably not much code I wrote, left. I write apps that now leverage it.
can you share what system is it ? is it public ?
I don’t really mention it in public, but it’s no secret. It’s managed by a team, these days, and it’s not really appropriate for me to draw much attention to my role. They are doing a great job.
It is public.
Happy to share it one-on-one.
Seems like you are saying the same thing as OP, but with a more cynical framing. He set boundaries because he did not in fact have to accept those PRs.
One might argue that programmers owe something to all those maintainers who so nonsensically donated their time and money to furthering a free software ecosystem that every single one of us - humans, not just programmers - benefit from. Maybe it's money, as you seem to imply, but maybe it's more time and labor to continue to further that cause.
> Godwin’s Law was invoked on my ass
Can you elaborate?
I was called a Nazi.
People can get pretty upset, when you say "no."
If someone has a “readfile” cli app on gh it’s just a moment away from a issue being open:
> thanks for a great project, in our org we have a requirement that we only write files, not read them. Can you please add —-write flag so this app works for us?
The fact that someone clones your repo or uses your software doesn’t mean that you owe them anything. Every person with open source code should realise this before they start responding to feature requests.
My pet peeve is people who use LLMs to generate code, never check whether it works, and then submit a PR.
As if open-source maintainers don't have enough chores.
I await the first LLM generated PR to my JS canvas library with eager anticipation.
I can't wait to ask them if they've run the PR branch against all of the test demos, so they can prove that the PR doesn't break existing functionality. Currently there's just under 200 test demos, each of which needs to be tested manually (because: hell = canvas library + animation) across the three main browsers to make sure nothing breaks. Bonus points for going the extra mile for testing on mobile device browsers.
Over the last 6 months this has been my experience with new engineers at work, absolutely awful. I wish people didn't feel the need to throw out SDLC once the LLMs came along.
It's not rare for me to ask if they tested it. They can lie, but if they say they did and it crashes on me right when I start it, then I may never trust this contributor ever again.
Also I don't hesitate to be frank in my review, it's okay to say "I won't merge your feature because I don't think I can maintain that, but you're free to keep your fork". Or "I can merge it if you change this and this", but in that case I need to actually merge if they do what I asked for.
> They can lie, but if they say they did and it crashes on me right when I start it, then I may never trust this contributor ever again.
If it’s obvious without a shadow of a doubt that someone has lied, either on an issue or a PR, I’m very much inclined to block them. I have a lot of patience for people who are still learning or make silly mistakes but are genuinely making an effort; but if someone doesn’t even help me help them, that’s disrespectful and such behaviour shouldn’t be rewarded.
> 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.
Requiring an issue per PR makes sense for significant bugs and features, but taken to the extreme it feels arbitrary and pedantic.
I occasionally submit documentation fixes when I find broken docs (outdated commands in the docs, incorrect docs). I’ve had these rejected before because someone insisted I create an issue and have it go through some process first just to submit an obvious 1 line fix.
At the extremes it clouds the issue backlog. You try searching for something and find pages and pages of arbitrary issues that didn’t need to exist other than for someone to get past the gatekeeper.
I forget the episode its been years but the Talk Python podcast had someone I think from the Django team mention tips on contributing to open source and one of them was start by volunteering to document things, most devs dont do it or want to do it. It forces you to know and understand the codebase and by the time you want to contribute more you know the library better.
I actually don’t encourage this. If you find broken docs then contributing a fix is good.
However, writing docs as the starting point for someone’s entry to a project doesn’t produce good results much of the time. You need someone who is more familiar with the project to write the docs. Having the docs written by someone new to the project can lead to some really frustrating docs.
This is even more true now that projects attract junior devs who want to build their resumes and think that documenting can be done by pointing Claude Code at the codebase and demanding it write some docs.
It also encourages bad behavior from devs who think they’re doing a favor for new contributors by leaving the documentation as an exercise for someone else.
You could easily say that docs, comments, and formatting changes don't need issues. The core problem the author is trying to cope with is code changes or features that could deviate the project or scope. I feel it's quite reasonable to set a blanket "issue first" rule for any change beyond like 5 rows of code.
Or if you need a fix ASAP and go ahead and make the change locally, then want to upstream it later.
This was / is not my experience. I worked mainly on frontend code, web and mobile app.
As a developer, I got the task, an “order” that something needs to be added. Best case scenario, my product owner / manager came up with it, because they talk to customers and noticed it would be helpful. Worse case scenario, someone else above them told them to do it because “we need it”, and I just hope the product person on my team properly vetted the request. Worst case scenario, the “order” came down to our team, and the managers push to the individual contributors and there is no room for discussion at this point anymore and an arbitrary (made up) deadline that is somehow always unrealistic.
Oof, ye i have heard about this kind of company culture. I think front-end and app development is particularly prone to cheap and dirty iteration. Bugs are cheap and non-consequential. New features are visible, fast to add, and make higher-ups happy.
I work in industrial embedded C. So perhaps i have weird expectations about the level of pedantry. A 10 row code change may take week to discuss, and likely require an open issue and test-case to get through.
At worst, a small 100 row code-change may require a 8000$ independent re-certification of the device before being fully pulled into master.
Yeah frontend don't care about correctness. I've seen entire websites go entirely blank because I clicked somewhere and that triggered a js error and that means delete the whole DOM.
> 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.
I made a lot of PR for Chez Scheme (and indirectly Racket). For me it's easier to write the code, perhaps because I'm not an English native speaker, but my Spanish is bad too.
Most of my PR are like 30-50 LOC (including comments and tests), with a few very related features, and I have probably a 90-95% merge rate. Sometimes writing the explanation takes a long time. Many times while writing the code I get a lot of small surprises and unexpected corner cases. So most of the time a previous discussion would be too generic to be useful for me and inteligible for the maintainers.
Anyway, my idea is to take only a few hours (4?), perhaps distributed in a few slow days. So if it's not merged it's not a big deal, not hard feelings. Also a short feature is easier to review and modify if necessary.
I have worked at a company that required an issue for every PR. It was dumb though. It just meant you made the PR, got shouted at by some checker for not having an issue, create an issue, copy & paste the PR title into the issue, submit the PR, and then the issue gets closer again.
Totally pointless.
> Discussion about a feature or bug is done before writing any code.
Not always. Not all PRs are significant enough to warrant discussion. For example I fixed a copy/paste bug recently where they had `foo_a = foo_b + i;` where it should have been `foo_b = foo_b + i;`. Obvious mistake. One character fix. Why on earth would I bother creating an issue and discussing how to fix it?
> We don't want to pay someone to write a feature we don't agree we need
We're talking about open source here, and saying "no" to unpaid, external contributors.
The way I approach it as an external contributor is that if the project is useful to me, I fork it, make my changes, and then open a PR in case the maintainers want to adopt them upstream. They don't have to, it's fine. But I don't have to ask for their opinion in an issue because I will just do what I want in my fork anyway.
I think the stereotypical open source way is that you modify the code in private to what you want it to be and then upstream that in case it might be useful for others.
When I was a teenager I submitted a random/unsolicited pull request to something in the spree ecosystem, got a very nice message from the maintainer/author saying that he appreciates it but it wasn't in the direction he wanted to take the library, but I could collaborate with him in some other way. Glad for the patience in that message, if it were spicy I might have been put off programming.
> There is nothing more delightful than the drive-by PR that lands, fully formed and perfectly aligned, fixing a bug or adding a small, thoughtful feature.
I'm actually generally not a fan of "drive-by" PR's.
Unless the drive-by PR is fixing a simple bug in a simple way, then the contributor really should've opened an issue first. Doing otherwise is rude imo.
This is actually open source etiquette that I'd like to see encouraged more in the future. Something like "If you've never contributed to this project before, then open an issue first". I understand that this can be explicitly placed in a CONTRIBUTING.md file, but I think that this should just become common etiquette that we all follow and understand.
> Unless the drive-by PR is fixing a simple bug in a simple way, then the contributor really should've opened an issue first. Doing otherwise is rude imo.
I kindly disagree. If the project is open source, it means that I can fork it. If I find an open source project and want to add a feature to it, I will fork, implement my feature, and then open a PR to the original project. A couple things there:
1. I have no need to open a PR to upstream, it's totally right to keep my changes in my fork (as long as I honour the licence).
2. If the maintainers don't feel like merging my PR, they don't have to. It's their right. They may request changes, and I may choose not to implement them.
It's not the only way to do it: it's perfectly fine to open an issue and ask for guidance. But I don't see the problem in opening a PR saying "look what I did with your project: you can merge it if you want".
I strongly disagree. I don't find it rude at all. In fact I find the idea that you have to get permission to offer code much more rude.
You are free to say "sorry I don't want to do it like this; you've wasted your time". That's totally fine.
I understand, but my experience with open source projects on Github basically says the opposite. It doesn't really matter how detailed my issue is or if I point to the actual bug in the code, if there isn't a PR it simply gets ignored.
This grinds my gears regularly but I try to let it go because I have no power to solve this issue.
A year ago I changed my CONTRIBUTING document to say that I don't accept pull-requests on my very modest open source project (a special purpose DNS server)
I like coding, but am not fond of reviewing other people's code.
Also, the few PRs I received weren't up to snuff: for example, they included code changes but not tests. If they included tests, they weren't comprehensive. And they never included documentation changes.
I think it's fine. Open source does not mean at all that it has to be open development. Doesn't mean it cannot be, of course.
> "“In writing, you must kill all your darlings.” - William Faulkner [0]
This quote is becoming a cliche. Perhaps because it provides such helpful dramatic motivation to the act of maintaining creative quality through active negative selection. When have the freedom to create things we want, that can be hard.
[0] https://www.goodreads.com/quotes/79715-in-writing-you-must-k...
Given how many improvements are ignored or rejected in so many of the open source projects, it doesn't seem like "one of the hardest parts" is hard at all.
Especially when "burden of proof is on the contributor, never the repo" and the repo is hiding behind immeasurable principles such as "ultimate success of a project isn’t measured by the number of features it has, but by the coherence of its vision and whether it finds resonance with its users." with the perfect example
> This threat can take many forms. The most obvious is a feature that’s wildly out of scope, like a request to add a GUI to a CLI tool
Indeed, a threat to the project that can transform a niche tool into a widely used one of at least reduce the usability barriers for a wider user base. Shoo the "incoherent vision" of a drive by Trojan horse bearing gui contribution gifts!
> there is a significant transfer of responsibility when a PR is merged. ... maintainer who is suddenly on the hook for it.
> we’ve introduced and documented the contrib
Oh, so all you had to do to get off the hook was add a comment that you're not responsible?
You are free to fork and make whatever mess of features you wish for!
You're free to address any of the actual points in my comment instead of using an irrelevant cliche!
Scope creep destroys projects and software. Most software is bad because it does too much, so most of it barely works and of the parts that do kind of work, they don't work together.
Writing code is easy. Not writing code is much harder. Know what code to write, and what not to, is hardest.
Not really. That solution only works if you are willing to maintain your fork forever just for your one patch, and you're happy to build the software yourself every time you need it and it's a "leaf" project (e.g. it's not good if you want to add a feature to Linux and it only exists on your machine).
This answer is very much like "well if you don't like Trump you're free to live in another country!". Technically true.. ish. Practically dumb as hell.
The "willing to maintain your work" forever is the crux here - the open-source contributor is doing some amount of work to bring their contribution in line with the expectations of the repository, but it's up to the repository's maintainers to decide if they want to take on the work of maintaining that contribution forever. And that asymmetry exactly what TFA is about.
If there's great features missing form a library which are out of scope for the library, you have options - fork it, make a new library depending on the other one, launch a new linux distribution, and so on. These options require taking on the long-term work that the other library is saying (implicitly) that they don't want to do.
Libraries /should/ be tightly scoped and think hard about serving broad use-cases with simple API's: Otherwise maintenance, documentation, and discoverability of features become nightmares. It's also completely OK for composition to happen, as new libraries serve new sets of features for their own specific use cases, with dependencies on existing work. It's an ecosystem! It's ok!
Maintainers really do need to say no more often, and teach users to be way less entitled. helping maintain a big project you see all sorts of users trying to push features just for themselves onto you.
I see a solution to this for both sides: encourage published forks. This allows the contributor to shoulder the burden of packaging and support. If you support the patch, adopt the fork and advocate on the issue. If you find issues, help refine it in the fork’s issue tracker.
Or build a proper plugin system, or other means of composition.
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.
There will be pressure to make it easier to discover plugins, install plugins, install plugin dependencies, manage plugin options, uninstall plugins, verify and validate plugins, etc. It's all well and good to punt these problems to 'someone else' but that usually means either no one, someone who does a one-shot that becomes immediately out-of-date, or someone nefarious.
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.
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.)
Maintainers should understand that saying no and closing an issue is polite. Much better than ignoring, stalling conversations, demanding yak-shaving, bike-shedding or pretending that a feature request could be added if only someone else contributes it, then never accepting the PR once it arrives.
Contributors should understand that receiving a no and having their issue closed is polite.
But closing it immediately is definitely not polite.
Struggling with this right now at my current job as one of four lead devs tasked with implementing our design system with using a React component library.
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...
> As an open-source maintainer, you should be ecstatic — in fact, you owe a significant debt — to every single person who engages with your project.
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.
> As an open-source maintainer, you should be ecstatic every time someone engages with your project. After all, if you didn’t want those interactions, you could have kept your code to yourself!
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.
What would be an example of a well-designed, useful feature that doesn’t mesh with the philosophy of the project?
Anything that falls outside the intended scope of the project.
"What if we allowed posting GIFs to hacker news posts and comments?"
“What if we added a GUI based web browser to CURL?”
IMHO a better example is: "Can we make a teeny tiny change to CURL that would allow me to use it as a fetch engine for the GUI web browser I'm making? I can't think of anything else that might use that change, but pretty pretty please?"
This could have been a good example, except curl is not only a CLI, it builds on top of libcurl, one of the most popular libraries for doing HTTP in C. If building a web browser, it’s one of the first candidates for a fetch engine I would reach for.
Maintainers owe users absolutely nothing.
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.
> ... 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.
> No. We could not assume that contributors would engage in such discussion, in the past; nor has this been inverted today.
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.
> ... is not a great push request.
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.
> 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.
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.
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.
I strongly disagree with the premise of the article and content being reiterated here by a number of commenters.
An incredibly common pattern is a maintainer thinking they know better in an area they are inexperienced in, and rejecting change because they don't like the sound of something or are unable to see past their cultural biases.
We know this by another name - not invented here.
Common, practical areas this occurs in boring open source business CRUD applications:
- Address models aren't thought out. "Why would anyone want geocoding? What addresses don't fit the US style?"
- Phone numbers get modelled as plain strings and all of a suddenly "but changing them to be standardised is really hard"
- Company, brand, account structures rarely add URLs or links to external datasets. What possible use is a wikidata ID?
- Why would I put in vCard/CSV/Schema.org/any other import/export?
All of these areas are often ancillary to the primary purpose of whatever the application is, so get rejected out of hand.
But the use cases they enable for users - who don't use the application in isolation - are then completely blocked.
- Map, route or visualise spatial data mashed up with other datasets. Send people to remote locations without formal addresses.
- Hook up phone systems to make your system run for teams with centralisation, integrate SMS based messaging, etc.
- Join to public datasets to understand more about your customers (food safety, licencing registers, corporate entity registers, contract management systems, etc)
A typical maintainer is going to say "wait, what; my accounting system is all about finance, none of this is relevant!"; but they miss out on what users really want in many cases: interoperability or data portability.
The problem is the maintainer's frame is in their world view; and if they aren't dogfooding their project they aren't running into their users problems - how likely is it the maintainer is the BI analyst, or the low level data entry person, or from a country where QR code payment is the norm, or a million other considerations?
I used to think the same way. Why does xyz developer refuse to do this? Don't they know that feature will be of great use to people like me?
Then I made something for myself. It took a lot of time and iterations because my needs were evolving. After it was perfectly tuned for me, I put it out there so someone else can find it useful directly or indirectly.
I started receiving feature requests and changes. I accepted a few, but rejected a a lot. This is mine. I made it for myself. I didn't step out there to build something for the world, I made it for myself and it was perfect for myself. If someone wants my stuff to do things their way and not mine, they're completely free to do so, that's why I shared it.
If I put my paintings out there and the steps I took to draw it, people are free to follow those steps and recreate mine or do it in their own way. You don't demand changes on my original painting.
> A typical maintainer is going to say "wait, what; my accounting system is all about finance, none of this is relevant!"; but they miss out on what users really want in many cases: interoperability or data portability.
I think you are the one missing the point.
Users can want whatever they want to want. They're receiving, generally, et gratis et libre software which depends on someone else's time and effort. If they aren't getting what they want from the project, they are free to fork that project — and when they do, they're still getting more than they would otherwise be entitled to (i.e. the ability to start from scratch).
Further, a maintainer by definition is normally someone not charged with implementing new functionality (that's a "developer"), but simply with bugfixes.