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

81–90 of 95 posts

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

#81

Post by rikroots »

Liriel wrote: post #37

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.

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

#82

Post by jagged-chisel »

Too wrote: post #77

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.

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

#83

Post by zahlman »

tuna74 wrote: post #78
zahlman wrote: post #62

Earlier quoted context omitted.

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

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

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

#84

Post by IshKebab »

jagged-chisel wrote: post #82
Too wrote: post #77

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.

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

#85

Post by IshKebab »

sdenton4 wrote: post #71
eviks wrote: post #70

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…

You are free to fork and make whatever mess of features you wish for!

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.

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

#86

Post by saulpw »

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

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.

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

#87

Post by tuna74 »

zahlman wrote: post #83
tuna74 wrote: post #78

Earlier quoted context omitted.

"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?

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

#88

Post by Daimanta »

joshdavham wrote: post #48

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

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.

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

#89

Post by sdenton4 »

IshKebab wrote: post #85
sdenton4 wrote: post #71

Earlier quoted context omitted.

You are free to fork and make whatever mess of features you wish for!

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

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!

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

#90

Post by const_cast »

eviks wrote: post #73
sdenton4 wrote: post #71

Earlier quoted context omitted.

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.

Post reply on HN