Hacker News new | past | comments | ask | show | jobs | submit login
Actix project postmortem (github.com)
338 points by dabj 31 days ago | hide | past | web | favorite | 397 comments



"Ok... So that was unprofessional. If you don't want to maintain a project anymore, you give it to someone else and link to that repo in your README.

This just screwed me over big time."

https://github.com/actix/actix-web/issues/1#issuecomment-575...

These kind of entitled attitude is probably exactly why the guy just removed everything.

More details / discussion here: https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou...


It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.

It's not very hard to say, this is a project for my own technical interest, I don't intend to follow Rust norms about use of unsafe, and you shouldn't rely on it, but here's the code if anyone wants to look. That's fine! (And I do think we need to be better about making it common to do that. GitHub has no good tooling for such a repo, for instance: you can't disable pull requests unless you archive the project or make it private.)

But that's not what Actix's docs say. See https://actix.rs/docs/ for instance: there's nothing to the effect that you shouldn't use or rely on it, and everything to the effect that you should. (In case that page gets taken down, it starts, "Actix is your door to developing web services with Rust and this documentation is going to guide you.") On https://actix.rs/community/ it says you should report bugs to GitHub, implying that bug reports are in fact welcome, and there isn't a single statement that the project goals prioritize the author's technical excitement over correct code.

Again, there's nothing wrong with wanting to prefer your technical excitement over having bug-free code. Just be clear about it.


> if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.

This reminds me of an incident years ago. I was on a city bus, very full of people, and we were just about to leave a stop. There's a woman maybe 150 feet away running towards the bus. The driver sees her running and re-opens the door, waiting. Inconvenience to all of us on the bus, but hey, she's running.

The woman, seeing the bus has waited for her, stops running and starts slowly walking instead.

Driver sighs, closes the door, drives away.

I'm not sure what the moral lesson I take from it is, but mainly "if I go out of my way to help you, don't take advantage of my generosity". Maybe that partially applies to situations like this one. Or maybe just "don't annoy transit operators". That's a good one too.


I think that's fair - especially the part about not taking advantage of generosity. But I don't think that's what happened here. Someone reported a soundness bug. Someone else (IIRC) posted a patch fixing it by switching from a custom Cell type to the standard library one, which is what the maintainer called uncreative and boring. Fixing a soundness bug is a perfectly reasonable, non-advantage-taking thing to do in a PR.

(I agree that in general there is a problem with open-source users feeling entitled to support/features and maintainers not feeling comfortable saying no, but that doesn't seem to be the type of incident that triggered this, and more generally it is difficult for me to see how a patch would count as that - at least a patch that isn't "please maintain this pile of new code," which this one wasn't.)


> Someone reported a soundness bug.

Your description starts off on the wrong foot because a) there was no bug, and b) although the library used unsafe code extensively, its maintainer argued that was not a problem and that didn't meant the code was unsafe.

So in the end we only have issues being reported by opinionated users trying to force their personal opinions on a project maintainer, who due to the content and tone of said issue reporters decided not to accept the reports or patches. Once some bad apples in the community started to increase the unpleasantness of the whole experience, the maintainer said enough is enough.


In this case, the maintainer made an active and conscious decision to do something that did nothing but hurt everyone using the project. There are no passengers who might benefit here, sadly.


Since this seems to be a constant point in this thread but I don't see it: How exactly did that person hurt anybody? They maintained this project for 3(?) years and the code is readily available elsewhere on github now. If there's really that many people being inconvenienced by that, surely somebody else will take over that fork instead.


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.


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.


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.


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


They're right, it was unprofessional... but since the maintainer is not being paid this is not a professional project. It's a personal project. And this seems like a perfectly personal thing to do with something that's preventing happiness.


I absolutely agree with this. The author has spent an insane amount of time to build all this stuff and instead of getting recognition and/or being payed adequately he is getting shitstorm after shitstrom.

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


Well, no different than any other tech where the community is an echo chamber full of fanboys. Linux used to be like that, especially some of its distros (uhm Gentoo?), cryptocurrency fans are like that, Apple users probably don't need mentioning neither ...


Gentoo is just a meme spread by some 4chan /g/ board's members. Maybe you meant Arch?


... Gentoo predates 4chan's existence by 3 years, is one of the older and more respected distros still around, and is the basis of Chrome OS and Container Linux. Don't assume that 4chan somehow defines the things they happen to be interested in.


"btw I use Arch" is a meme as well


