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.

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

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.

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

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

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

Otherwise the bad apples are the apples.

> I think you are confused

You sure?

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.

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

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.

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.

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.

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.

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

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

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

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

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.

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.

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.

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.

>> the author even asked for volunteers

citation needed

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.

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

Yes, this is what I don't understand - we spent decades fighting the perception that open source could never be as good as proprietary commercial software. Now that we've mostly convinced our bosses, we want to turn around and say, no actually an open source maintainer who writes buggy code, rejects patches, and takes down their project when called on it is doing exactly what he should do?

Of course he has every right to do that, but this shouldn't be (and fortunately isn't) the norm. Defending this outcome as the expected outcome just means that the bosses will quite justifiably say, suppose we use this software and I let you publish patches back, you're telling me to expect that the upstream author will take their code offline? Why should I use this software at all, let alone let you waste your time on patches? I'm gonna buy from Oracle.

Yes. If a company shuts down, who is to blame when the downloads are no longer available?

No offense, but your build process is lacking if you are affected by a project disappearing from the internet.. You should be bundling all of your libraries with your final artifact.

This is a prime example of relying on the cloud without a continuity plan.

With OSS you always have an option to keep your personal copy of the source tree, and you have an option to fork it and maintain it at your own expense. When Oracle closes and discontinues the software you rely upon, you are screwed big time.

The advantage of them is pretty theoretical since you don't really want to become responsible for someone else's code drop, but that's not any different with open source.

I think I agree, and its tricky because its really hard to pinpoint what the contract is (without sounding "entitled"), like there is with any social contract I guess. Maybe it even depends on the various cultures of the people working on the project.

I consent to let other people make demands of my OSS because I wish to make demands of their OSS because together we can build a better world than either of us could on our own - because I am consenting to be part of a community. I have security-sensitive Rust code on GitHub. I'm careful about unsafe, and I welcome people filing bugs, because I want the entire ecosystem to be good about unsafe, and so I need to do my part in that.

That statement is quite wrong. It's not a "take my ball and go home" attitude. You are not the boss of a FLOSS maintainer not are entitled to order anyone around to do your bidding. At best you're addressing a person and asking them to do you a favour. If the maintainer doesn't feel he should be bossed around by you then he has been generous enough to let you pick up where he left off and actually put in the legwork you are expecting others to do.

And in return these haters prefer to just bitch around and criticise others for not following their orders.

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.

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.

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.

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.

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

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?

You're not obligated to keep your copy online.

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.

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.

As an outsider I have to say that I think what the Rust community has technically achieved is remarkable. But on the social side it is not so bright, avid Rust users constantly spam forums of other programming languages with toxic comments. But this incident shows that the situation is even worse than expected, the Rust community even treats its own peers like sh..

For many people, their personal interest in open source is writing code for fun and showing it off. For others, it's making a product that people can rely on. The second one is my motivation; don't take that away from me.

If you are making products that people can rely on primarily because you enjoy it, you are literally an amatuer.

There are figurative connotations of quality and polish implicit with those terms, but I find those connotations unfortunate and in many cases unwarranted.

For instance, I don't pay a penny for HN but I can complain that these discussions sometimes become self-congratulatory prattle where angry people carrying a giant chip on their shoulder posit absurd, completely ridiculous notions and they're supported in their group delusion by like-minded parrots. You don't have to agree with my complaint, but nor do I need your or anyone else's permission to hold it.

Also, there are expectations for both sides of a professional interaction. My employer buys various fancy networking equipment for lots of money and we absolutely wouldn't expect an answer for that question.

If you create an organization on GitHub for a project that is meant to remain personal, this kinda sends a wrong signal.

Blaming some users for being rude and entitled, and then deleting an open source repo out of spite... it's a bit hard to feel sympathy for the guy here.

Sounds like there were intentions or plans to transform a one man project into something bigger. Some steps were made. Hence, a nice looking website, a github org, benchmarks etc. All those signals are intentions, the vision of the future self. They may or may not come true.

Nothing signaled an established business model or sustainable backing of any kind.

