Live data from Hacker News

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

jlowin.dev

11–20 of 95 posts

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

#11

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…

> 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.

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

#12

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…

> 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.

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

#13
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.

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

#14
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.

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

#15

> 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 agre…

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.

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

#16
> "“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...

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

#17

> ... 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…

> 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.

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

#18

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…

Say you're making a music player and someone opens a PR to add PDF support. Suppose the implementation is immaculate.

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

#19

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…

> 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.

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

#20

> 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 agre…

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 c…

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.
Post reply on HN