Comment by geofft
5 years ago
It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
It's not very hard to say, this is a project for my own technical interest, I don't intend to follow Rust norms about use of unsafe, and you shouldn't rely on it, but here's the code if anyone wants to look. That's fine! (And I do think we need to be better about making it common to do that. GitHub has no good tooling for such a repo, for instance: you can't disable pull requests unless you archive the project or make it private.)
But that's not what Actix's docs say. See https://actix.rs/docs/ for instance: there's nothing to the effect that you shouldn't use or rely on it, and everything to the effect that you should. (In case that page gets taken down, it starts, "Actix is your door to developing web services with Rust and this documentation is going to guide you.") On https://actix.rs/community/ it says you should report bugs to GitHub, implying that bug reports are in fact welcome, and there isn't a single statement that the project goals prioritize the author's technical excitement over correct code.
Again, there's nothing wrong with wanting to prefer your technical excitement over having bug-free code. Just be clear about it.
> if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
This reminds me of an incident years ago. I was on a city bus, very full of people, and we were just about to leave a stop. There's a woman maybe 150 feet away running towards the bus. The driver sees her running and re-opens the door, waiting. Inconvenience to all of us on the bus, but hey, she's running.
The woman, seeing the bus has waited for her, stops running and starts slowly walking instead.
Driver sighs, closes the door, drives away.
I'm not sure what the moral lesson I take from it is, but mainly "if I go out of my way to help you, don't take advantage of my generosity". Maybe that partially applies to situations like this one. Or maybe just "don't annoy transit operators". That's a good one too.
I think that's fair - especially the part about not taking advantage of generosity. But I don't think that's what happened here. Someone reported a soundness bug. Someone else (IIRC) posted a patch fixing it by switching from a custom Cell type to the standard library one, which is what the maintainer called uncreative and boring. Fixing a soundness bug is a perfectly reasonable, non-advantage-taking thing to do in a PR.
(I agree that in general there is a problem with open-source users feeling entitled to support/features and maintainers not feeling comfortable saying no, but that doesn't seem to be the type of incident that triggered this, and more generally it is difficult for me to see how a patch would count as that - at least a patch that isn't "please maintain this pile of new code," which this one wasn't.)
> Someone reported a soundness bug.
Your description starts off on the wrong foot because a) there was no bug, and b) although the library used unsafe code extensively, its maintainer argued that was not a problem and that didn't meant the code was unsafe.
So in the end we only have issues being reported by opinionated users trying to force their personal opinions on a project maintainer, who due to the content and tone of said issue reporters decided not to accept the reports or patches. Once some bad apples in the community started to increase the unpleasantness of the whole experience, the maintainer said enough is enough.
In this case, the maintainer made an active and conscious decision to do something that did nothing but hurt everyone using the project. There are no passengers who might benefit here, sadly.
Since this seems to be a constant point in this thread but I don't see it: How exactly did that person hurt anybody? They maintained this project for 3(?) years and the code is readily available elsewhere on github now. If there's really that many people being inconvenienced by that, surely somebody else will take over that fork instead.
5 replies →
I think you are confused. The maintainer made an active and conscious decision to protect himself. That's clearly not "nothing", and a perfectly legitimate reason.
11 replies →
Yeah, people who aren't in perfect running form don't deserve help.
Well put!
He held the door open for a lot of people. Some people spit at him as they walked through. He doesn't want to hold the door open any more, he's done it enough. He didn't sign up to be a doorman for life.
This idea that replacing unsafe code with safe code is "spitting" is unhealthy in the extreme.
I don't understand why the author felt so defensive about accepting packages. As far as I can tell, they've always had this attitude.
Why even make a project open source if you don't want to consider patches? The whole idea is that even if you think a thing is boring, someone else may not and they'll do that work for the community.
Weirdly, this is now some kind of grave affront to the maintainer who appears to take the idea that a compiler check could be added to their general framework as an insult.
> Why even make a project open source if you don't want to consider patches? The whole idea is that even if you think a thing is boring, someone else may not and they'll do that work for the community.
This is a false dilemma - making a project open source can have plenty of motivations besides "I want to be a project manager for free!". Some other motivations:
* Someone may find this useful even if I don't ever touch it again.
* This could show others an example of a different way to solve a problem.
* This is cool, look what I did!
* Github is a free host, and there's no reason to keep this private.
* I just need some code I wrote in a public place for hiring managers to peruse.
1 reply →
I know why I might.
Here's an analogy for you. When you pour yourself a glass of pop, and you over-pour - do you then pour the drink back into the bottle?
I know some people that would return that drink to the bottle, and some that would rather pour that little bit into the sink. Those that would "backwash" believe that the bottle will be fine - sure, you've maybe transferred a little bacteria in, but it probably won't cause any problems. Those that throw it away believe that the hygiene of the bottle - even from a clean glass - would otherwise be compromised.
So if you come to my battle-tested codebase, and tell me "Hey, I've made you code better. It now has a theoretical metric of cleanness, instead of your proven metric of cleanness" - you may well have just introduced a bug. I now need to test your code, ensure it meets my real-world standards of cleanness. And maybe it does! Maybe your code has fixed a glacially-slow memory leak, but I won't see that. Maybe your code has introduced a complex interaction that none of my examples exploit, but other people's examples blow up because of it.
Maybe the bottle of pop will be fine. Maybe in a couple of days time, when I have guests over, the unhealthy layer of scum floating in my mother-in-law's glass will make me look bad.
Either way, it's a lot of work, and little certainty, and only theoretical benefit - vs no work, and full certainty in the real-world correctness of my code.
And it's a question of which do I value more - my big bottle of pop, or the dribble you'd rather give me back.
5 replies →
Just walk away then, no need to set the door on fire.
> Just walk away then, no need to set the door on fire.
That's what he is doing: simply walking away.
But he doesn't owe you anything, and that'exactly what you are getting.
It's astonishing how some people feel entitled to other people's life work. It's like you believe others owe you everything just because you like their work.
4 replies →
Right, and he can do that and that would be totally fine. People stop maintaining projects all the time. But by going out of his way to antagonize people (many of whom aren’t even the people who “spit” at him) he’s just not being very nice.
> It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.
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
> Th e 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.
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.
>you're telling me to expect that the upstream author will take their code offline
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.
1 reply →
> Why should I use this software at all, let alone let you waste your time on patches? I'm gonna buy from Oracle.
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.
1 reply →
> Like it or not, there are implicit social contracts if you maintain OSS software.
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.
that contract is precisely spelled in the license file, idk what you all are on about.
4 replies →
> Ignoring security conventions, and then adopting a "take my ball and go home attitude"
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.
This is a weirdly hostile and unreasonable take. The maintainer was rejecting patches and ignoring bugs after advertising that patches were accepted and bug reports were desired. That at the very least makes the maintainer a liar. Additionally, the framework was advertised for general use that it was not suitable for given the soundness issues. Since when did lying to people, wasting their time, and being obstructive about their good-faith attempts to improve the project in the way the maintainer had already requested become admirable?
If some one opens the door for you that was nice of them, they did your work for you, they have no ongoing obligation to maintain the door in an open state.
If some one give you their code that was nice of them, they wrote your code for you, they have no ongoing obligation to maintain your code.
by simply giving you their code they have already provided you with value, a head start for nothing in return, they have opened the door for you, the rest is up to you.
We’re starting to stretch the metaphor too far, but by opening the door you’ve signaled to me that I can walk through it safely. Closing it abruptly can in some cases be even worse than the alternative, since I could have possibly opened the door myself (written it myself and not invested time in this particular project) or gone through a another door that was also being held open (used another open source project).
> by opening the door you’ve signaled to me that I can walk through it safely.
It was safe for me, is it safe for them? Thats not a judgment I can make on their behalf. A lot of people are complaining that the code is unsafe while the author thought it was safe enough for them. How many nines is safe, depends on the person.
You should consider these things before using some ones help, not after, looking at the comments here no one did that.
> It's not very hard to say, this is a project for my own technical interest, I don't intend to follow Rust norms about use of unsafe, and you shouldn't rely on it.
So this guy is happy to rely on code he hasn't even looked at and then gets upset when that code is unreliable. This is not a reasonable expectation.
He try's to make out like this was a professional product that you would expect professional support for, but this is just some code he found on github and couldn't even be bothered to look at.
If you took the code when it was available then you walked through the door when it was open, now the door is closed its your responsibility.
5 replies →
You walked through the door safely. Then you come back day after day and say "Where is my doorman! He opened the door once, that is an implied social contract to open the door every day!"
agreed that it is being stretched. perhaps a better metaphor would be not just opening the door, but building it.
Well put. I’d add on to your metaphor: slamming the door on someone is quite different than just not holding it open anymore. The second is totally acceptable; the first is impolite.
This case is clearly akin to not holding the door open anymore.
The code’s all there and still available, right? Anyone who wants to can reach out and “hold the door open” for themselves, can’t they?
If someone is relying on your code, that means they have their own copy of it.
You're not obligated to keep your copy online.
As an open-source developer myself, I'm annoyed when people do that. I want them to rely on my product, not my code. I want them to update when I publish new versions and I want them to send patches back.
There are even almost-open-source licenses that compel you to send patches back. I don't want to use one. I want to treat them with respect and I hope they treat me with respect in turn.
I don't know what planet you live on, but people need a local mirror of your stuff for reasons such as, oh, so that their continuous integration builds don't stop when your server is not reachable.
Most users are not going to use your today's daily build, nor should they. Only people who are more than casually involved with your project can be expected to contribute changes which are rebased to the current.
If things are working for some users, and there is no security advisory that affects them, they have no reason to update to every new version.
Anyway, between you and the users, there may be middlemen: the distro package maintainers. Those people will lag in picking up your changes, and may push back on bad ones that break things for them.
People should mostly get stable things from their distros, not straight from the horse's mouth.
For instance, if I'm building something on Ubuntu 18, I will use the make, bison, shell and whatever else that is packaged on Ubuntu 18; I'm not going to pull these things from the tips of their repos and rebuild their latest versions.