Well, it's easy to get confused when you look at the professional looking website with a well crafted logo, a promo list of features and a copyright notice from the "The Actix Team". The community page even says "We're a welcoming community so don't be afraid to engage.". Ouch!


The easy way to tell is to remember if you're paying them or not.


Absolutely not. You can get professional (but not necessarily timely) support from me for multiple projects I maintain on GitHub, for free.

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.


That’s fine. It’s even admirable if you to do that. But it isn’t and shouldn’t be mandatory.


While “mandatory” would be a stretch, I don’t think there’s anything unreasonable about expecting project owners not to overstate the maintenance level of their projects. Deliberately conveying a false impression to people is called lying, and it’s generally regarded as being bad.


The distinction between "amatuer" and "professional" is literally the motivation for the action, i.e. if you are doing it for enjoyment vs if you are doing it to get paid or advance your career.

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.


Sure. I'm not saying I am a professional. I'm saying I will provide professional-style support (according to the connotation), just not necessarily in a timely fashion, and it's demoralizing when other people say you should avoid my amateur software because they're leaning on the connotations of "amateur" and "professional."


That's not true at all. You can pay for amateur bullshit, and you can get professional software and support for free (and free as in freedom).


You can get professional software and support for free, until you can’t. This “you’ve provided me free support once, so it’s your obligation to support me for free indefinitely whenever I ask” attitude has certainly contributed to my open source exhaustion as a maintainer.


Well, good luck getting a company you paid for a product to provide indefinite support, large professional software companies cancel projects and EOL software all the time.


You only have a right to complain about the amateur bullshit you paid for, though.


You have a right to complain about anything and everything.

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.


My Ethernet is stuck in ipv6, professionally tell me how to fix it, for free.


That's not an open source project any of us maintain.

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.


Sure, could you provide some more detail?


I actually did that for years in a linux forum.


Huh nothing you said indicates it is a professional project. Sleek does not equal professional.


> It's a personal project.

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.


For information, the repo has not been deleted but simply moved: https://github.com/fafhrd91/actix-web


> If you create an organization on GitHub for a project that is meant to remain personal,

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.


Exactly. It can be argued it's unprofessional to become dependent on third-party software without any background recherche regarding the maintainer's motivation, team size, financial standing, etc., especially when said third-party software isn't a replaceable, standards-based component such as, say, Java Servlet containers and other web components used to be.


Professional pursuits are things related to a vocation, not directly tied to an exchange of money for every interaction under consideration. If you're in the industry of software development, and tie your identity to an open source project, it is de facto professional.

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.


> And this seems like a perfectly personal thing to do with something that's preventing happiness.

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


> These kind of entitled attitude

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.


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

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.


Lets compare it to an other type of volunteer based work, after school activity for kids. Some of those are going to be free, run by people who volunteer (usually other parents), with disclaimer policy that say that any responsibility is on the parent and no liability may be put on any of the volunteers.

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.


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

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?


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


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

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.


> Open source authors promised us nothing and owe us nothing

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.


> either express or implied

Did you miss this part?

kjs3 31 days ago [flagged]

There is such a thing as an implicit promise, but it does not trump an an explicit disclaimer of such attention. Which there is in this case. Once again, thanks for demonstrating the entitled attitude that brought this on.


Would you please edit personal swipes and/or snark and/or name-calling out of your posts to HN? Between this and https://news.ycombinator.com/item?id=22080698, you'd done this more than once in the thread. We're trying for curious conversation here, not flamewar rhetoric.

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.


Or to put it another way:

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.


The repo has not been deleted! https://github.com/fafhrd91/actix-web


From the bottom of the postmortem repo:

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


so it's not deleted. it's the last call for all the people that wanted to profit from his work to take up the mantle and drive the project

something anyone can do right now, I would add

but people just prefer directing the guy work


I don't see why.

Anyone that cared already has their local repository copy.

After all that is what DVCS are all about


Issues and pull requests are often useful documentation (for open source projects, sometimes the only documentation), links to files and lines of code are now broken.


That is what happens when one outsources everything to Github.


This would have happened identically even if the project had its own hosting, so outsourcing hosting to GitHub isn't a factor in this case.


Lkml doesn't seem to have this problem, and they are the original git users.


So all you need to do is get popular and important enough that several unrelated third parties will mirror and host your communications for you.


