It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fixes: little responsibility there, but security is something that can hurt a lot of people if done wrong. The use-after-free bug this was about could've been exploited in the right circumstances.
If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.
The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.
> if you write one, advertise one, you need to care about security
The word "need" there is wrong. You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. If you want those obligations, get a contract and pay some money.
What's happened here, and you seem to have fallen into this trap too, is that people believe software abstractions also automatically abstract responsibility. It's certainly not a new mistake.
What this incident seems to show (and I'm not a Rust community person, I've just been reading a lot of the threads/archives about this) is not that the framework maintainer was terrible, but instead, that what he was offering was not what people assumed it to be - some people assumed the project would behave in certain ways, and have invested their time (and presumably money) in building on top of that project, only to discover that the project does not behave how they want and now they feel burned.
I believe that being an unpaid open source maintainer (which I am, and have been, in various small ways, for a couple of decades) means having a best-effort responsibility to your community, but never at the expense of yourself. That is, however, just my belief, and nobody is obligated in any way to share it.
The ancestor post about owning dependencies, while a little more aggressive than I might have written it, is basically right. You don't abstract responsibility for code just because it came neatly packaged - if you don't have a support contract for it, you are responsible for it. That's just basic logic really.
Having said all that, I do think that deleting the repos was a poor reaction - I believe (again, just me) that a maintainer should step aside gracefully when they are no longer the best person to lead a project. If there are people to hand it off to, do that. If not, archive it and indicate that it is unmaintained.
> You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything.
I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different backgrounds. But I think it's reasonable to hold as an ideal that there is a moral responsibility to at least make sure people using your stuff understand what they are getting into. And that such a moral responsibility would require more than disclaiming liability.
I don't think these are contradictory positions. It's a bit like defensive programming in social space: one can take significant responsibility for one's own work while remaining aware that others with no legal/etc compulsion to likely will not.
> I was taught that part of being an engineer taking a moral responsibility for the safety of your creations.
almost certainly in the framework of being employed or contracted to do engineering work. go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time.
> go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time
As an engineer, your first duty is to protect the public, then your client, then your employer. You have that duty to the public regardless of whether you're being paid by a client or not, because it comes from practicing engineering, not from remuneration.
If I build something in real life, like a playground, and ask people to come use it, but then through my own negligence it falls apart and becomes a hazard, it is my fault for having created this situation in the first place.
Idk why this keeps getting tied back to paid/unpaid. I can think of many a situation where someone gets paid, and also doesn't care at all to help.
> Idk why this keeps getting tied back to paid/unpaid
i was responding to a comment about engineering ethics. engineering is a profession. engineering ethics is taught to student engineers in the context of a job, where you're getting paid. taking the (literal classroom) lessons out of context distorts them.
if you go back to your engineering ethics professors and say "gee, but what if i do this work for fun and just stick it up on a web page on the internet", they're going to look at you like you're insane, and then not know what to say.
> If I build something in real life
the last thing this thread needs is more analogies.
> if you write one, advertise one, you need to care about security
No, you don't. The author doesn't owe you a single thing unless you have a warranty saying otherwise. Most licenses explicitly say something like:
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
If you don't like the terms, don't accept the code. I don't see how that could be more clear.
Half (more probably 99% actually) of our critical infrastructure software use that wording (or an equivalent one), regardless of it is free software or proprietary software.
Yet most are maintained responsibly, if they are used for serious stuff and/or advertise in a way that suggest that kind of usage can be considered.
Everything you ever used in production is "production-ready". The bar is super low, there is no deception here.
The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages may have to include such patches themselves, effectively always being forks, never using vanilla upstream code. But this is only if you care about security a bit. If you just install from language package managers into prod, you obviously do not care about security even a little bit.
You should accept that you are responsible for all the code you run in production, whoever happened to write it. Whether you feel you are more likely to write bug free code than anyone else is your call.
I think it means you should look more closely into the contract you have with the maintainers. Either you rely on trust, like you would do if you used OpenSSL or NaCl because the creators and maintainers are known to go beyond the required minimum, or you get an official contract.
This. There is no free lunch. Either you pay for quality or assurance, or you risk you might get something rotten that wasn't obvious at first glance and you can't do anything about it. That's the difference, when you pay, you might also get something rotten, but you can do something about it. Your options are of course only constrained by what you pay.
The problem, as I see it, is that a whole generation of programmers have grown oblivious to this implicit relationship, and when that relationship is actually exercised in some way, they default to what they understand, which is paid services and products, which results in both sides feeling like they got a raw deal.
Again, in my experience there is very little correlation between how much you pay for something and how rotten it is. And I find the opposite, when you get open source software and it's rotten, you can do something about it. You can patch it locally, even if the maintainer won't accept your patches. If you have a proprietary product written badly, paying money for a support contract will not magically make it a more secure product or guarantee that they will be able to fix your issues.
> "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.".
This is a good opportunity for you to read up on the license you explicitly agreed to in order to use said software in order for you to discover that that's precisely what you agree to when you use said software.
You don't owe the maintainer anything, nor does the maintainer owe you anything at all. The project maintainers donated their work to be used freely as is, and that's the full extent of what you are entitled to.
That is why the Apache license has a responsibility disclaimer, that to the extent allowable under law the work is offered with no warranty and no guarantees, not even of correctness or usability for any particularly purpose. Words still mean things, even after we get so used to copying and pasting licenses that we forget that they mean something. If you expect a project maintainer to take responsibility, ask them to use a license where they take responsibility.
> If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.
This is less building the playground and more providing architectural plans to build the playground with common building materials. If some part is unsound, people might also be upset, but they weren't forced to build using your plans and could have reviewed the plans themselves. Where the blame lies is much more ambiguous than how you present it, IMO.
Legally, absolutely agree with you. GP's playground analogy was a particularly bad choice in that context.
Socially though - I don't see an issue with holding major projects socially responsible for egregious failure to fix security flaws. Public criticism is part of the open source model, it's the "many eyes" defense in action. Social pressure would be appropriate if Ubuntu just said "ahh, so, a worm is stealing every user's keystrokes. There's a fix for it but we won't merge it because we'd rather spend our time working on PulseAudio and systemd. If users want to use a forked version that will stop the keylogger, they are free to do so, but we make no guarantees our future changes won't break those forks."
They actually do exactly that. The only goal of Ubuntu is to provide usability. They will care about security to an extent it does not interfere with that goal.
Such as maintainers being overloaded fixing visible issues.
You want a security oriented distribution, you picked the wrong one.
I didn't mean legal responsibility here (perhaps the example was somewhat poorly chosen), but surely there's some level of responsibility here? Bugs happen, security issues happen, facts of life, but actively rejecting security patches is another level of irresponsibility.
If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.
The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.