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

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

Reading the description in the root of that project, the community and user base might just as well be attributed to "killing the momentum" if you like (if that's even the case, this seemed to have happened literally hours ago). The issues seem to be intact on the maintainers personal copy of that repository.

I mean, yes, keeping a project together has value, I just don't see where the assumption here comes from that this maintainer has to do that indefinitely or even has to be involved in actively searching for successors in a community they don't feel good about. The maintainer even states being open to suggestions. If nobody steps up, momentum can't have been that great, if somebody does, a fork will live on. That's still in the realm of mild inconvenience, other projects have survived much larger controversy.

edit: the frontpage is currently topped by a more balanced write-up by Steve Klabnik that weighs up, among others, both of these views https://news.ycombinator.com/item?id=22075076

> I just don't see where the assumption here comes from that this maintainer has to do that indefinitely or even has to be involved in actively searching for successors in a community they don't feel good about

Of course they don’t. But I don’t see why they couldn’t have made an issue along the lines of “I’m stepping down, I’d like someone else to take over the project”. (Still reading through the other writeup.)

What do you mean wiped? It was moved to personal account https://github.com/fafhrd91/actix-web.

I was under the impression that that repository was probably going to be deleted at some point.

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.

I think there are a number of ways the maintainer could have protected themselves without making it actively worse for the community. I would even predict that this decision makes them likely to get even more abuse, though of course I would never condone that.

> I think there are a number of ways the maintainer could have protected themselves without making it actively worse for the community.

If said community was the one causing the problem, what would be the point of that?

The community is not a monolithic entity.

If there are bad apples in the community then the good apples need to speak up and reject them.

Otherwise the bad apples are the apples.

They're referring to the maintainer's conscious decision to reject a patch made in good faith, that fixed the issues that had been pointed out. It was rejected with the statement "this is boring." Do you think this behaviour is justifiable?

> I think you are confused

You sure?

> They're referring to the maintainer's conscious decision to reject a patch made in good faith, that fixed the issues that had been pointed out.

You're misrepresenting the problem. There was never a bug or an issue, only a bunch of opinionated and vocal users who thought that bullying a maintainer is an acceptable way to get him to accept their patches. The maintainer rejected the bullies' actions and in turn the bullies ramped up their attacks, which ultimately convinced the maintainer that closing up shop is the best way to stop having to deal with these bullies.

> You're misrepresenting the problem. There was never a bug or an issue

The story originated from the author of this article [0] posting a bug report issue [1].

Why are you accusing others of misrepresenting the problem while doing so yourself?

0: https://medium.com/@shnatsel/smoke-testing-rust-http-clients...

1: https://archive.is/BEqfM

Please stick with the facts and thus with primary sources. Part of the blame of this shitstorm lies in those who insist in misrepresenting the problem with bullshit blog posts and "he said she said" nonsense.

https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou...

Unfortunately this is not the first time Rust soundness/unsafe zealots are aggressive and create shitstorms in the community.

I linked to an archive of the GitHub issue in question and the reporter's own blog article about it. Are those not primary sources? And you've linked to Reddit?

It is if your the one maintaining it. It's not like people are paying the person to accept their patches. If they want their patch applied they can fork the project. The maintainer isn't a slave to others.

Under what obligation does the maintainer NEED to accept any patch? It's his project he built. He can build or destroy his work as he sees fit. If you have an issue fork it. This is how things like libreoffice, mariadb, and countless other projects have come to exist.

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.

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

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.

So uh, I gotta be honest with you: I can barely follow your post. It makes very little sense to me. But the parts I can figure out, I disagree strongly with.

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

The flaw with this is that just running code in production for a modest amout of time proves nothing. That is in fact the opposite of proof, it's an anecdote. Safe code from a sound compiler can be literally proven to hold certain properties, with a margin of certainty that depends on then compiler.

Now of course, the proof guarantees of the specific code in question are weak compared to what you can do with something like Liquid Haskell or Idris or Coq, but they're definitely more than this pride-based programming you're holding up.

> Maybe your code has introduced a complex interaction that none of my examples exploit, but other people's examples blow up because of it.

And maybe your code already had that. That's why I trust compiler checks a hell of a lot more than people. And that's why I find this entire movement of pride-based programming that you and the subject of this thread so problematic. You're just holding up your haphazard experience as evidence. And honestly, not many people's experience would move me that way. Maybe if you're running it as Google or Facebook's frontend I'd find that reassuring, but short of that...? No.

Have you load tested your software? How did you simulate it? Have you validated your algorithm with a tool like TLA+? Have you watched your memory use carefully? Have you measured the latency variance? Under what kinds of loads? Is your data real or a projection using something like USL4J?

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

Pull requests on GitHub are generally the click of a button. If they're not good on grounds of completeness, then reject them on those grounds. Not, "Oh here we go again this code is so much more mechanically verified than mine, don't start this again."

> pride-based programming

I'm absolutely not talking about pride. That's a straw man - nowhere in my answer did I discuss a person's pride. I'm a big proponent of egoless programming (as far as any human being can) and while I have no idea whether ego came into this, pride is not the only reason a person might reject these kinds of patches.

That said, ego is a great reason for you to dismiss valid arguments, so I'm guessing you've made up your mind.

> The flaw with this is that just running code in production for a modest amount of time proves nothing. That is in fact the opposite of proof, it's an anecdote. [...] proven to hold certain properties [...]

You've just made exactly my point, but from the opposite side. You are saying that Safety, and those "proven properties" are of higher importance than being bug-free in the real world.

The issue is that it is impossible to prove that code is correct via tools. You can prove some properties, but you cannot prove fitness for purpose.

> Have you load tested your software? How did you simulate it? Have you validated your algorithm with a tool like TLA+? Have you watched your memory use carefully? Have you measured the latency variance? Under what kinds of loads? Is your data real or a projection using something like USL4J?

Generally speaking, I have no idea. In this scenario, I know the project owner has done some performance testing, so maybe. But honestly, I've no idea what you're trying to argue here.

> Pull requests on GitHub are generally the click of a button

This seems like a big flip from the previous statement. No, Pull requests on GitHub for a trusted and depended-on project are NOT a single click. If that is how you run your open source PR pipeline, very quickly your users will not trust you.

> You've just made exactly my point, but from the opposite side. You are saying that Safety, and those "proven properties" are of higher importance than being bug-free in the real world.

You don't know its bug free. You're saying you haven't seen obvious bugs. That may work for you, but I try to gamble as little as possible when it comes to code.

But even if we ignore safety, you're also skipping expressiveness and more self-evident code for what?

You're not qualifying your "real world experience" with any sort of alternative rigor that might represent some sort of nod to modern practice. Until you do, you're shouting "I believe in this because of my pride."

You can deny that characterization, but that's what it is.

> Generally speaking, I have no idea. In this scenario, I know the project owner has done some performance testing, so maybe. But honestly, I've no idea what you're trying to argue here.

As opposed to your "pop" metaphor, you think asking for some demonstration of rigor is confusing? Well... The world is full of different ideas I guess.

> No, Pull requests on GitHub for a trusted and depended-on project are NOT a single click. If that is how you run your open source PR pipeline, very quickly your users will not trust you.

You didn't read very carefully if this is your takeaway and I won't entertain a straw man. Perhaps next time spend less time on a labored "pop" metaphor?

This is cognitive dissonance at its finest! Clearly you want preciseness, so I'll go through these gems bit by bit:

> You don't know its bug free.

And I haven't said that I did. What I have said is that - unless you give some evidence to the contrary - I'd rather trust the code as it stands, to new code that hasn't had the same amount of airtime. So if there is a known bug, and your bug fix ALSO introduces some correctness, then brilliant! I applaud your girl/boy scouting. If you are rewriting someone else's code because you don't like it on a philosophical level - however much the community appreciates this philosophical viewpoint - the project owner is under no obligation to gamble on your new code, and is right to accuse you of hubris, self importance and a lack of any kind of empathy.

> You're saying you haven't seen obvious bugs.

No - I'm saying you haven't seen any proven bugs. I'm saying that care and attention has been made to eradicate the bugs that were in the first versions of the code. With every code change you make, every line of code has a 1-in-X chance of containing bug(s) (that X varies from language to language) so if you change a lot of lines, unless the code is _really very very_ broken, the more lines you add, the greater the likelihood that you're adding bugs.

> That may work for you, but I try to gamble as little as possible when it comes to code.

I think I've made the point above, but in case I haven't: Both choices are gambles. One is a gamble with the evidence to back it up, the other is a gamble on something that has next to no evidence at all. One is the pragmatically certain choice, the other is a lot of risk with no known reward (in this case).

> But even if we ignore safety, you're also skipping expressiveness and more self-evident code for what?

I can't answer that. That is a very very good question. But not asked as hypothetical question - ask it for real. What has the original developer gained? Why is that more valuable to them than enhanced memory safety? Why does the original developer believe this code to be safe enough? Until you ask this question and can answer with certain knowledge, you have not earned the right to rewrite his code.

> You're not qualifying your "real world experience" with any sort of alternative rigor that might represent some sort of nod to modern practice.

Oh, I'm sure the original code had no behaviour-driven tests, single-character method names, that the original author reimplemented GOTO just to get the thing to work.

> Until you do, you're shouting "I believe in this because of my pride."

> You can deny that characterization, but that's what it is.

I'm happy to assume that pride did come in to it. The original author is proud of their work, the new author is proud of theirs. Great. But making a work that only exists to trample on someone else's decisions is crappy behaviour, unless you can prove that your change actually fixes a real problem.

And I do deny the characterization, but only in the sense that you have some kind of weird fixation on this as the only conclusion. I've been making an argument for pragmatism - the pragmatic choice is to ignore the rampantly self-assured meddler.

> As opposed to your "pop" metaphor, you think asking for some demonstration of rigor is confusing? Well... The world is full of different ideas I guess.

You can ask for a demonstration of rigor, but as I pointed out previously, I'm not in any position to give it. I don't know what he did or didn't do to the code. My question is, why does that actually change the gambles above? Are you saying that the author of the pull review DID do all this? Are you saying that the project owner, working in his spare time for free on a project used by thousands who are probably making money from it, should be required to implement this level of testing? Your statement was presented without any context, which is why I was confused.

But here's the rub: Absolutely none of the strategies you mentioned can guarantee correctness in the real world! None of them. Sure, they can help. Maybe they'll make that 1-in-X bugs-per-LOC turn into 1-in-2X, or 1-in-20X. But they won't fix a fundamental misunderstanding on the way a method should work. They won't tell you that some client code is now broken because you introduced an assumption that wasn't in the original code.

What they will do is reduce the amount of time that the original author has to spend with their family, because they now need to test your code change for all the bugs and bad assumptions that the original author probably made the first time they wrote the code, and a few more beside. Maybe they do now have to rewrite their TLA+ constraints, rerun their benchmarks, etc.

The original author might be willing to use his spare time to make his codebase work better. He does not have to spend that time massaging your pride because you rewrote his code because you knew better.

>>> Pull requests on GitHub are generally the click of a button

>> No, Pull requests on GitHub for a trusted and depended-on project are NOT a single click

> You didn't read very carefully if this is your takeaway and I won't entertain a straw man. Perhaps next time spend less time on a labored "pop" metaphor?

I'm not seeing how this is a straw man. You were minimising the effort that goes into PRing... I pointed out that lack of effort in PR process is bad... you shout straw man and try to insult me?

Hey - I'm just trying to give you another perspective here. If you're not a fan of analogies, that's a shame, sorry you feel that way, some people find them useful. You started this by saying:

> I don't understand why the author felt so defensive about accepting packages.

The guy basically flat-out said that the problem was with entitled idiots who think they know best rewriting vast swathes of code without understanding the original decisions.

Since you didn't understand that, I gave you an allegory. If that doesn't help, and this doesn't help, well, don't know where we can go from here.

> Since you didn't understand that, I gave you an allegory. If that doesn't help, and this doesn't help, well, don't know where we can go from here.

It was a metaphor, not allegory. And literally no one understood it. I only saw your comment because I was briefly reminded of this discourse after some other community sites found your attempt at metaphor and mocked it in front of a wide audience.

Not the outcome I was hoping for, but I hope that the exposure helps you get your message of "I do what I want and don't have to prove anything to anyone" when writing code. I look forward to seeing how that helps your professional reputation.

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.

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.

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

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

well, I already apologized elsewhere as I had misunderstood his personal repo to mean a private repo, but anyway I don't code in Rust, so no, I'm obviously not complaining that he is no longer working for me.

This obviously means also that he has not given me a gift.

Finally I am not sure what reasoning has led you to assume that if he gave me a gift moochers would want to mooch off of him, and how they would do so by virtue of him giving me a gift. Whatever reasoning it was, I'm forced to think there must have been little of it.

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.

This has nothing to do with build process, this has everything to do with the expectation that a project will continue to exist and put out new releases. All out builds at work, in fact, are offline. We check in tarballs and we don't access the internet. That has nothing to do with whether I can tell my boss in good faith, allow me to submit a patch upstream and it'll be worthwhile to the company and we won't have to carry local patches. Right now I can say that. Why would we want to get rid of that?

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

Big companies often have code escrow agreements to cover that exact problem.

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.

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

This is kind of like saying "its technically not illegal!", in the same way it's not illegal to open the door for someone and then shut it as they are about to walk through. We are talking about social contracts that are not written but are collectively understood to some degree.

The social contract is generally not written down anywhere. Here's what we're all on about: https://en.wikipedia.org/wiki/Social_contract

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.

good thing the license file cover implicit guarantees then, because this is just bullies making up bullshit for justify their pressuring people into complying with their wishes.

The social contract is not enforced in the courts.

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

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

There's a very precise definition of this, it's not a matter of opinion. The code exposed a public API that was not marked "unsafe" that allowed you to construct (definitely intentionally, perhaps unintentionally) two mutable references to the same object.

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

This is a hostile misinterpretation of what actually happened. The bug reporter actually looked at the code, determined it was unsafe, and reported a bug. That's what everyone wants an OSS user to do.

> The bug reporter actually looked at the code, determined it was unsafe, and reported a bug. That's what everyone wants an OSS user to do.

No again this is end user entitlement, you are not an end user you are a developer, if you discover a bug you are supposed to provide a patch to fix it not expect some one else to fix it for you.

If you depend on some one else's code it is your job to do due diligence on that dependency, no one did and it came back to bite them. People need to stop blaming every one else and learn from their own mistakes.

Which is what the end user did! The maintainer rejected the patch as "boring" despite being given concrete example of how UB could be triggered and how the patch would fix it.

Another user provided a patch, the patch got called "boring" by the maintainer, a passerby snapped with offensive personal attacks and the rest is history.

The Actix website encourages end users to report bugs: "If you think you found a bug it's best to go to the github directly."

If you're claiming that taking those directions seriously is entitlement and that it's less entitled to second-guess the maintainer and do what you think they meant even if it's the opposite of what they said....

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.