Or... publish everything as essentially a log in an openly accessible manner (ie. email as a on a list serv with it's web accessible archive), and places like archive.org will happily squirrel it away for you.


I wouldn't happen if instead of git, they used fossil.


It seems like the only "Fossilhub" is this: http://chiselapp.com/

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


Fossil has everything built in including fully functioning web interface (in contrast to git).


If you want to rely on some code that it takes even a second of your day to think about your response to author deleting that public code, then you fork it and simply track author's repo.


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

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


Yeah, that's really the core of the problem, isn't it. People trying to impose an implicit understanding (which is nothing more that 'this is what I want the world to be like') when there's an explicit statement of 'this is how it actually is'.

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


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


No, that's not the converse. The license says exactly what it means, which is:

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.


To assume certain conditions that are not explicitly laid out without even talking to the person providing you the service is literally entitlement. It seems like you've made assumptions that turned out wrong. I've fallen for it too in the past. Not everyone thinks the same thing so people's assumptions are always different. The key thing is, when your assumptions don't turn out true, to learn from it.

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.


Exactly. The open source community is far from homogenous, and people who engage in it (maintainers, packagers, <s>leechers</s> users, etc.) tend to have wildly different expectations that vary from person to person. I’m sure RMS, some Contributor Covenant wielder and I won’t ever agree on a set of assumptions.

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.


No you don’t. You aren’t alone in assuming that, but it’s an entirely unreasonable expectation. And as evidenced by this exact thread, people like you cause good developers to stop maintaining their projects. Your attitude harms our community.

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.


Cool, you don’t have to work in the project if you don’t want to. But going and nuking it off the face of the earth so nobody can have it is still impolite.


It's good that git clones are all complete, full copies, including history.


But they don't have the issues nor pull requests that were open when the repo disappeared.


Should have used fossil :)


And for that I am quite thankful that it is so widely used.


Strongly disagree. For me, what's implicit is that any software, commercial or F/OSS, can be abandoned at any time - because that's just the way it is. A remedy would be to use software coded to a specification with mulitple implementations such that in case a project folds, you might be able to switch over to a different implementation. The Java EE ecosystem used to be like that until around 2012 or so.


> what's implicit is that any software, commercial or F/OSS, can be abandoned at any time

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.


Good examples


Abandon is different from deleting 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.


Not deleted.

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


That's very much a "Not deleted _yet_"


With distributed version control, is anything ever really deleted? How does he have the power to delete everyone else's local copy of the project and prevent them all from forking and maintaining it?



I see thanks


I've never heard of "implicit promises". For me a promise is by definition explicit. Anything else are assumptions, in this case false assumptions.


In many contexts, there’s often an implicit promise to be courteous to others, even if it’s not defined explicitly.


From my skim of the maintainer's comment, this happened because people didn't keep their end of the promise.


I, and most people reading this, likely never interacted with this person. From where I sit, this is what's colloquially referred to as a "dick move".


“Implicit promises” is going into my Orwellian dictionary. What a farce, do people really believe such a thing?


It’s strange that you’re unfamiliar with the term. It’s an important concept in legal contexts, and the same general concept applies in all sorts of situations where people make reasonable inferences about other people’s behavior. It’s even called out as a real thing that is then explicitly denied in many OSS licenses, because otherwise such implicit promises might have legal implications.


Yeah, no.

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.


I do not think these expectations are reasonable. This line of thinking is definitely the core issue of the problem.


>If you offer code to the public – and present it as an active, dependable project

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.


> you implicitly promise and signed up for

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.


A large amount of human interactions work this way. It's fuzzy and messy, with many shades of gray, but the world is filled with implicit promises with varying degrees of commitment and severity.


Well sure.

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.


> professional behavior is exactly what you implicitly promise and signed up for.

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 think that's made pretty clear in pretty much every open source license: "Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND".


That’s a legal, not a social statement. Following the letter of the document that governs your work doesn’t mean you still can’t do something that would be inconsiderate.


I am honestly confused by this line of thinking. what should projects do in your opinion? should there be a LEGAL-LICENSE and SOCIAL-LICENSE?

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


Legal documents don’t really make an affordance for what would be impolite versus what would be against the license. Usually I think the unwritten expectations work out ok (for example, in a project I help maintain I recently wrote out an apology for stepping away from development and ignoring contributions to fulfill these obligations) but perhaps writing it down in some sort of Code of Conduct style document might be beneficial.


I think that people have pretty much put their "core values" into their licenses these days. People who don't want Amazon to run their software as a service use the AGPL. People that don't really want an open source project but want to put "open source!!!11!" on the box add caveats like "you can't run this code on a device you didn't buy from us" (very common in the keyboard firmware market).

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.


> you should immediately make that clear, front-and-center, to any current and future users.

like, for example, in a license file?


