Comment by eganist
5 years ago
It seems like the reason is (paraphrasing) "because I can't meet the resulting burden of support."
which is something I haven't really seen anything in the open source world manage, though that might be because I'm not much of a contributor. What happens if a utility explodes in usage and the author can no longer effectively support it as a result of being buried in overhead?
Are there any mechanisms for limiting how much of one's life an author signs away to their project (without feeling compelled to grow an operation) while still retaining an Open Source designation?
I guess I've always struggled with this, because this seems like an extremely easy problem to solve.
In this particular instance, if you think the problem is "nix users are overwhelming me" - then you have a hard and fast requirement of: if you want support fill out this form that includes OS version. If someone lists NixOS as their version you give a canned response linking them back to the Nix github page.
If the issue is just a generic: my package is so huge there is just an unending list of people asking for help. Ignore them? I get as a maintainer you may have a desire to help folks, but nobody is forcing you to. Browse github and respond to the things you feel like responding to, and ignore the rest.
I mean this with all due respect, but part of being an adult is knowing when and how to say no.
> Are there any mechanisms for limiting how much of one's life an author signs away to their project (without feeling compelled to grow an operation) while still retaining an Open Source designation?
You don't have to do anything to keep it open source. The source is already open, others can use it, fork it, etc. There is no formal obligation for you as maintainer. However as a maintainer you can feel a moral obligation for whatever reason (pride, guilt, peer pressure, etc).
It's just a small dependency for Home Assistant. I don't think the author will receive a lot of reports.
https://github.com/frenck/python-ambee
The project has zero issues right now. I think that is not the real reason.
The project is barely a week old so that might explain the lack of issues. Also Homeassistant is a big project with a big community, there are going to be a lot of people getting into edge cases. The Homeassistant project does do a lot of damage control on this because they promote standardised deployments like the Home Assistant OS. But I can't image why a NixOS repackage would add a lot more issues the author doesn't want to deal with.
I lost the blog post I learned this from, but one way to do it is whenever someone opens a PR on a project you don't want to maintain anymore, make them a maintainer!
That way, the project lives on with minimal disruption to its users.
I think that's the famous blogpost that eventually led to the event-stream malware.
>Are there any mechanisms for limiting how much of one's life an author signs away to their project (without feeling compelled to grow an operation) while still retaining an Open Source designation?
Yeah, it's called setting realistic expectations. If I release something open source, I don't owe you anything. Support, help installing, fixing bugs, spending time implementing your specific feature...
At least he’s up front honest. Most people just get shitty with you when you volunteer PRs for their project or ignore you I find.
> Are there any mechanisms for limiting how much of one's life an author signs away to their project (without feeling compelled to grow an operation) while still retaining an Open Source designation?
For distribution repacks specifically, there’s the old device of providing a configuration-time option to change the web and email addresses in the documentation (e.g. GCC does this), but I’m not sure if this will work when Google results for the error message will still point you to the upstream. There’s also the bug report checklist with “I have verified I am running the last development version”, but that comes with its own limitations.
I've observed basically 2 sustainable patterns here.
1. Some kind of forum/wiki starts providing community support and increase community contributions pick up the burden
2. Some business starts supporting this component and picks up a lot of the burden because they fix things that cause them pain in their business.
I've never seen a single person passion project be both open source and well supported for a long period of time without healthy community engagement.
It's not about popularity. Distributions often ship outdated or modified code, link it against unsupported versions of dependencies, etc. When this causes problems users will contact or blame the author of the code, instead of the distribution which broke it.
> It seems like the reason is (paraphrasing) "because I can't meet the resulting burden of support."
Exactly. He made that point a few times, but the replies don't always seem to address the issue he raises.
I think they proposed this:
> Would you be happier if we forked your upstream source to provide our own, or provided a similar Python package with an identical API that we can use as a drop-in replacement?
Wouldn’t this remove the burden of support from the author? Or it might be that I don’t understand exactly their proposal.
It would only remove the burden if users of the NixOS package know to go to the fork for support, as opposed to the upstream.
5 replies →
Sometimes when a package gets very popular other people step up to help, or take over. Other times the maintainer has a mental breakdown or just disappears.
> Sometimes when a package gets very popular other people step up to help, or take over. Other times the maintainer has a mental breakdown or just disappears.
It sounds like this author is looking for a third option, one that doesn't involve people management (1) or ghosting (2), and as far as I can tell, no mechanism for this exists that doesn't violate the current tenets of open source.
Correct. There's basically nothing in either the mechanics of open source nor the dominant open-source philosophies that says "We need to be able to throttle use of the software to provide good user experience."
A direct consequence of open source is that the good user experience burden falls to the consumer, not the producer. If someone wants control over the user experience, they want a closed-source model.