8 ms·

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 us

by geofft 7y 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/ 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/ 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.

Touche 7y ago
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.
- saagarjha 7y ago
  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.
- j-pb 7y ago
  Just walk away then, no need to set the door on fire.
  - rumanator 7y ago
    > 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.
    - bryanrasmussen 7y ago
      he's walking away, but before he does he decides to brick up the door he was holding. that's ok though because the house has lots of other doors that are based on the door he was holding open, all people have to do is to go through the effort to find the best version of the door that is most like the door he was holding open before that he's bricked up and thus is not available for comparison anymore. I certainly think he had the right to do what he did, and the people who were rude deserved to have the door bricked up, but the people who read the notices he put up before hand about how he was holding open the door and it was a good way into the house might feel he is sort of a jerk.
      - rumanator 7y ago
        > he's walking away, but before he does he decides to brick up the door he was holding. If you're interested in the project you can still access the source code. Hell, the author asked for volunteers to pick up where he left off. Yet, you're only complaining that he is no longer working for you and complying with your personal whims. That's the problem. A guy volunteers himself and donates his expertise and work to give you a gift, and in return some moochers just want to mooch off of him and, worse, attack him for not complying with their whims.
        j-pb 7y ago
        Literally no one is complaining here that they no longer want to work on the project. It's all about the deleted code, and the damage he did to the community by yanking the project from its primary hub (which also kills all gitter conversations, links, build pipelines e.t.c.) >> the author even asked for volunteers citation needed
- KirinDave 7y ago
  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.
  - sophacles 7y ago
    > 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.
    - KirinDave 7y ago
      > 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: But isn't it also a false dilemma to suggest that the only lens by which you accept PRs is in the role of "project manager?" > Other reasons offered Sure but those are hypothetical. That's not what was going on here. The author of this diatribe was actively soliciting patches and maintaining the project publicly. We certainly aren't coercing him to take a role he didn't want (at least initially).
  - undecisive 7y ago
    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.
saagarjha 7y ago
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.
- jmull 7y ago
  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?
mabbo 7y ago
> 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.
- saagarjha 7y ago
  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.
  - tastroder 7y ago
    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.
    - saagarjha 7y ago
      This person killed the momentum that this project had, much of which was only partly their work. Forks fracture a project’s community and pit the pieces against each other: occasionally they work out, but often they all just fizzle into nothingness. Keeping a project together has value. (Also, note that associated GitHub metadata such as issues has been wiped.)
dangerface 7y ago
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.
- saagarjha 7y ago
  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).
  - dangerface 7y ago
    > 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.
    - geofft 7y ago
kazinator 7y ago
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.
- geofft 7y ago
  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.
  - kazinator 7y ago
    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.
Tehchops 7y 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. 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
- rumanator 7y ago
  > 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.
  - dodobirdlord 7y ago
    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?

by geofft 7y ago

Touche 7y ago

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.

saagarjha 7y ago
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.
j-pb 7y ago
Just walk away then, no need to set the door on fire.
- rumanator 7y ago
  > 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.
  - bryanrasmussen 7y ago
    he's walking away, but before he does he decides to brick up the door he was holding. that's ok though because the house has lots of other doors that are based on the door he was holding open, all people have to do is to go through the effort to find the best version of the door that is most like the door he was holding open before that he's bricked up and thus is not available for comparison anymore. I certainly think he had the right to do what he did, and the people who were rude deserved to have the door bricked up, but the people who read the notices he put up before hand about how he was holding open the door and it was a good way into the house might feel he is sort of a jerk.
    - rumanator 7y ago
      > he's walking away, but before he does he decides to brick up the door he was holding. If you're interested in the project you can still access the source code. Hell, the author asked for volunteers to pick up where he left off. Yet, you're only complaining that he is no longer working for you and complying with your personal whims. That's the problem. A guy volunteers himself and donates his expertise and work to give you a gift, and in return some moochers just want to mooch off of him and, worse, attack him for not complying with their whims.
      - j-pb 7y ago
        Literally no one is complaining here that they no longer want to work on the project. It's all about the deleted code, and the damage he did to the community by yanking the project from its primary hub (which also kills all gitter conversations, links, build pipelines e.t.c.) >> the author even asked for volunteers citation needed
KirinDave 7y ago
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.
- sophacles 7y ago
  > 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.
  - KirinDave 7y ago
    > 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: But isn't it also a false dilemma to suggest that the only lens by which you accept PRs is in the role of "project manager?" > Other reasons offered Sure but those are hypothetical. That's not what was going on here. The author of this diatribe was actively soliciting patches and maintaining the project publicly. We certainly aren't coercing him to take a role he didn't want (at least initially).
- undecisive 7y ago
  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.

saagarjha 7y ago

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.

jmull 7y ago
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?

mabbo 7y ago

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

saagarjha 7y ago
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.
- tastroder 7y ago
  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.
  - saagarjha 7y ago
    This person killed the momentum that this project had, much of which was only partly their work. Forks fracture a project’s community and pit the pieces against each other: occasionally they work out, but often they all just fizzle into nothingness. Keeping a project together has value. (Also, note that associated GitHub metadata such as issues has been wiped.)

dangerface 7y ago

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.

saagarjha 7y ago
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).
- dangerface 7y ago
  > 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.
  - geofft 7y ago

kazinator 7y ago

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.

geofft 7y ago
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.
- kazinator 7y ago
  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.

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

rumanator 7y ago
> 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.
- dodobirdlord 7y ago
  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?