Is it entitled? Most would agree, "very" (but that's not my concern nor judgement to make)

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.


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

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.


Now due to that comment actix maintainer has disabled issue too. I don't know why people show such attitude as if they are paying him to do opensource.


In open source you give and take. The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work. 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 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.


> The actix author almost certainly (unless they deploy their own kernel)

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


When you hold the door open for somebody you don't sign shit, yet it's implicit that you don't swing the door in their face.


But you don't hold a door: you are dropping a package on the street and letting people pick it up. Anyone can reuse the cardboard, paint it red, stack it up with other packages, or hang it on their livingroom walls... but there is no guarantee that the package won't contain a bomb, that the cardboard was made by eco-friendly methods, or that it will last one second after getting dropped on the streets.


That's the bare minimum of what you can do, which really just constitutes dumping your code on GitHub, slapping an unmaintained label in the readme, and calling it a day

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


Lawsuits is how society distinguishes the actual social contract from wishful thinking. You are free to establish your own imaginary community based on imaginary rules of etiquette, but everyone else is free to ignore such "rules".


Sure, but people whose behavior is only constrained by law rather than the general expectations of good taste in their community are generally referred to as assholes or with some similar term to indicate that their behavior is disapproved of but not to the extent that it would make sense to prohibit.


Yes and pushing the archive button is saying "I won't produce any more packages sorry."

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.


No, he didn't break into people's house, started their computers and started deleting stuff. It's all the same as the day before yesterday.


Except for they didn't simply push a commit which replaces the code with a readme that tells people to go maintain it themselves or fuck off, they emptied it, rewrote their history and did a git push --force.

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.


No, he just stopped dropping the package on the street every Monday at 7am. Whoever picked up the package in the past, still has it - or had the option to preserve it.

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.


Yeah there's this common concept in society called trust, aka a social contract, that people don't advertise their stuff first only to deliberately screw you over.

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!


Caveat Emptor.


"The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work."

Prove it.

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


>> Prove it.

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.


Once it's public and people depend on it you can't retract it like that. His goal was to make his work public, not private.


You basically can. The cost of free stuff like this is "be nice to the guy giving it to you" or at least don't be actively abusive about it. If the community won't pay that price, expect it to evaporate.


> The cost of free stuff is "be nice to the guy giving it to you".

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


This goes both way though. Be nice when people submit patches especially when you reject them.

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.


You can retract it. He just did it. You can take down any webpage under your control. I could delete this comment later if I like. You could delete yours. etc.


> I could delete this comment later if I like.

Now you can’t.


The point of open source is that people can maintain their own forks etc. There's plenty of mirrors of actix I'm sure.


Why?


It’s no longer “his” code.


In open source you give and take. The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work. 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 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.


Dude, sorry to break this to you! But basically any widely used software is supported by major companies just to avoid this problem.

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.


Companies should contribute their fair share by supporting open sources projects monetarily, definitely!

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 believe we should not demand free work from people only because they were nice enough to push their code on GitHub and let stranger use it for free.

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.


To take the metaphor from a different user on this topic: "Its completely ok to not hold the door open for someone, but its extremely impolite to drop them into their face."

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.


> has profited immensely from other peoples work

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.


Making a profit != profiting.

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!


> Making a profit != profiting.

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.


From your source:

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


Whatever drawbacks Actix may have had, this entitlement has gone too far. There is no defensible reason to tell someone "never write Rust again" because you don't like the code they're making available to you. We need something to remind us that we should be civil and grateful for FOSS contributions.

I recently saw a talk by Atwood about good discourse and how you should remind people of your values before they write their comment, which I think applies here. I'm going to make a single-page website reminding people that FOSS maintainers are volunteers performing a service to everyone else, and that we should keep that in mind.

If nothing else, it'll be an easy think to link people to in my issues sometimes.

EDIT: It's going to go up on https://www.osscoc.com/


"We need something to remind us that we should be civil and grateful for FOSS contributions."

You mean like having the legitimate risk that maintainers will take their ball and go home when people are cruel and others stand around and let it happen?

This is everyone's fault who didn't dogpile the people who were being terrible. We all need to be calling out people being horrible, and provide a little emotional support to maintainers. We worry too much about the feelings of people who contribute nothing, and not enough about the people who build the things upon which we rely.


No, I mean something less remote and which looks less like a random act of God, something that people can read before engaging in discussion and not easily dismiss because "it probably won't happen". We need to raise the level of discourse across the board, not just prevent the most egregious of negativity.

I want people to enter the discussion with the mindset "this is a volunteer effort so I will aim to be productive in my disagreement", rather than "fuck this guy".


Ahh, yes. That would be fantastic.


> "This is everyone's fault who didn't dogpile the people who were being terrible."

That presumes that "dogpiling" would actually stop the behavior, rather than getting people to dig in their heels and further inflame tempers.


Even so, it can serve two purposes: the author feels defended and acknowledged and the author feels relieved as the heat is, at least temporarily, directed at someone else. And this is the worst case scenario.


The author feels defended, but the subject of the dogpiling feels attacked. Maybe that leads to deescalation, but that's far from a foregone conclusion. Bullying bullies often further normalizes the act of bullying in the eyes of the bullied bully, as well as potentially normalizing bullying in the eyes of observers.

There are better ways to handle situations like this.


> how you should remind people of your values before they write their comment

That sort of thing doesn't work, even if it's shoved in people's faces. The only viable solution I've ever seen for enforcing community standards is to suspend or ban people who violate them. Otherwise, you'll always have trolls and people who want to see you fail looking to poison the well.


> We need something to remind us that we should be civil and grateful for FOSS contributions.

Sort of ironic that the entire commotion started when the Actix maintainer dismissed a contributor's code as boring after they wrote a POC and a patch for a use-after-free bug.


>I recently saw a talk by Atwood ...

Interesting, if you could share a link or some other source me and my dinner would appreciate it :)



