Hacker News Reader

Comment by elmerfud | Hacker News Reader

Seems like an author that doesn't understand the spirit of FOSS. The nixos team was clearly allowed to use it and include it when asking for some technical merits as to why, and even offering many alternative options to appease the author the author seemed to just childishly stamp their feet and say, "because I said so". Eventually the author took the position of "taking my ball and going home". Why is a person like this even engaged in FOSS if they don't have a desire to share or even engage in a reasoned discussion?

View on HN

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.

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.

IMO, it's worse than that: frenk does seem to understand the history of FOSS distribution. Most Linux distributions included packaged sources for the software. This is no different. They did not point back to the original repo, not to the source control repo. They had rmps or the equivalent.

The existence of pypi does not mean everyone is forced to link back to it and use it has their own source repo. Frenk insistance that everyone uses pypi and only pypi is just a tantrum not based on reality.

People could use his package from pypi and still have an outdated version. People could use a pinned version from pypi and they would always get an outdated version. People could be using an installed software from long ago and thus have an outdated version.

Thus his concerns are not magically solved by not packaging sources.

Plus, he has an attitude problem, is passive-aggressive, is closed minded and won't discuss. May he have fun with his newly weirdly licensed package,

He strikes me as someone who has been burnt by the packaging issues that have been around in the ecosystem for years.

You're right that the existence of PyPI doesn't mean everyone is forced to link back to it, but damn it would make a lot of stuff a hell of a lot easier if it did. I've been bitten by Debian packages being years out of date, I've seen packages modified by maintainers in ways that are poorly documented and useful for Debian users rather than Python ecosystem participants.

I've managed to work my way out of that now and would never go back to that world if I can help it as the trade of reduced engineering quality (along various axes) for increased "freedom" is not one that I value (personally, or at work). So I can really empathise with this persons position.

I think they handled it poorly, communicated poorly, came to the wrong conclusions, and left the discussion in a bad place, but all of that just screams frustration to me, and I can understand where it comes from.

> I've been bitten by Debian packages being years out of date

I've been bitten far harder by pypi packages trying to download random opaque binaries, miscompiling their own binaries, vendoring and failing to update large packages, having impossible-to-satisfy dependency requirements (relying on pip only ever making a half-assed attempt at satisfying them) and generally making strange assumptions about the target system.

That is indeed also a problem! Essentially it comes down to wrapping sets of dependency management. Thankfully the "engineering" side of Python is fairly good at this in my experience, but I have seen the "data science" side of Python do some of this.

The whole point of nix is to decrease the chances of being burnt by dependency management. This is why packages don't rely on _just installing packages via pip_.

Some people release something as FOSS but don't understand what that means. We had a developer we worked with at PortableApps.com release his software under a FOSS license. He requested we package it portably in our format and release it. His users and ours were happy.

Fast forward 3 years and a bug impacted a user's data in the portable package. The developer became increasingly irate even after it was fixed and demanded we stop publishing it. To avoid confusion, I even renamed the portable package to a new app name, forking it. That made him even more angry and he started publicly claiming we were "stealing" his work, despite following the license, maintaining his copyrights, and directing users to donate to his donation page to support development. He put up banners on his website and documentation pages about the "theft". As his emails to me went downhill, I got the feeling he might poison the code itself upstream to mess with the fork. I didn't want to deal with that just for one small app, so I abandoned it.

So, yes, this does happen. And some people thing "because I said so" is a valid position.

Fascinating story. I think it's hard to anticipate consequences of actions, for some harder than others.

Yeah, they went above and beyond trying to mollify the original author, in my opinion.

I would have forked his repo, and said, "We'll be happy not to include any of your code. We'll just use this forked repo which is now our code."

I agree. This is kind of bizarre behavior from someone who is such an important contributor to Home Assistant, a large scale open source platform. I can’t imagine most of the leaders in Home Assistant would share this attitude, but maybe I’m wrong.

Unfortunately, the founder of Home Assistant has acted similarly too. When NixOS maintainers raised concerns, he accused them of having "no intention to contribute anything positively." This was despite NixOS maintainers' best efforts to engage in a civil discussion.

To make matters worse, he even used the fact that the NixOS discussion was temporarily locked down due to high tensions and accused NixOS maintainers of attempting to shift the maintenance burden on Home Assistant, which is hardly what all this is about.