In this example it is held as a significant accomplishment on this individual's linkedin page. Which isn't surprising as professional credibility is a primary motivation driving a lot of open source involvement. We are seeking a different, less direct form of compensation.

So it's fair to say that acting like this is unprofessional.

That doesn't mean it isn't merited, or that they might have been frustrated or had good reason. But professionally they would have been much better served by other means: Simply announcing that they're retiring from the project and encouraging forking and the percolation of a new canonical version, etc.

Sure, if you want to spread the misery. That's still kind of a dick move, even if he's perfectly within his rights.

If you offer code to the public – and present it as an active, dependable project – professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.

It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.

As far as I can tell, this project was released under the Apache License 2.0.

https://github.com/actix/examples/blob/master/LICENSE

Clause 7 of said license says the following:

"7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License."

Other popular free software licenses (namely the GLP) have very similar clauses.

> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.

Expecting labour from someone without paying them is the very definition of entitlement.

Is there a social contract that put some expectations on the volunteers who are organizing the activity/event, and is that the definition of entitlement?

I would say there is such social contract, and when people expect too much of it there is also entitlement going on. Where the exact line goes is gray zone.

What the license says and what image the project presents can be very different. Pointing to the license and reasoning that nobody has legally promised anything contractually is not very useful.

> Expecting labour from someone without paying them is the very definition of entitlement.

That’s a very mercenary view of the world. What about volunteer charity workers? Is it OK for them to just not show up whenever, just because they aren’t paid?

I have some friends whose profession is running charities (i.e. they actually get paid). Volunteers not showing up is exactly what happens, all the time. And my friends expect it, plan for it, because the volunteer is not getting paid to be there. Without that tangible incentive, a volunteer time competes for all the other intangibles competing for time (e.g. "I'm tired", "the kids need something", "friends are going to do something fun at the same time"). They build it into planning: some percent of the people who signed up aren't going to show up...if the weather bad, a bigger percent aren't going to show up. And so on.

They don't get all ranty or judgmental about it, they're just smart enough accept that reality and to plan for that eventuality. Just like anyone using an open source project without paying for it should be.

It is quite useful, because the license is the legal document that comes included with the software, and that specifies what things you agree to if you use the software. And it explicitly specifies that you cannot assume any contractual obligations from the "image the project presents", or anything of the sort.

> That’s a very mercenary view of the world. What about volunteer charity workers? Is it OK for them to just not show up whenever, just because they aren’t paid?

I would say that if someone promises to do some charity work and doesn't show up without a good reason is breaking a promise, and is thus being a shitty person. People should keep to their word. Open source authors promised us nothing and owe us nothing. More often than not, we owe them.

There is such a thing as an implicit promise. A project which presents itself as active and maintained by a community does implicitly promise a certain level of attention by its maintainers.

Did you miss this part?

If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting, we'd be grateful. I appreciate how much your HN posts have improved, but it's necessary not to break the guidelines.

As an open source maintainer, you're perfectly entitled to just walk away. Hit that archive button on github so nothing new can come from the repo, and enjoy your life. Nobody could fault on you that. People would prefer you work out a clean transition to a new maintainer, but you have no obligation to do so.