Thank you!


Open source maintainers have a hard time - especially when they're under criticism and receive zero positive vibes. Author mentions it, here's the excerpt:

Be a maintainer of large open source project is not a fun task. You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help.

This a big problem with open source - I, as a programmer, like when someone commends me. It might be childish, but if I invest a few days into code and someone finds it useful - I would love to hear it, it would make the day for me. Instead, I had similar experience like the author of actix - hatred, rudeness and a lot of people who don't read the docs, they merely expect everything to work if they drop the library into their project.

Sadly, we're way too negative and don't appreciate OSS maintainers. This trend should change. It's sad to see yet another project go because author was mentally drained due to negativity. We should take care of our own "brothers in arms" (we all write code or deal with tech, don't we?).

I haven't used Actix-web, but I can sympathize with the author. Keep your head up, recharge your batteries and remain creative. Good luck with your future products!


A data point: I've been involved in Open Source for 10+ years, developing projects myself, helping to maintain very popular projects, contributing, and I don't see a trend like this. I've interacted with hundreds of people over the years, and the vibes are overwhelmingly positive; I haven't noticed any hatred or rudeness towards myself. I can't think of a single time interaction with OSS people afected me negatively, but there were a lot of positive (or neutral) interactions.

Over time projects I'm contributing to were changing, and so I was exposed to several different communities (Python web development, data science, web scraping), and all of them turn out to be awesome. Maybe that's just luck, but not all OSS maintainers have it hard - no idea why :)

+1 to recharge the batteries!


Yep this is why, more and more, developers are simply doing private repositories. They might exist on GitHub. Or a torrent or something. Rachel goes into more detail about them here.

Basically people fix things and don't commit them back upstream because doing so is too much of a political headache.

> While it's probably true that the dictator does suck at design, the talented user wants no part of the drama which would follow such a report. There is absolutely no benefit to lighting that particular fuse. And so, the problem is never reported, and the patch is never conveyed upstream. It effectively becomes a private fork limited to the talented user's systems.

https://rachelbythebay.com/w/2018/10/09/moat/


I've been thinking for a long time that one of the problems with these online shitstorms is that the adults in the room are silent. It would have been so much better if the senior people in the Rust community stepped in to actually say "Hey, we're all using it, yes it's got issues, but thanks for your contribution and don't worry about the idiots". Instead we've got senior people in the Rust community waiting until the damage is done and then hand-wringing about it afterwards.


It's a tricky balance. This is also sort of where I was getting at in my post with the "unofficial" bit; because /r/rust is not official, we do not look into it. And because this happened on Reddit, there was no real opportunity to actually step in. It's quite possible this is simply a failure on our part.


Today is the first time that I've heard that /r/rust is apparently regarded that little from the Rust team. To me it's the most important online gateway to the Rust community, and also the best resource to stay up to date with the ecosystem.

I knew that it was an "unofficial" channel, but given that it's most likely the single biggest aggregation of people in the Rust community, I always assumed that the Rust team would consider it of close to equal importance to users.rust-lang.org.

> And because this happened on Reddit, there was no real opportunity to actually step in. It's quite possible this is simply a failure on our part.

