An open-source maintainer's guide to saying “no”

<- Back

An open-source maintainer's guide to saying “no”

jlowin

Comments (73)

ChrisMarshallNY
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.
kazinator
> 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.
prymitive
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.
Liriel
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.
aDyslecticCrow
> we recently tried to nudge this behavior by requiring an issue for every PRI'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.
brian_cunnie
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.
Nevermark
> "“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...
sanarothe
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.
eviks
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 toolIndeed, 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 contribOh, so all you had to do to get off the hook was add a comment that you're not responsible?
joshdavham
> 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.
deckar01
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.
arccy
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.
jonorsi
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...
firefax
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.)
ungreased0675
What would be an example of a well-designed, useful feature that doesn’t mesh with the philosophy of the project?
palata
> 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.
dismalaf
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 changesThat'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.
einpoklum
> ... 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.
zygentoma
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!
throwaway346434
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?