Deleting the repos is the equivalent of setting the house on fire on the way out (especially when they're under their own org). Unlike in reality, it turns out it's totally permitted, but people will still view it as a dick move.

> At the moment I am planing to make repos private and then delete them (will remove benchmarks as well), unless others suggest better ideas.

something anyone can do right now, I would add

but people just prefer directing the guy work

Anyone that cared already has their local repository copy.

After all that is what DVCS are all about

I would guess that it would make it very hard to create a community around the project.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

It's in big capital letters there. Explicitly no implied promises.

> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented

That is almost literally the definition of entitlement

The attitude baffles me. So many times I've had someone come in all butthurt and say 'I know it was in the contract, but I didn't think they'd actually enforce it'.

or the converse situation "I know I used liberal license but I'm still going to raise hell if people actually do what the license allows"

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,

Period. Calling it a 'liberal license' doesn't mean what you think it means.

In the case of open source, it's worth asking the maintainer what the terms are if you're unsure. The LICENSE always says that authors and contributors are not liable for any outcome, either as an ALL CAPS paragraph or a clearly defined section.

Everything is provided as-is so you can't expect anything. It's on you to pick up after them if you still need the project.

Moreover, companies present themselves as “active, dependable project”s then go belly up all the time. Not sure why hobby projects should be held to a higher standard.

Practically speaking, if I give you some work I did for free yesterday, and give you some work I do for free today, that does not entitle you to free work from me tomorrow. It does not entitle you to free support on the code I’ve published already. I owe you my time when you’re paying for it. Until then, if I have made something you found valuable you are in my debt for its use. Not the other way around.

As a user of my software I generally give you two rights - you have the right to use the code in your project, and the right to fork the project. And as the maintainer, I have the right to spend my time however I want for the rest of my short life on earth. If the beach looks like more fun than putting up with entitled complaints on github and HN, that is my right.

This is particularly true when you look at what licenses say:

... THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

... THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.

... IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The onus is always on yourself to insure against everything.

Ofc, git is distributed, so someone should have a copy of the repo, even if it's not updated.

Edit: disregard post, apparently it's just moved to the personal account.

> I moved actix-net and actix-web project to my personal github account. I will make decision during next couple days what to do. I don’t want to see the project becomes ghost of what it was. Maintainers must understand how everything work, but don’t anyone who does and those who could are busy with other projects. At the moment I am planing to make repos private and then delete them (will remove benchmarks as well), unless others suggest better ideas.

If you put your code out there open, it's still your code. If people start to rely on it, they need to be ready to maintain their branch.

Not familiar with the project or Rust Ecosystem. Anyone else can comment whether it was presented / marketed / sold as an "active, dependable project" ?

As someone more used to the Ruby Rails ecosystem, I think the communities as a whole generally accept the convention that all open sources, whether they are backed by a single person or cooperate account, are given out as it is ( MIT ) and their maintainer or author will do the support or development as they could when they are FREE. And it is perfectly acceptable of forking it to make your own variation or improvement.

Think about this. Do you really think it makes any sense to try to hold people to promises inferred by alternate parties that aren’t even providing any consideration in return?

Just think about that.

That's exactly why I encourage people to think about it.

It's a delusion to believe random strangers owe you anything (beyond basic compassion and curtesy) and you'll continue to be unhappy until you let go of that delusion.

Apparently a number people believed this developer worked long hours on this project (for free) because they were obligated to do so. Not only was that incorrect, it seems to have contributed to the dev leaving the project since some people felt justified in making rude (and sometimes angry) demands.

Thinking about it is important because when you do, you can see there's no reason at all to believe that the dev would put in a lot of work for free to maintain a project while continuously receiving abuse from a reddit mob while doing so.

Wise up. Professionals get paid, if you aren't paying some one they are not a professional. This is the reason why opensource projects provide professional support for pay, for professionals who need professional support.

I believe that the legal is the "top-level" statement that sets expectations all the way down.

If people aren't choosing a license compatible with their values, then that's on them. The era of Github only giving you free hosting if you pick a DFSG-compatible license are long over; you could put the Windows source code on Github and they would be happy to use a heart emoji to describe how they feel about it.

like, for example, in a license file?

Did the maintainer screw over people that were using Actix? Very likely.

I sympathize with both sides here. I've been the unthanked, punching bag contributor on a few notable projects, and I've been a user of software whose leadership got into drama and squabbles, that ultimately fucked me over.

There were times that I pulled certain projects and essays, that had greatly helped people, and taken my ball home because I was fed up with the people I was catering to. There is no correct answer here, dealing with people and their emotions, but there is a way for both sides to handle things without contributing negatively to other's lives.

How so? Just find a fork with a decent maintainer, or push your copy to your own repo. Let the Actix guy do his thing and move on with life.

It is your choice to use open source software without open sourcing your own work or without contributing.

But by engaging in open source you engage in a social contract, you become part of a community whose goal it is to foster collaboration and help one another, other people start to rely on you, just as you rely on their libraries, compilers, and kernels.

The author choose to break that social contract out of spite. He created a scenario where people choose to rely on him, when they could have relied on other works, and then screwed them over majorly.

... or use Windows / MacOS / Solaris / any other commercial OS he paid for...

> by engaging in open source you engage in a social contract

You heck. You simply allow other people to use your work as they see fit. That's it. The only contract is the license, and the license is very explicit in denying the existence of any other tie, explicit or implicit.

But we can go beyond that, and start to do more work, and make grander social promises. Calls for a "community" come with the implicit agreement that this codebase now exists for more than just the one person who initialized it. And that you've pushed it into the public, and requested people to treat your repo as the repo, you've taken on certain responsibilities, and made some implicit, or explicit, promises.

Sometimes the job is thrust upon the maintainer accidentally (eg Linus), and sometimes it is requested (apparently in this case?)

But nonetheless it's a natural function of the OSS community, and there are ways to deny the responsibility appropriately, and inappropriately.

But it's there is much more nuance to this than dumping a box, or reading a legal contract (which is never representative of social contracts; it's just the bare minimum to avoid responsibility in the eyes of a lawsuit.)

What they did was climb through everyones window to get the cardboard box back, just as with the npm leftpad incident.

Stop painting the narative like people demand some volunteer to do more free work, when all they do is ask to not be actively sabotaged.

And frankly I don't buy the story that they wanted to put the code on their own repository anyways, seems more like a concession because the other contributors also hold some copyright.

If your workflow relied on a package being delivered every morning, even unchanged, it's your own fault. He never made that guarantee.

Stop painting the narrative like people owe you anything, when you're just failing to correctly evaluate the actual resiliency (non-)guarantees of production pipelines based on random github repositories.

And yes shockingly people are entitled to be treated fairly and not to be sabotaged. And no, providing them with a library for a limited period of time and then being fed up with it's maintenance doesn't somehow earn you that right. It gives you the right to walk away, but clearly thats wasn't enough for the author.

But hey if you want that to live and bathe in that kind of toxicity, enjoy!

Prove it.

"But by engaging in open source you engage in a social contract" https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

Actix was written in rust. Rust is OS. qed.

Quote from Rich's gist.

>> I'm sure you know better about the one true way to write software. But kindly don't burn the community down on your way out, with self-serving proclamations.

The actix author could just have walked away, no harm done, push one button "Archive", go outside and enjoy the sun.

Instead they choose to throw a tantrum, write a pamphlet and nuke everything.

Entitlement goes both ways.

Can I get this on a poster please? Really well put.

The abusive comment seems to have been a knee-jerk response from someone dissatisfied by the "it's boring" comment about a proof-of-concept patch.

Now you can’t.

Libraries, compilers and kernels alike.

If you want to rely on software being there, you should be ready to pay for people to support it.

> This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share.

It is clear to me that is not true anymore. It is really hard to find open source project without clear direct financial incentives.

Again, as a community, we should start to pay for the components we use.

But that is a different issue, from the behavioral standards we as a community uphold implicitly, and which are broken by pulling a "left-pad" incident.

I work in open source as well at both day job and for "fun" but I fix the issue that I want and if people want something from me as author of whatever, there is going to be a money talk.

The author created a project and advertised it to people, if they don't want to maintain it anymore, sure, no problem.

But deleting it to spite others is considered a d* move.

Have they? how much $$$ profit did they make?

You aren't paying for shit and yet you think they are making a profit and you are entitled to professional support? Wise up.

I profit from Clojure, Python and the linux kernel. Doesn't mean I habe an income from their existence.

Nobody is arguing about professional support, but advertising a project and then deleting the entire thing to spite people is a jerk move.

Ready up!

Thats exactly what it means.

https://dictionary.cambridge.org/dictionary/english/profit

I use linux to write python that I sell for a profit, I profit from these things, and I am happy to support these projects with my profits in return for professionalism I need to make a profit.

If I use them in a personal project I benefit from them not profit, and I certainly don't expect anything more than the benefit of not having to write that code, the rest is up to me.

This is pure entitlement.

>> the good result or advantage that can be achieved by a particular action or activity