I don't think that much could've been done to prevent that. It also happened on such a quick timescale that one could've completely slept through the whole situation (from the initial Reddit comment to the post-mortem).


Unofficial subreddits are hard to reason about. Within the context of reddit, they are still the most official place to talk about a thing they like. And even worse, those are the people likely to only interact with the "community" on reddit, forming an echochamber where they think the unofficial subreddit's opinion is some sort of majority.

In rust's case, it probably is worth diverting some of the existing manpower for moderating online discussion to reddit. I think that the harsher this moderation is, the less attractive the subreddit will be to the reddit-only echochamber, as an added bonus. But this is only possible because you already have people involved with online discussion on other sites. In most cases, if reddit or twitter keeps talking about you and keeps saying dumb stuff, you just have to ignore it. This is how r/competitiveoverwatch is treated; everyone knows that the stuff they say there doesn't matter, and that they don't represent more than a tiny fraction of the people watching the OWL matches. Even some of the people posting there know it. The players and casters still seem to read it, but for the most part just laugh about how dumb their opinions are.

In this case, I don't know why the maintainer took some redditor's comment so seriously, when they said that they should not write rust anymore. This is just a separate issue that anyone with "fame" has to deal with, ignoring critics who are idiots, nothing to do with reddit really.


Evan Czaplicki (Elm designer) has a great talk about this issue "The Hard Parts of Open Source" https://www.youtube.com/watch?v=o_4EX4dPppA


I don’t want to come across as toxic myself, but I think that the toxicity that Evan sometimes has to endure from people in the community is somewhat self-inflicted.

Last year I wrote a web application in Elm. Even though I really liked the language and had lots of fun writing code, I noticed that the users effectively have to rely on Evan to make any meaningful progress. The ‘forkability’ of the project is very poor.

To give you a couple examples of that:

- Elm has a centralized package repository: https://package.elm-lang.org/. There is, however, no functionality in Elm to host your own registry, whether it is public or internal to your organisation. The monolithic compiler/build tool hardcodes the URL of this registry.

- Relatedly, there is no way you can easily fork a package and apply some changes, especially if you have no intent to host it through the official package collection. There is no way to say: “I want to use elm/http with this tiny local patch applied that I have sitting in my tree.”

- Some parts of Elm’s grammar/intrinsics are only permitted to be used by packages with author “elm” (i.e., the official core packages). This means that you cannot fork, say, elm/bytes to yourname/bytes and make local changes, as it can no longer be built.

Because of this, the maintainers of Elm don’t just decide what goes into the tree, they effectively also decide what users may do on their end. They are the folks sitting behind the master control panel and people filing issues/pull requests rely on them to push the buttons for them. I can understand why this causes friction within the community.

Note that this was my experience using Elm early 2019 (January-April). It may well be that Elm improved in these areas since.


Similar experience. Some OSS users have some very entitled mentality.


I use to do a TON of open source back in the day. i quit cause of the same reason, people suck and feel they are entitled.

i couldn't count how many times someone would yell, kick and scream about an issue they were having and demand that i fix it right away (ain't gonna happen dude). i finally got to the point where i told people that i would only participate in pull requests and nothing else. you could still file issues, but i wasn't gonna even look at them. if you wanted something fixed, open a pull request and i will help you fix it but i'm not wasting my time with an issue that i didn't personally have an investment in. was i being a jerk for doing that? maybe, but my own personal serenity was worth more to me than pleasing you.

i think every open source author starts out with this fire in their heart to make the software world a better place for everyone only to get beaten down by every moron out there. when you are getting paid to do something, you put up with the idiots in your life (how many of us are still at the job that pays well, but HATE the people there?), but when you are doing it on your own time and not being compensated for it, what's the point?

i applaud this dude for doing what he did. i hope his actions has put the people using his project in a position of panic to the point where they reflect on how they treat people and participate in the open source community. pain is the only way we learn and change things about ourselves. i hope the people who caused the author to quit open source change the way they treat people in the future.


Maybe it's because I work on more niche projects, but every time someone contacted me about an issue in one of my repos they were always exceedingly apologetic about "bothering me". My projects only have ~400 downloads per month, so I'm sure it's a matter of sample size. If anything, working through issues with the community has made me enjoy the work more.


Yeah, it's important to remember that most of the time people are very nice.

Of course there are "problem kids" out there who screamd about an opinion they disagree with or tries flirt with female contributors on IRC..

Having co-workers, a code of conduct, and a community organizer you can escalate to can help a lot.


