I saw an issue today on a fairly popular project (better-auth, see the link to the issue attached). No repro, no context, just a wall of caps and profanity ending in “fuck you”. The maintainers ship this for free. People run production businesses on top of it, for free. And the thanks is someone raging into a text box because a minor bump cost them an afternoon.
I maintain and contribute to a few projects myself, so this hits a nerve a bit. Something people don’t see from the outside: it’s not enough to know how to build the thing. You also have to know how to defuse a thread where someone’s insulting you and not fire back, even though most of us aren’t paid for any of it, let alone the work of staying civil while being told to get fucked.
I’m not pretending breaking changes don’t cause real pain (that’s what the issue is about). But I keep coming back to a boundary question: if you’re not paying for it, do you actually get to demand anything? (Obviously yes, but we still need some boundaries)
This guy has a public identity and even has some very starred repos. I wonder if he gave so much as a thought regarding his whole company seeing his disgusting attitude.
this is the Next.JS dev
I was surprised to find out that he actually stuck with his original issue text and defended it later on. I understand being frustrated and all, but an apology about the tone was definitely in order.
Imagine the chaos if all the FOSS maintainers collectively went on strike until their demands were met. They could demand so, so much despite being volunteers.
I’m convinced the world’s top companies are all secretly built on FOSS projects, so might be able to scrape together a few billions from it.
They would sooner enslave the maintainers
I’m not pretending breaking changes don’t cause real pain (that’s what the issue is about). But I keep coming back to a boundary question: if you’re not paying for it, do you actually get to demand anything? (Obviously yes, but we still need some boundaries)
And if the issue makes you lose face, it’s clear you’ve been dealing with it for quite some time and should’ve learned to lock your dependencies and test after updates. Unacceptable.
I don’t think it’s valid to simultaneously present open-source as a legitimate alternative for paid software, while also saying you can’t have expectations of the software or trust its guarantees (ie. semver) because it’s just a volunteer project. If you’re presenting your OSS in the serious space of choices for its niche, it will (and should be!) held to a high standard. If it can’t be, then don’t present it as a real alternative. I’ve noticed this (mostly-unintentional) conflation between serious OSS competitors and hobby projects in almost every discussion on this topic I’ve seen.
The thing that annoys me is that one of the big strengths of open source is that anyone can help make it better, which SHOULD allow it to be a legitimate alternative provided it’s popular enough.
But for some reason both maintainers and users/contributors tend to find it really fucking difficult to be sensible about things, with users/contributors being needlessly rude (among other problems) and maintainers not giving a shit about the quality of their projects.Like… it’s totally understandable and okay for projects to be flawed since the people making it are mere mortal humans, but we should neither be responding to this with “ugh write better code you lazy scrub!” nor “fuck you i write this for free you don’t get to demand anything”.
We should respond to it with “hey {xyz} could use some improvement” and “hm yeah that’s true, i can’t be arsed to implement it but anyone who wants to open a PR will carry the favour of the heavens”.
It’s not rocket science.Yup
Yeah, I started a major project 20 years that got a lot of attention.
I gave it up after a few months because whilst there was a lot of support, you have to constantly fight against a holes who will tell you how much you suck compared to other options, or how unnecessary you are
I say thanks to open source maintainers all the time! 😄
Anyway, while a wall of profanity and fuck you is clearly not ok, I do disagree with this:
The maintainers ship this for free. People run production businesses on top of it, for free.
Just because you offer something for free doesn’t absolve you of all moral responsibility. I’m not saying you have a lot of responsibility, but “it’s free so you can’t complain!” is pure nonsense.
Go and give some kids free poisoned sweets and see how far that gets you.
From the license:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
An open source dev is owed nothing and owes nothing.
By stating otherwise, you are trying to say that the person who releases something, on their own time and expense for free and probably fun, has an obligation to conduct themselves in a manner you think is best.
But… They don’t. This isn’t even really a debate worth having, because there’s nothing to debate. You’re just wrong.
I said morally, not legally.
And you’re still wrong. They don’t owe anything to anyone, legally or morally.
I disagree. If you make a project, put it out there for.people to use, and it becomes popular, you have some moral obligation not to dick over people who have come to depend on you. I’m not saying you have a moral obligation to e.g. provide free support forever or work weekends or whatever.
You can think otherwise but IMO that makes you a bit of a dick.
What arbitrary line of popularity suddenly requires me to support every use-case, by never breaking something in a project nobody is paying me to build?
10 people? 100? 100,000?
The answer is: none because the premise is false.
FOSS maintainers owe you NOTHING. Nada. Zip. That includes a working copy of the software, and you agreed to that stipulation in the license. That’s what “no warranty of fitness any purpose” means.
That includes not owing you any specific method of project “governance” or versioning scheme, it includes not owing you releases, ever.
Also, what counts as “dicking over” a user? That sounds arbitrary too.
- Refusing to answer their questions?
- Removing a feature they liked because it was a nightmare to maintain?
- Leaving a bug in place because trying to fix it sounds unfun?
- Introducing a bug because you didn’t realize there was an interaction between two features?
- Deciding that tests are no fun, and deleting all of them, increasing the likelihood of bugs?
- Deciding that documentation is out of date, too much of a pain to keep updating, and removing it wholesale to avoid confusion because it’s inaccurate anyway?
FOSS maintainers have no obligations to you. None. No arbitrary line of popularity changes that.
I build my open source projects for fun and for free. Your decision to use what my fun produces doesn’t suddenly require me to have my fun in a specific way. It doesn’t obligate me to ensure the output of my fun never breaks your production environment.
What arbitrary line of popularity suddenly requires me to support every use-case, by never breaking something in a project nobody is paying me to build?
Not what I said at all.
FOSS maintainers owe you NOTHING. Nada. Zip.
Oh so it’s either “nothing. Nada. Zip.” or “support every use-case”. Nice false dichotomy you’ve got there.
I may have been hyperbolic, but my point is that the dichotomy is between:
- Any obligations
- No obligations
FOSS maintainers have no obligations at all. Moral or otherwise.
Go and give some kids free poisoned sweets and see how far that gets you.
How is that even remotely comparable
It wasn’t meant to be comparable. It was meant to be a simple counter example to disprove “free => no obligations”.
Go and give some kids free poisoned sweets and see how far that gets you.
I can’t think of a single analogous action in providing software for use for free aside from injecting malware, which I’m pretty sure is criminal? No?
I wouldn’t call “not intentionally being malicious” a responsibility anymore than following any laws is a real responsibility… responsibility here implies an active duty to do something, not really to not commit crimes. I really can’t think of any active responsibility any dev has for software they’ve put out there. It could literally cause harm to some hardware and they still really wouldn’t have a responsibility for anything as long as it isn’t (in fact that’s for good reason a common disclaimer for things that tweak hardware).
What did you have in mind as responsibilities a dev has?
See my other comment.
“Not doing an illegal thing” isn’t really an obligation in a sense anyone would understand that statement, but OK.
if you’re not paying for it, do you actually get to demand anything? (Obviously yes, but we still need some boundaries)
Wrong!! Obviously no. You’re not entitled to demand anything. You can ask politely.
You don’t like the project? Go and use another alternative.
There is no alternative? Go and write your own.
You don’t have the skills? Go and pay somebody with the skills. And if you want the most skilled for the job, probably is the person maintaining that project that you don’t like but still keep using for free.
Not so long ago someone here argued with me that open source devs have a lot of responsibilities and if they can’t make their project easy to contribute they should be banned from open source community (no idea what it would look like). They got upvotes too. Nice to see some sanity here again.
Having been on the maintainer side of a popular project once before, I’ve pretty much just taken the mindset of “if you owe them nothing, then they owe you nothing”. Basically, pay them, or stop making demands (though suggestions and bug reports are usually welcome by maintainers).
Incidentally, this is why I didn’t accept donations for that project (though I have nothing against donations in general, of course). I didn’t want to even feel a sense of responsibility to maintain a project I knew I’d eventually burn out from.
I wouldn’t take it as far as paying allows demands. If I decided to pick up some litter in my way in public and some sees it. Just because they shoves a $20 in my face, doesn’t mean they can demand and expect I’ll pick up all the other trash around. There would need to be contract (even just Social) negotiations at the least!
I wouldn’t take it as far as paying allows demands.
Neither would I.
Paying implies exchanging money for something the other party is selling, and would require the other party (the maintainer) to sell it. Shoving $20 in someone’s face is a donation, not a payment.
I just refused donations for myself. I would never claim a donation gives someone any special right to demand something.
When that whole rsync stuff came out, I remember arguing with someone about this too.
Like, I’m not defending AI or the use thereof. I also don’t know the full details of that situation, or how much AI the dev actually used, or for what. That’s not the subject of the argument I was making.
Basically, I was saying that it’s a FOSS project and the guy has been maintaining it more or less by himself for decades at this point, and it’s become a critical infrastructure that an enormous number of projects (both professional and hobbyist) rely on.
I said if these people didn’t like how the guy was maintaining his project (for free, and thanklessly at that), then they could either contribute, fork it, or make their own.
A couple people in that thread were doubling down about how the dev somehow apparently has some sort of responsibility or duty or obligation to run his project the way they think he should. They just didn’t seem to get the fact that he’s doing it for free, it’s his own project, and it’s not his fault that the majority of linux users decided to make it an indispensable part of their backup processes.
But these people said everything from “you can’t just fork a major project like this, that’s an enormous task with xyz responsibilities” (as if that doesn’t strengthen the point that it is an enormous task which this guy is choosing to do for free) to “if so much critical infrastructure depends on it, then it does oblige the developer to maintain it in such-and-such a way.”
In the end, I didn’t get through to them. Not that I expected to, but sometimes arguing with these people is more for the lurkers who will read the chain rather than for the people I’m actually arguing with…
Contribute, fork it, or make their own
Except this is a bit silly. So, for example, rsync does have an alternative already on the market; it’s called openrsync, but I tried to just “s/rsync/openrsync/“ (in a script) and it is not a 1:1 replacement. And it’s not even close.
Contributing requires the project maintainer to not be a dick, but with rsync, people have probably been “oh, he’s been doing so good as they are.”
I might fork rsync (to version freeze) before the AI adds, but it complicates system administration. System administration is easiest using the package management systems. I, personally, believe there are like four Linux versions: pacman, dnf/yum, aptitude, and source.
Maybe it’s silly to make your own fork, but unless someone else does it and you opt for their alternative, those are your options.
Complaining about how the dev decides to maintain his own project that he does for free is not one of them.
He’s been maintaining critical infrastructure for decades. Maybe if you make him a billionaire then he’ll have to run his project however you demand, but as long as this is just a passion project of his, it’s no one else’s business. They can submit bug reports, they can contribute PRs, but cussing him out because you don’t like how he manages his own project is just dumb.
He may be an asshole, but he’s not wrong.
No, he is wrong. He blindly assumed that the project followed semver, and kept insisting that it did despite the obvious evidence to the contrary. That’s entirely on him
It turns out that he is an asshole, he is wrong.
No, they are wrong because they should be pinning a specific version of their dependencies, and then reading patch notes before upgrading. This chud lost face because they didn’t pin their dependencies. Their project was broken for an afternoon, and they were mad that their own ineptitude was put in the spotlight. They flamed a maintainer because they couldn’t be bothered to RTFM before they upgraded.
Pin version.
Problem solved.
The part that irkes me most about this, is he’s right.
The complaint is valid, non-breaking production changes should be the norm, not the expected, 100%. And yes, I maintain upstream work, too.
Doesn’t forgive them being a dick. Permaban in my book, I just hate that he’s right.
Are they right though? Not every project follows semver, it’s on consumers to pay attention. Especially if it’s a recurring problem: this problem (assuming the project follows semver) hould happen once at most.
Love it how everybody’s mocking this entitled clown.
Naah, I don’t really demand anything if the author breaks something on update. I just asked if the breaking changes are intentional and if there’s a workaround. Failing that, I revert and look for other libraries or roll my own. To me Open Source is always about making something you love without any obligation. Not even to follow semver.
That view of open source only applies for non-profits and hobbyists, releasing code that solves their problems altruistically.
Corporations, startups, and VC’s abuse open source by using it as a means to gain goodwill and trust until they are funded or profitable, then they perform a bait and switch or other parasitic practices; they deserve the hate, and can eat shit and die.
Also, if you’re not gonna follow semver don’t use semver. Just use YYYY-MM-DD or whatever. Quite simple really.
Regarding this project; anyone who chooses to use new (thus untrustworthy) foss libraries in prod without version pinning and thorough integration testing is an idiot.
V1.2.3 is not unique to semver tho. So it could really be anything like linux 7.1.2. To be fair, linux does predate semver by a long time. But the point is that not every software with #.#.# needs to be semver. And I think better-auth, from the issue linked, has stated that they don’t yet follow semver somewhere in their docs.
If the versioning has no meaning, or conflicts with a widely held standard, why not switch to datever? Then we at least know how out of date we are…
I ask the inverse. Why should you demand that every project that uses x.y.z versioning be a semver? A widely held standard only applies if you actually want to follow it in the first place. You know HTTP spec didn’t mention anything about the body in GET requests and so almost every web server just ignores body on GET? Yeah, some software decided to use that. And guess what? That software? It was Elasticsearch. People are free to do whatever they want with their software. If they decided to publish something non standard and you decided to use it, you can ask them nicely to follow standard, or make an adapter for it.
Yeah, choosing to establish the semver social contract and then break it is not great
But they never established a “semver social contract”. You can’t assume that project follows semver just because it has an x.y.z version number; semver is not the only versioning scheme, it’s just a very popular one
Why would you use the syntax of the most widely adopted versioning schema in software engineering, then not follow it?
This isn’t linux; it’s a 2 year old project ffs. That’s just ignorance or incompetence, but poor design decisions are expected from an AI slop project. Unless you can enlighten us on the logic of the chosen schema, you shouldn’t defend them.
This is the first time I’m hearing about semver contract. I always assumed the x.y.z versioning was pridever, which was the first definition I found. And that says nothing about backwards compatibility.
So it might as well be the case of the XKCD.
Why not fire back? It’s not like you can really get fired from an open source project.
Complains about improper release management.
Apparently not using lockfiles for prod.
This is not a serious developer.
What makes you think it’s a lockfile issue? If they sighted a patch upgrade then updated the lockfiles but then noticed a breaking change, then lockfiles are irrelevant.
If it’s actually like they claim, I understand the frustration. (Not that I know this project in particular or how it gets integrated.) Without clear versioning and/or changelogs/release notes managing upgrades is cumbersome, sometimes impossible.
In some cases I’ve had to ask for clarification in PRs because release notes were not clear, PR was not clear, and resolved ticket was also not clear on the thing or solution.
Apparently they had issues before, so maybe they could have expected “patch may not be patch-only”.
It’s the combination of “breaking changes on minor releases” and “disregard for … production environments”.
Can you stop releasing breaking changes on minor releases? It’s absolutely infuriating that you guys keep doing this over and over again with complete disregard for people downstream using this package in production environments.
By the time you’re deploying to production, you should already have your versions locked in, so semver does not factor into resolving dependencies for production deployments at all.
I can understand it being annoying for development processes. Like, if you have a dependabot-style tool that tests against new releases and submits PRs for them, that can definitely be a waste of time and attention if it fails frequently on patch-level updates.
But in between that “eager testing” step and a production rollout, there needs to be a moment where a human reviews the updates and signs off on updating the lockfile.
And at that moment, reading the changelog, it really doesn’t matter if it says “1.0.1: breaking changes!” or “2.0.0: breaking changes!”, because you need to be looking at the substance of the update.
The only way semver violations burn you in a prod env is if you’re YOLOing new versions out there, either by forgoing a lockfile or by merging lockfile updates without review.
The reasonableness of your assertion kind of comes down to environment. Say NPM where people go nuts with dependencies (and is the subject here). If for instance there is a security issue in a package used by the package in question and you must update the package in question to get the package with the security warning updated, then you must update the package in question, and there is every expectation in the NPM ecosystem that semver is followed.
That said, being rude to the developers is immature and counterproductive, and moving to a different solution if a package repeatedly causes problems would be the sane course of action.
I mean, I told a paying customer to get fucked yesterday over demands so you can definitely say it to a non-paying person.
If he was a paying customer of mine i would void the purchase and tell him to go fuck himself
