Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jlowin.dev

Post reply on HN
Print view View original

21–30 of 95 posts

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

#21

Post by StilesCrisis »

Aurornis wrote: post #12
zygentoma wrote: post #2

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

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.

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

#22

Post by jaggederest »

deckar01 wrote: post #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.

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.

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

#23

Post by serial_dev »

aDyslecticCrow wrote: post #5

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

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.

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

#24

Post by aDyslecticCrow »

Aurornis wrote: post #15
aDyslecticCrow wrote: post #5

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

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.

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

#25

Post by Aurornis »

giancarlostoro wrote: post #20
Aurornis wrote: post #15

Earlier quoted context omitted.

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.

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.

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

#26

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

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

#27

Post by aDyslecticCrow »

serial_dev wrote: post #23
aDyslecticCrow wrote: post #5

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

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

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.

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

#28

Post by 1718627440 »

aDyslecticCrow wrote: post #5

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

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.

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

#29

Post by johnisgood »

aDyslecticCrow wrote: post #10
zygentoma wrote: post #2

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

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