We are all on notice. Be nice. Support and protect the people contributing to the world... or write it yourself.


For context, this comes after yet another unsoundness bug has been found in Actix-web. Normally people in the Rust community don't get very worked up over these because we know that everyone makes mistakes, but the Actix project has had a consistent history of introducing unsoundness through the use of unsafe for dubious reasons like nebulous performance increases or bypassing Rust's safety guarantees (which is what this last one was about). Furthermore, when someone raised this issue and provided a patch to fix it the actix-web maintainer called the patch "boring"[1]. He also censored comments that talked about the unsoundness and eventually deleted the entire issue. This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem.

[1] https://web.archive.org/web/20200116203731/https://github.co...


I completely disagree with your last sentence. Think of actix-web as a gift to the world (and judging by its popularity, a very nice gift). Being verbally abused by vocal majority of freeloaders would drive anyone furious.

I think I understand your perspective, though. It would benefit the community to have projects of great importance properly maintained. How to ensure it? Well, by paying people to do it, not necessary developers but active project mantainers. Only then you are entitled to complain about somebody doing a lousy job. To sponsor it, introduce micro-transactions for dependencies.


Obviously being vocally abused is not OK no matter what the victim has done. This is a big problem and I think Steve's article that is currently on the top page of HN gives a good overview of that part of the situation.

My problem with viewing all open source as a gift to the world, take it or leave it, is that when people create open source packages, market them as being ready for production use and as the best option for said production use, and then act unprofessionally towards security issues and reject patches that fix the security issues for no reason other than being "boring" and "not creative enough" people should be able to call them out on it as unacceptable behavior for an open source maintainer. If actix didn't claim to be production ready and instead stated that it was an experimental code base designed to advance the state of the art in web server performance I wouldn't have a problem with how it was managed. However, once you claim that something is production ready I think you need to be ready to take responsibility for it.


I strongly disagree, with extreme passion.

They could have marketed it as the greatest gift to humanity for all I care. It's your responsibility to handle your use of code. Sure, you may find issue's in your dependencies, and you're welcome to submit a bug or provide a fix, but if you expect anything more than the code as it is, it's still your problem how to deal with it.

The entitlement is astounding. A person providing free code doesn't owe you anything or "need to take responsibility" or whatever else you may want.


While that's true, expecting bad maintainership to not have any effect and third parties not discussing about the quality of the software is also delusion. (And in practice, maintainers maintain, and I'm glad they do, because otherwise e.g. Linux distro would be complete absolute crap.)

What is also a in the realm of possibilities is that a project gets a bad reputation and for indirect effects or others, dies. That happened here. However, in the effects we saw here, while the people proposing patches and debating in a civil way about technical flaws (or at the very least widely perceived as such) were fine, the brigading was absolutely inexcusable, as well as the unproductive/nasty comments.


And we yet to see any actual real-life problems with these "unsoundness" problems. Most of these issues raised in Actix were about theoretical problems.


You say, "This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem."

Or what? What's the "punishment" here? Who's going to decide what's acceptable, and what's not?

Seems like you are demanding that the author of Actix do what you want.

Sometimes people take their football and go home. In this case the vocal complaining minority are free to make their own copy of the football, and proceed on their own...which is also known as "put up or shut up".


Or he will lose the reputation, that's what.


> This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem.

And the better solution wouldn't be to harass the guy, but to recommend and try to move the ecosystem away from actix.


> but the Actix project has had a consistent history of introducing unsoundness through

Then you can stop using Actix and create a better project or fork it and fix these unsoundness bugs and call it ActixSound. I do not see the point to rally up the crowd and raid his Github in the name of soundness. This reflects poorly on the Rust community.


>Actix project has had a consistent history of introducing unsoundness through the use of unsafe for dubious reasons like nebulous performance increases or bypassing Rust's safety guarantees

sounds like the author had specific strategic vision - "push the boundaries" - which he clearly explained, and there are other people who don't agree with such an approach, both are valid positions in their own right, and instead of being jerks and trying to shove their approach down the project owner's throat these other people should have just started their own project reflecting their more conservative approach.

It is like those people who try to push Linus to use C++ and do other funny stuff in the kernel - one should go and read Linus' responses to the people like these.

http://harmful.cat-v.org/software/c++/linus

"Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.

[...] I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with."


I’m not sure why people are so fork-shy. Forking is the greatest gift of open source. It’s basically the point and the core of what it means to have software freedom. I think the anxiety around forking is unwarranted, especially in scenarios where the author clearly has divergent goals and values from a large number of people.