https://community.home-assistant.io/t/consider-to-avoid-addi...

It seems like HA has its own plugin distribution model, whereas NixOS is trying to work around that to provide reproducible builds.

Aside from how this issue has been handled, poorly, that seems like a reasonable technical decision for HA to make, particularly given that their main use case is semi-technical user installing on a Raspberry Pi, and in that case is it something they should be forced to support? A fork seems like the right option there?

Nobody is actually asking them to support anything. And they “refused” a fork (which is pointless as nothing stops one from happening). They seem to want to hold some control over their software that is against the usual rules of the game for OSS.

This and the OP seem to suggest there is something else going on behind the scenes than just abrasive personalities. Do the people who work on Home Assistant have some issue with NixOS?

It's sad to know that Home Assistant is such a project. I should consider alternatives. Partially I can grasp them, but the attitude in reply is really looks bad.

> I can’t imagine most of the leaders in Home Assistant would share this attitude, but maybe I’m wrong.

I'm afraid they do[1] (that's from the project founder, and current CEO of the company supporting HA development).

https://community.home-assistant.io/t/consider-to-avoid-addi...

oh gosh. i am afraid i need to get rid of HA now. Whats that attitude about for gods sake?

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?

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.

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

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.

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.

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

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.

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?

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.

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

He doesn’t understand the letter of OSS either. Limiting who can distribute a project means it no longer meets the Open Source Definition and is therefore not OSS.

No, he acknowledges explicitly early in the thread that the license allows the code to be redistributed with or without his approval.

And later he states "Unfortunately, you are wrong there. I will explicitly and publicly list parties that are allowed distribution in the license and allow for requesting distribution requests."

The "fine article" always contains the correct bits.

In that context he was talking about for future releases of the project, if the others in that thread forked the project right this minute, it would still be MIT.

Yes this is precisely the section I meant.

He later says he will relicense it so only specific projects can use his code. I think that would likely invalidate their own licenses, so I'm not sure how that would work.

Not retroactively. They can stay on the old version forever / maintain the new fork but any new code will be under the new license.

I think there’s some emotional nuance here. After a certain point he basically said all of his technical justification and the request does boil down to “because I said so and I’m the author.” The Nix maintainers explicitly do not want to respect the author’s wishes (which is fine) but that makes the whole thing turn adversarial because “okay we won’t include it” wasn’t even something the maintainers considered for even a second. It was pretty level headed discussion until it was clear that their only motivation was getting to yes or enough justification to ignore him.

they have good reason to not not include it.

In totally agree but in the case where the Nix maintainers don’t think the author’s reasons are good enough (which happened) that’s where we’re left with “because I said so and I control the license.”

I would agree that the author's reasons aren't good enough, because when they proposed a solution that would mitigate the reason, he rejected it. That implies that there's far more to it than the reason given.

> It was pretty level headed discussion until it was clear that their only motivation was getting to yes or enough justification to ignore him.

No, they offered solutions and only gave up when the author refused to provide any actual objection other than that he didn't like it. "Doesn't want people to file bug reports because downstream broke something" is a reasonable objection, but it's also a fixable problem. "The only thing that will ever make me happy is you completely removing this package from your distro" is neither.

The only solution Franck gave is to not re-package for any emotional reason he had. The Nix developers gave their reasons why they need to re-package. Franck just ignored everything and gave no reasons to justify his request.

The broader issue here, again, is that maintaining FOSS software seems to be becoming a shittier and shittier proposition.

I can fully empathize with him that he doesn't want some other project shipping an old an broken version of his project even though it is allowed by the license.

FOSS is really quite ill at this point. If you don't recognize what is happening, you're going to see this happening more. Continuing to blame maintainers that are burned out and frustrated and broke won't fix the systemic issues.

Just because you are legally allowed to do so doesn’t mean that you should. Hopefully you have a similar stance towards Amazon’s behavior in the OSS community.

If that's the case then it's no longer FOSS.

It's not an issue of legally allowed. It's the very spirit of the community that allows for this. The FOSS community has worked very hard to create a system where permission isn't needed because it's already there, baked into the system. So while yes, some large corporations abuse this, I also don't consider Amazon to be part of the FOSS community, and I definitely consider NixOS to be a part of the FOSS community. To declare that you will go so far as changing the license to prohibit certain persons or projects from using your software is an affront to the FOSS community itself. If the whole FOSS community degraded into "It's free for everyone except you and you and you because I don't like you or maybe you're gonna make my life difficult" then we would have no FOSS at all.

I can understand the author's concern, and NixOS offered to maintain it's own fork to mitigate it, and the author rejected the idea. That tells me that it was more of a temper-tantrum stemming from some other deeper issue than just a concern about support.

Except the part you are including a company to "prove" your point when NixOS is a FOSS project and they give their part back to the community.

Reading through all the comments that was my take as well.

None of the alternatives were something like "rename, so it isn't attached to them any more". I understand their issues, at present they can push new releases via pip, with this many nix users could have very out of date packages.

If I understand you, they offered that very thing in https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86... and it first wasn't answered, and then was dismissed with "This was already answered. Please don't repack my source in this repository was my request. I don't see how your suggestion is changing that."

That response was what confused me as to the problem with packaging the library, as it seems like that would fix the inundated-with-support-requests issue.

I missed that bit, thanks. I find it weird they seemed to suggest they would also consider reimplementing the whole package, with the same API.

Legally yes they are allowed and can ignore the author as they like.

They can also act as a bigger person and say "Sure, we understand, respect your wish and will find an alternative."

It's being added as a dependency to home assistant, a popular package, so they are pretty much between a rock and a hard place. Ultimately, if the author of the code doesn't want it redistributed by distributions, I assume home assistant will have to remove it from upstream. It might be good for someone to raise the flag with home assistant since this is apparently becoming a point of contention with two different distros now.

It appear this has already been done, and the founder of home assistant seems to be supporting the developer. [0]

I'm starting to get the feeling that home automation might be somewhat hostile to repackaging.

[0] https://community.home-assistant.io/t/consider-to-avoid-addi...

This is unfortunate, but I suppose it joins the growing list of open source things that I have to avoid because I don't want to support behavior that's hostile/antithetical to the health of the open source ecosystem. It's a damn shame, but nothing new.

This is a subdependency of a larger project (homeassistant) so doing so would involve nix maintaining an entirely separate fork of homeassistant, which is a completely unviable ask.

The author's conduct in that thread is certainly not what I'd call "acting as the bigger person".

If they were serious about their request they'd be looking into having the homeassistant guys removing it, or PRing to homeassistant. Or changing the license to make it closed source.

They appear to have done that last bit after getting nowhere with the Nix maintainers. Does that prove their seriousness?

Which last bit?

From looking at the ambee repo the license appears to still be MIT; can't see any relicensing anywhere.

(And actually, as has been mentioned elsewhere, it seems like it wouldn't be possible for him to relicense in reality as the package is explicitly developed for homeassistant and as such would need to comply with homeassistant's licensing to be included as a dependency of it)

What you're describing would be to comply with what are effectively shadow terms in an apparent open source license, which is not something that should be tolerated as it makes a farce of the whole purpose of licenses.

He understands it perfectly. That's why he asked nicely at first. Nixos just "request denied" him after rounds of requests and discussion. With that he's roiled up to change the license to exclude Nixos.

He just doesn't want the extra work to support another distro which would include an outdated version of his package.

It's not because he asks nicely that people have to agree or accept. This is literally the nice guy meme.

If you make a license FOSS then people are free to do what they want. Just don't make it FOSS if you don't want.

If you look at his bio on github, it's the epitome of the nice-guy meme.

"Slightly assholic at first sight Actually a nice guy that just likes to get stuff done."

If you have to warn people that you're an asshole and then try to convince people that you're actually a nice guy, then you're probably not a nice guy.

I have no specific opinions on the author really, but:

  > Seems like an author that doesn't understand the spirit of FOSS.

The author states he understands the licensing and the project's rights to use his software earlier in the thread. He was simply making a request.

  > Why is a person like this even engaged in FOSS if they don't have a desire to share or even engage in a reasoned discussion?

Again, he stated his reasons in the thread. He didn't want to have to potentially support their repackaged and/or old versions of his software. His software being OSS did not give up his right to make nuanced requests.

That said, the thread ended with something to the effect of "well, we can include instructions on how to install his software" -- an option which wasn't presented until the end, yet it fully complies with his request.

Reply on news.ycombinator.com