Hacker News Reader

Comment by eganist | Hacker News Reader

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?

View on HN

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.

How would they even know to ask upstream for support, rather than the fork? If you use package bar and have a problem, you would have to do a lot of digging to even find original progject foo and ask them for help (which wouldn't even make sense since it's a separate thing)

I guess that depends on how users go about finding projects on github to file issues. If, for example, the user has an issue with this NixOS package (or debian package/any other repackaged example), and they start by just searching "python ambee github" or "Home Assistant ambee github" (seems like a reasonable first attempt to me) they will likely find the upstream near the top of the results.

Now, some users will perform due diligence and maybe find the NixOS issue referenced in OP and look elsewhere, but many will find the project and immediately file an issue there in the upstream, leading to the author's main concern of "I don't have time to support NixOS issues".

Ah I think you might be right with this case where someone will just google that. I am not doing that but prefer to go to the package manager list find there there the project URL.

I was thinking that people will do the same or else how will they know if the github repository returned from search results is truly the one installed?

That's fair; I was assuming that the fork would be renamed substantially enough to obscure the origin.

I am not using NixOS but in general every package manager links to the project homepage let’s say (or name of the project which for example in a GitHub fork is clearly different than the original) which in this case would be the fork.

So for example if this will be the case with a package I use I will report the bug to the fork because the package manager showed me their link.

I will not search for name-like projects or the original one and report there if a fork was distributed to me.

This is why I am confused why a fork is not solving the burden of possible bug reports. Also the fork assumes its own maintenance this is the purpose of the fork.

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.

Reply on news.ycombinator.com