Hacker News Reader

Comment by Latty | Hacker News Reader

When they offered to fork it completely to avoid the issue and he rejected that, it really just looks bad.

I get being done with something when you've had a bad experience, but the maintainers here went to every effort to accommodate, and did so in a friendly way.

It reads like this guy wanted a fight and an excuse.

I think the correct answer is to just make the fork as proposed and use that instead, it solves the problem and removes the guy from the equation entirely. The fact he rejected it doesn't matter and he can be angry all he wants.

View on HN

From what I can see in the thread (and I'm not very familiar with the tech so I'm working off of inference here) it looks like the library fetching tool is well equipped to fetch the freshest branch from his repository directly. His responses are very minimal but it sounds like he's objecting to older versions of his library being bundled in and causing breakages on the client side - forking would potentially just make this problem worse from his point of view if his primary concern is the fact that users get out of date code - compared to the concern of code maintenance.

Daniel Stenberg creator of cURL has famously gotten a lot of weird support requests and emails over the years due to his license being shipped with an insane number of different utilities. He has handled them gracefully and with good humor from what I've seen, but not everyone is comfortable with fielding questions from random non-technical users - if that's where this dev is coming from then forking the project would probably let him dodge a lot of the responsibility. I just can't clearly tell due to how terse[1] his replies are.

1. I would say succinct here due to the fact that it lacks the negative connotations of terse, but it also implies a completeness of information which sadly isn't here. Please don't read terse as insulting or negative in any way.

It seems to me he states pretty clearly that his issue is the support burden, not some paternalism over users:

> If users experiencing issues with the ambee library in this package, they will knock on my door. And I'm not willing to support that or accept that burden. Especially as I don't see a good repacking reason in this case.

I absolutely agree that there is a legitimate reason to say "look, I can't handle the support burden from this", but users aren't going to track down the original project to make support requests if you fork it, rename it and point everything to the new one.

(Obviously you might get one or two, but anyone that motivated would probably be making their own package and run into the exact same issue anyway, at some point you can't really blame the package).

The solution is to fork the project and give it a new name & URL so users don't knock on his door - he refused that option too! Kudos to the maintainers for their curtesy - they didn't have to ask him for additional permissions over and above the current licensing agreement - they have the rights to redistribute or fork the project, Frenck is against them exercising either right.

From the profile https://github.com/frenck He describes himself as "Slightly assholic at first sight. Actually a nice guy that just likes to get stuff done." Very fitting description actually, I wouldn't argue with such a nice guy.

I don’t think there’s any obligation for support. One can even disable GitHub issues. Or let community support itself by appointing comaints.

The point about shipping old versions is rather moot in this case however, because the NixOS package was using the version required by the latest version of Home Assistant.

If anything, the Nix packaging of Home Assistant should (tm) be running on a known good working set of deps.

The nixpkgs/NixOS packaging of NixOS uses packages which work with the tests of home-assistant. We cannot respect every version pin and if package have none breaking updates we happily update them. This is especially important to get security fixes in.

Reply on news.ycombinator.com