It seems the forest has been lost from the trees: exercise your freedom, fork, and let diversity lead to longevity. I think a lot of the aversion is because forking and fragmentation is messy. It doesn’t surprise me that the Rust community in particular would abhor such disorder :) (see the JS community for a counter example.) But such disorder is a key element of so many good human systems, like democracy and free markets. Better to embrace them and relish the freedom they bring, than dive deep into conflict with others only due to imagined chains binding you together, chains deliberately lacking due to the selfless altruism of the project creators who bound their work to a free software license, to whom you should be thankful, not resentful.


This whole issue is confusing to me. It's like no one ever heard of fork. It's hardly mentioned in the comments. The author owes people what they paid him to do, which is nothing. If he wants to go unsafe and fast that's his business. I don't have to ride with him. I can make a copy of his car for free and drive it the way I want.

I think this is a case of the end justifies the means. The end: get the maintainer to change his code the way I want. The means: bully and abuse him to force him into it because that sometimes works.


At some point open source got morphed into being about free as in beer and gratis volunteer work by generous souls. But its origin and what the licenses themselves are about are freedom to read and freedom to modify. The entitlement that has crept in and the social contracts that seem to have formed around expectations for people writing Free code are concerning.

Shame on people who forget this, and demand more than those freedoms from authors who so generously grant them to others. Based upon what I’ve read, I would have checked out from this project as the author well before they did given the harassment they’ve apparently been getting for not merging PRs into their repo.


I'll save this link for the next time someone tries to argue that the Rust community is somehow "more welcoming" than some other X community.

All internet-based communities contain some assholes. All of them. Sadly some maintainers don't seem to have the werewithal to tell them to go away. I mean, when you get "asked to change coding style", it's the time to put the banhammer down, because there is no way to please these people without humiliating yourself.


> I'll save this link for the next time someone tries to argue that the Rust community is somehow "more welcoming" than some other X community.

It's deeply disappointing to see this outcome (and r/rust is literally divided into two halves on this drama at least for now, ugh), but I believe it is the statement about the average atmosphere. Not that I have an argument for or against the refined statement, but it doesn't automatically get rejected with a single counterexample.


Nah, it's just the usual delusion of small-but-growing communities. The Python community was great in 2001, a bit less so these days. The Lisp community was probably great at some point in the '70s too. It's just that, with size, the likelihood of attracting undesirable elements inevitably grows until their presence simply cannot be denied. At that point, you either deploy heavy-handed moderation and get branded "unwelcoming" by the assholes, or leave it free for all and get branded "unwelcoming" by the most sensitive not-assholes. Then someone or something will spawn a new community, and the cycle will repeat itself.

This process is basically inevitable, and it has been observed in internet communities for so long that it's basically a science by now. It's just the nature of the (human) beast.


Of course I don't disagree to you, I too think that that reputation is extremely hard to retain. However:

1. It seems that there are/were some language communities noted for their relatively more welcoming atmosphere. If small communities are usually great until it aren't, why don't we see many such communities? There seems to be some truth in this (albeit ultimately fragile) reputation.

2. For this reason, in order to claim that some community is no longer what it used to be, you need multiple anecdotes at the very least.


If a small community is great and the tool they push is valid, it will grow until it's not great anymore. Try mentioning any tool that has grown in popularity, stood the test of time, and still has an exemplary community.

If a small community is great but the tool is not particularly good, they will stay small and simply get ignored. That's the average scenario for most languages not pushed by a wealthy vendor: you just don't hear about them because you don't need the tool.

> you need multiple anecdotes at the very least.

Meh, this is just the first of many to come, if Rust is to keep growing in popularity. It's on the same trajectory as Go, just a bit behind because it got usable a few years later.


> Meh, this is just the first of many to come, if Rust is to keep growing in popularity. It's on the same trajectory as Go, just a bit behind because it got usable a few years later.

If you originally meant that the Rust community is on the way of becoming less welcoming, well that works for me.


Re 1, if they're small communities, you don't hear much about them in the first place. And if it's a language community, then the language is probably pitched long before the quality of the community comes into question.

That is, I've never heard anything about the communities for zig, D, beef, futhark, pony, Julia, etc.

But then, I don't think ever seen any comment on their community... Their supporters are too busy trying to justify the language's existence!


Well let me the first to mention Julia’s community. Especially on the julialang slack channel, the community is excellent. It’s incredibly friendly, welcoming and helpful.


I’d argue any community that crosses Reddit and Open Source would cross this issue eventually - it’s not necessarily a Rust issue.


Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: