Yes, this is what I don't understand - we spent decades fighting the perception that open source could never be as good as proprietary commercial software. Now that we've mostly convinced our bosses, we want to turn around and say, no actually an open source maintainer who writes buggy code, rejects patches, and takes down their project when called on it is doing exactly what he should do?
Of course he has every right to do that, but this shouldn't be (and fortunately isn't) the norm. Defending this outcome as the expected outcome just means that the bosses will quite justifiably say, suppose we use this software and I let you publish patches back, you're telling me to expect that the upstream author will take their code offline? Why should I use this software at all, let alone let you waste your time on patches? I'm gonna buy from Oracle.
Yes. If a company shuts down, who is to blame when the downloads are no longer available?
No offense, but your build process is lacking if you are affected by a project disappearing from the internet.. You should be bundling all of your libraries with your final artifact.
This is a prime example of relying on the cloud without a continuity plan.
With OSS you always have an option to keep your personal copy of the source tree, and you have an option to fork it and maintain it at your own expense. When Oracle closes and discontinues the software you rely upon, you are screwed big time.
The advantage of them is pretty theoretical since you don't really want to become responsible for someone else's code drop, but that's not any different with open source.
I think I agree, and its tricky because its really hard to pinpoint what the contract is (without sounding "entitled"), like there is with any social contract I guess. Maybe it even depends on the various cultures of the people working on the project.
I consent to let other people make demands of my OSS because I wish to make demands of their OSS because together we can build a better world than either of us could on our own - because I am consenting to be part of a community. I have security-sensitive Rust code on GitHub. I'm careful about unsafe, and I welcome people filing bugs, because I want the entire ecosystem to be good about unsafe, and so I need to do my part in that.
That statement is quite wrong. It's not a "take my ball and go home" attitude. You are not the boss of a FLOSS maintainer not are entitled to order anyone around to do your bidding. At best you're addressing a person and asking them to do you a favour. If the maintainer doesn't feel he should be bossed around by you then he has been generous enough to let you pick up where he left off and actually put in the legwork you are expecting others to do.
And in return these haters prefer to just bitch around and criticise others for not following their orders.
Exactly.
Like it or not, there are implicit social contracts if you maintain OSS software.
Yes I've read the birdseed of the various licenses.
I know this will whip up the oft-suffering maintainers and developers in here. But this is the exact kind of trope that stymies wider FOSS adoption.
The artifacts of these little meltdowns are exactly the kinds of things your upper management will cite the next time you suggest using FOSS vs. whatever vendor they're about to push down your throat.
Ignoring security conventions, and then adopting a "take my ball and go home attitude" isn't a ringing endorsement for adopting FOSS, unless it's run by a large entity.
I'm not saying the author should have to endure abuse or harassment, but consistently pushing unsafe code into a web-framework, being cavalier about trivial and widely accepted coding conventions, and dismissing patches as "boring" is exactly how you end up with NPM Ecosystem v2