Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
A Sad Day for Rust (steveklabnik.com)
1243 points by pjmlp on Jan 17, 2020 | hide | past | favorite | 991 comments


The earlier related thread is https://news.ycombinator.com/item?id=22073908.


I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all.

I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what Actix does should use any unsafe code at all, so I didn't use it.

When I later saw the way the maintainer responded to well-meaning bug reports, including patches, that validated my decision.

There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.


I hit a same conclusion about a popular framework (that shall remain unnamed) on a different platform a few years back.

It feels like it should be simple: I disagreed with how the maintainer was doing things, so I decided the package was not for me. No need to hassle them about it. I wish it could be that simple.

Instead, I had to weather a fair bit of defending my choice to use a different, less popular option, and there's apparently no honest answer I can give that won't be taken as an attack on the framework or its users. And refusing to engage with the question is, of course, rude.

I'm finding that Internet culture wears me down, these days. Even when you don't go looking for flamewars, they come looking for you.

With less-popular libraries, it's easier. Open an issue, say hi, make sure the maintainer knows what you're planning on doing, do it, learn a few things, have a nice day. Once or twice I've been asked to more-or-less rewrite the patch because the maintainer didn't like something about my coding style, which is also fine, and often a good way to try a different way of doing things on for size. It's all pretty benign. But popular, well-known projects have this way of getting political.

I suspect that the worst thing that could possibly happen to one of my labors of love would be for lots of other people to like it, too. A few people, great. But I don't want my free time to become Internet politicized.


Part of using any piece of software, professionally or privately, open source or commercial, is assessing how well if will meet your needs now and in the future, and possible complications you might anticipate.

Doing this well and thoroughly is extremely hard, and commercial enterprises spend a lot of time and money doing so (or pay the equivalent of insurance to not worry about it). Doing a minimal amount of research entails doing what you did. Look at the current and past state of the item in question, and decide whether it's worth putting the significant amount of time and effort into using it.

I can't help but feel the vast majority of people complaining failed to do this minimal amount of legwork. They're upset about their lack of forethought for what they view as a bad investment, but that's on them. Unfortunately, I find people often have a hard time accepting blame onto themselves, but feel there is blame to be assigned, and so it needs to be directed somewhere.

They say don't look a gift horse in the mouth, but if you are responsible for dealing with whatever diseases that horse might introduce to your stable, or even if you are just legally obligated to deal with the care and feeding or removal on death of such a large animal, you definitely look that horse in the mouth for red flags.


I don't like contempt culture either but there's a balance to be made here - if you let everyone do everything and encourage them all as special snowflakes that can't create anything crappy, a community will also go to shit.

In this case it does sound like people initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty.

The fact that the author deleted many of the linked issues e.g. https://github.com/fafhrd91/actix-net/issues/83 really feels like he is playing the victim here and taking everyone for a ride, denying his own responsibility in all this drama that's unfolded.

Yes a community should be open and forgiving, but blindly forgiving someone who doesn't even admit their own mistakes, who doesn't even understand what they are being forgiven for, is naive and also will result in community destruction.

I also don't buy the "if you don't like it just don't use it" argument. If it's actively dangerous and you know this, and you know that other people don't know this, you do have a responsibility to (politely) inform others about it. Simplying "not using it" is plain negligence.

[1] "the patch is boring", LOL WTF I would never have even come up with something this insulting even when I wanted to actively piss someone off, kudos for imaginativity


> initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty.

Yes, nice comments such as

>seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?

and

> Never write rust code again


That was after the author was extremely dismissive with "this patch is boring". Seriously, who says that??


And that still doesn't justify harassment. If that person said any of these things to the maintainer on HN, the mods would shut them down and for good reason.


Saying someone's "patch is boring" is also harassment.


> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.

Also, you can change your copy of it to work the way you want, and if you decide to share it, other people can choose to use your version if they like it better. You don't have to bully other people to get your needs meet, individually or collectively. These are among the core benefits of open source.

Probably in this case most people would have ended up using the less-unsafe fork of the project, and the original author would have tried harder to extract the potential performance benefits of his more-unsafe version, while both groups constantly learned from one another. Everyone would have benefited.

I've written a bit about the history of some such friendly forks at https://news.ycombinator.com/item?id=22080672


I wonder if authors consider "friendly" forks to be friendly ...


The XEmacs fork I mentioned had some bad feelings attached. As far as I know the other examples I mentioned (Stackless, swap-to-NFS, LuaJIT) don't. But it doesn't matter what authors think. What matters is what helps the users. Would you ask for Newton's approval before calculating a planetary trajectory, or Kalashnikov’s before designing an automatic rifle? Their achievements matter precisely because they empower everyone, for better or for worse.

Emphasizing authors’ feelings in this way has the effect of diminishing their software from a contribution to the intellectual heritage of humanity to merely a service like delivering a pizza. Don't forget to tip your waiter!

Of course you should be nice to authors if you interact with them. But the whole point of open source is that you don't have to interact with them unless you want to.


Actually I agree, I wasn't trying to emphasize their feelings as much as question if there is really such a thing as a friendly fork. In reality it shouldn't matter and the concept be void, if someone forks your project and it is successful you should be glad you don't have to anymore and can do something else, as well as benefit from the improved software.


If you like what they added, you can merge it into your version unless they chose an incompatible license for their work. (That's one reason the GPL is so important: it prevents such incompatible licensing.) So if the forks continue unmerged, it likely signals some kind of difference of opinion: perhaps over technical quality, perhaps over tradeoffs, perhaps over licensing. The humans frequently turn such differences of opinion into chimpanzee factional dominance games similar to football, but in principle there is no need for that. I don't know of any LuaJIT users denigrating the hygiene and ancestry of PUC-Lua users, for example, nor vice versa, but surely it has happened on one occasion or another.


Fighting over "who gets to donate their time for free" is absurd. Unless you are one of those pretend open source companies that sell commercial versions and prevents certain cloud based usage.


Yes, but most things the humans do are absurd.


I think that probably depends on the nature of the words exchanged before the fork. Many forks happen after nasty comments have been thrown around.


This is the standard voice vs. exit dilemma. Rust community is, for better or worse, very worried about "fracturing the ecosystem" so they generally prefer voice. Well, some of these voices can get ugly.


Or fork the code. That's the great thing about FOSS.


This could have solved a lot of problems...


and introduce new flamewars about "Not-Invented-Here", why don't you contribute to a common codebase, ffmpeg vs libav/avconv debacle.


ffmpeg / libav had lots of bad blood long before the fork, which might have been the real driver for making it a "debacle".

GitHub in particular has a "fork" button to make it super-easy. So fork, do your edits. If you want, make a pull request with the original project. If they take it, great: the fork can cease to exist.

If they don't want to merge it don't take it personally but go your own merry ways. And this is what didn't happen with actix.


Forking if it's mature and featured enough to justify it, but it maybe too unsafe broken to invest in rewriting large swaths of code. That's the perpetual trade-off of engineering decisions; whether to build, fork or buy.


I'm curious what you'd recommend instead for async pgsql requirements as a Rust web framework. Actix seemed interesting, but I didn't know about the masses of unsafe. These too eliminate it, because it'd be able to crash/break a cluster that uses deliberate unsoundness for its serialization/deserialization needs in the vain of speed (timely-dataflow), allowing memory issues to spread (at least in theory)... I thus can't use a framework that uses this much unsafs/has known stray pointers or similar bugd/issues.


We use tokio-postgres. Previously we had our own connection pool implementation, but we recently switched to deadpool.


Thanks! The pipelining is just really important to get proper performance out of CockroachDB (mostly due to network and coordination overhead due to it's cluster architecture).


What do you use now? Warp?


We just use hyper directly, with a small amount of glue code to use serde_json, serde_urlencoded for body parsing and a very simple (and very fast) router of our own creation. This approach also made it very simple for us to introduce std-future/async-await in a gradual way.


I've been in the process of switching to tonic for the last few of weeks. Based on hyper/tower and has async/await support. It's a gRPC server rather than HTTP, so I've been using it with grpc-gateway to provide an HTTP OpenAPI v2 interface.

It has automated quite a few things I found dull to do in other server frameworks, from the gRPC .proto file I can generate:

- Rust server request/response types and request handler stubs. - grpc-gateway files and an OpenAPI v2 json spec. - Client side typescript types and request/response handlers from the OpenAPI spec.

So now the process of adding a new endpoint is much less time consuming and involves writing less repetitive and error prone code. As mentioned above I've only been using it a few weeks but so far it has been great, easier to use than actix-web and felt no less responsive.


Right now, if you want async/await, you either have warp or tide.

Hopefully gotham or rocket gets around to updating.


Gotham will be async-ready once this PR lands and the next release is published: https://github.com/gotham-rs/gotham/pull/370


Noice. To me, Gotham makes more sense because it depends on stable, whereas Rocket uses nightly. Anything depending on nightly seems inherently more fragile and un-future-proof (no pun intended).


Can anyone comment on how close Rocket is to a 0.5 release? I’ve been wondering for awhile, but opening an issue to ask seems annoying.


I don't have any insight but you can subscribe to this issue to see how things are moving: https://github.com/SergioBenitez/Rocket/issues/1065


I've been following this quite closely. Most of the work seems to be done. But development is very stop-start in fits and bursts, so it's hard to tell how much longer it will take.


as soon as I saw the large amount of unsafe code, I stopped considering it at all

So in that case you wouldn’t use any software written in plain C, right?


At the risk of projection, that comment reads to me as an attempt at playing gotcha.

It's not necessarily that unsafe code is categorically bad and nobody should ever use software that is written without strong static guarantees. It's that, in a language like Rust that has such a high level of compile-time checking, and whose community places such a high premium on it, relying heavily on unsafe becomes a red flag. It implies that the author of the code has a tendency to play fast and loose in a way that you might not want to welcome into your own codebase if you don't have to.

Where unsafe is supposed to be treated as a sort of pinky swear that says, "The compiler couldn't guarantee that this is safe, so I did," that starts to get scary, because any errors will undercut the safety guarantees that the compiler is supposed to be enforcing on your own code. And a large volume of unsafe code implies a large manual verification burden, and a larger volume of code that's easy to accidentally break. And the more of it that should be manually verified there is, the lower the chances that it is actually being manually verified. So it threatens to defeat the ostensible purpose of choosing a language like Rust in the first place.

That's not to say that programming Rust that way is wrong or evil in any objective sense. But it's something that needs to play into a decision on whether to take a dependency on such code. When you link code, you're inviting it into your process space, and you now have to accept responsibility for anything it does while it's in there.


relying heavily on unsafe becomes a red flag. It implies that the author of the code has a tendency to play fast and loose

It does not imply that. It might mean that the author knows what he's doing. Or not. We don't know without auditing the code.

defeat the ostensible purpose of choosing a language like Rust in the first place

The OP didn't try to choose a language - they tried to choose a piece of software that solves their problem. Seemed like the software was rejected on wrong grounds.


To your first comment, I hadn't intended there to use 'implies' to mean logical implication. There's room in the vernacular 'implies' for "or maybe not."

Though I think that we can trot out logical implication in response to your second comment: Considering taking actix-web as a dependency logically implies that you have chosen to write your program in Rust. Or, at least, the only language I'm aware of being able to import Rust modules is Rust.


> We don't know without auditing the code

or when you really audit the code, find a problem, submit a patch and then the author dismisses your patch as "boring"


Yes. I try not to use things built in C when there are other alternatives. Why? https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=use+after+f...


It is actually easier to introduce an undefined behavior in unsafe rust than in C, since rust use the guarantee that two mutable references living that the same time cannot aliase to optimize code.


I have to question your position from a moral standpoint though.

If you were a rollercoaster engineer, and you saw that a rollercoaster had an unsafe design, would you follow a similar approach? "I'm not going to ride that, but I'll let this line of people ride it without warning them." Obviously the stakes are wildly different, but still...


That is a false equivalence, roller coasters have far more material risk given human lives are at stake.


If you had discovered Heartbleed, would you have kept that knowledge to yourself so that you could minimize the maintenance burden on the OpenSSL develoopers?

Granted, no one died over Heartbleed but it caused lots of real people harm. We should start worrying about the well being of our fellow human beings long before their lives are at stake.


Well they didn't find any specific issues. Just the overall code looked not up to their standards as well as how the maintainer dealt with feedback. What do you suggest one does in such a case? Every time I stumble upon shitty open source code, am I supposed to fix it and if the maintainer refuses the patches, patrol the internet and try to prevent anyone from using it?


> they didn't find any specific issues

The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well. If they had done nothing, it would have attracted no comment. If they had allowed another maintainer to review and merge, it would have attracted no comment. But they went out of their way to denigrate the people who called attention to this issue, called the issue "boring", rejected the patch, then deleted the issue and all comments.

> Every time I stumble upon shitty open source code, am I supposed to fix it?

Your tone suggests that you don't want any part of this, so you continue along that path. I'm not going to convince you to start caring about your fellow men and women.


> But they went out of their way to denigrate the people who called attention to this issue, called the issue "boring", rejected the patch, then deleted the issue and all comments.

This is an unfair characterization of what happened. Here's another version: The maintainer did not denigrate anyone, he did call the patch "boring" (which isn't really an insult or anything?), worked on his own patch (without closing the previous PR mind you). People immediately starting shitting on the maintainer - within the hour - because the PR had not been merged. Maintainer chose to delete the issue to avoid it devolving into the usual mess. More shitting contest happened here on HN, on Reddit, and elsewhere.


I would like to believe you. But without access to the actual issue in question, I have no reason to trust your account of the events over nindalf's account of the events.

To me, deleting the issue instead of disabling comments or making read-only suggests mens rea on the maintainer that their actions were out of line and regrettable, and don't suggest an effort to de-escalate the situation.


> The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well.

True, but I (and I think the other comments) referred to the top level comment here, which is a guy who just felt the code was smelly and avoided it, without having discovered anything specific.

> Your tone suggests that you don't want any part of this, so you continue along that path.

Been there, done that. The amount of excuses and other bullshit is not worth my time and effort. If the project is on github I still do open issues providing repro or at least a stack trace if possible. But if you have your own bug tracker where I'd need to sign up first (most likely going through email verification) you've lost me. Same for when you start requesting I do a git bisect even though I provided steps to reproduce or start giving excuses for why this isn't an actual bug and I'm holding it wrong. I'll just stop replying immediately.


Yes, and you're making the same mistake that you're railing against: if you're going to invoke some sort of moral imperative to do something, you have to examine the risk of what can happen if you do nothing. In the case of something like Heartbleed, yes, the consequences of silence could be quite high. But I just can't see the same argument against remaining silent for this web framework.

It's also a matter of degree and thoroughness. There's a huge difference between "I've found a specific exploitable vulnerability in this security library and here is a proof-of-concept exploit", and "after a cursory look, I see this rust code uses a lot of `unsafe` and I'm uncomfortable with that".


There were specific issues found in this library. Soundness holes as a result of unsafe. And people submitted fixes. This person could literally have done nothing and it would have been ok. But they went out of their way to be terrible to everyone.


Seems like there was plenty of actual terrible to go around, and the language barrier made quite a few instances of not terrible seem terrible.


Agreed, we have a responsibility as a community to not cause harm and even take effort to prevent it. That is what I like about HN, it is a place where these things are discussed and as a collective, positive outcomes can manifest.


> Obviously the stakes are wildly different

This point pretty much invalidates your argument. When making a moral decision like this, determining the stakes and the consequences of remaining silent is a critical part of the moral evaluation.

In the case of the rollercoaster, silence could have deadly consequences for the riders. Not so much for the code. (Sure it's possible that someone might use it in a life-critical situation, and it could fail in a way that would cause loss of life, but assuming from the outset that this is a strong possibility is quite the stretch.)


Look up “Ergodicity”...


Okay... huh?


Failures of Actix will be “ergotic”; individuals experiencing the failure will be able to play again, experiencing the long-term average failure rate.

Failures of a roller-coaster are “non-ergotic”; individuals never experience the long-term average failure rate, since they’re, you know, dead...

This has got to be the most common and tragic type of mis-application of statistics I’m aware of; I know I used to do it all the time! Virtually nobody teaches/talks about it, but it is arguably more critical to understand than “causation vs. correlation”, or “post hoc ergo propter hoc”.


> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.

It works both ways. You put something out there, you need to be ready for the response. I'm not a Rust user, but presumably there was a reason other than charity that he put it out there (show off his brilliance, use it to get jobs, I don't know - but it was something he did for his own benefit). If you don't like that, don't make your code available to others, and don't complain if others act in a way you don't like. There's so much posted on HN about "open source entitlement". Well, the entitlement seems to run in both directions. That's the simple the reality of the situation.


I don't think "entitlement" means what you think it means. Unless you're arguing that people shouldn't feel entitled to be free of harassment, in which case I don't agree with you.

Yes, if you put something out there, you should expect feedback, and assume that some of that feedback is not going to be very nice. But that doesn't excuse the people giving that feedback for being rude. It doesn't excuse the fact that those people giving feedback have no inherent right to see that feedback acted upon, and expecting that is unreasonable and entitled.

I'm not saying I would have acted the same way the actix developer did (in my experience as an open source maintainer I certainly have some moments I'm proud of, and others that I wish I could take back), but I'm not so quick to condemn them, either.


Well, I'm using the dictionary definition:

entitled: to furnish with proper grounds for seeking or claiming something

example: this ticket entitles the bearer to free admission

Being an open source maintainer doesn't mean you're entitled to recognition or praise or deference. You're not entitled to put out low-quality software and have others pretend it's awesome. You're not entitled to make claims that are false and not be called out for it. You're not even entitled to people not trashing your work. When you put your work out there because you want to be praised, that's the downside.

"But that doesn't excuse the people giving that feedback for being rude."

That has nothing to do with being entitled (at least not in the context of an open source project). That's basic human interaction.


We all have to ask ourself which shape we want to give our feedback. You can factually say the same as the other guy, but send a very different message.

When you critizise someone for using unsafe blocks, there are many ways how you could go about this. This argument here is not about whether we are allowed to point out unsafe code blocks, it is about how we do it.

It is a tangible difference if your message is: "You are using unsafe there and it is not really needed, let me help" or rather: "You are using unsafe there without any reason, you idiot. Go away and never come back!"

And the thing is: only one of these messages will get you closer to safe code.


> Being an open source maintainer doesn't mean you're entitled to recognition or praise or deference. You're not entitled to put out low-quality software and have others pretend it's awesome. You're not entitled to make claims that are false and not be called out for it. You're not even entitled to people not trashing your work.

That's fine and all but you are entitled to control your own repo, its issues, pull requests, and related fora. You are entitled to set the acceptable standard of communications and if you don't like the way someone is communicating you are entitled to shutting that off.

See, entitlement works both ways: as a maintainer you're not entitled to a lot of things, but as users others are also not entitled to lots of things.


Well, you're totally missing the point then. When we say people are flaming, we mean people are providing "feedback" in a characteristically rude way.

You'd think that basic human interaction dictates not being rude to eachother, but internet history says otherwise.


> But that doesn't excuse the people giving that feedback for being rude.

From what I can tell reading the salvaged conversations, that feedback wasn't rude (IMO) up until the maintainer called the outside patch "boring" (which, IMO, was rude). Even after that, the "rudeness" was pretty mild.

The entirety of this drama seems to have been self-inflicted. Blaming "reddit" for the author/maintainer being unable to handle criticism or PRs doesn't exactly change that.


I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project.

No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them.

Of course, you could do neither, but don't be surprised when people call you out on it.


> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them.

It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right?

Your comment is precisely what entitlement looks like.


Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients:

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

Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article.

Here is the first one I clicked on:

https://github.com/algesten/ureq/issues/24

The maintainer is happy to get the report, and has an exchange with the reporter acknowledging the bug and how to fix it.

This all seems a very civil, mature way to address issues with open source software. Accept actionable criticism of your code, and strive to make it better. As a developer, I know having other people test my code and report problems back to me is one of the best ways for them to help me and my code improve!

I think identifying to your code to the point where you consider criticism of your code an attack on your personal identity demonstrates a real lack of maturity.


You might have missed a couple lines. It's easy to miss as it's right below the quote from the article mentioned: "This causes the now-usual Reddit uproar. It’s extra nasty this time. Some people go far, far, far over the line."

The issue isn't the article or the bug reports. It's the uproar from Reddit, and the extra nasty comments.

"Some people go far, far, far over the line."

There is a reason HN has guidelines for how to approach communication. It's because if we "go far, far, far over the line" and get "extra nasty" things devolve and this place becomes far worse. Rather than "toughen up" or "just not taking things personally," HN realizes that words matter.

Like I said, a couple lines easily missed or forgotten. It's not the bug reports. It's the extra nasty comments.


This could very well be thanks to the moderators, but I hardly saw any nasty comments on r/rust. People were critical of the actix maintainer, sure, but I didn't see anything that crossed the line. Some comments in the GitHub issues were indeed nasty, but those were actually called out on the subreddit.

There's no way for me to know for sure, but it seems as though Klabnik was exaggerating here.


The nastiest response I encountered was at the end of the GitHub issue thread, right before the maintainer deleted it. (He also cites it in his postmortem.) It said things like "you should never write Rust again," with very little substance.

The problem with the r/rust thread, AIUI, is less "far, far, far over the line" and more just a huge volume of the same sorts of criticism. It sucks to see such a response on that scale, but it's harder to characterize any individual's comment as "nasty."


Yeah, that comment on the GitHub issue was definitely over the line, but it wasn't on Reddit. The comments in the subreddit were higher in volume, but way more reasonable.


Well, I've certainly seen some nasty behavior in topics touching the async-std crate that I didn't like and thought should not be written. It felt really bad and was the first time I felt how this community has changed from the years I started writing Rust.


>> It felt really bad and was the first time I felt how this community has changed from the years I started writing Rust.

I agree. I'm further disheartened by a lot of the reactions that happened since. One of Rust's greatest strengths is turning into a weakness.

The Rust community needs to treat this cultural exploit as if it were a critical technical exploit and apply the same sort of objective and collective examination of source and insightful exploration of assumptions made about existing grammars and syntax and come up with appropriately safe and forward thinking solutions to ensure that the code of conduct isn't just a progressive cliche.


Here's the thing, though: you're looking at a very limited set of interactions (namely, n=1), and declaring that the developer of ureq is awesome and polite, and that the developer of actix is an asshole.

You don't know the history of either project, or either person. The developer of ureq probably has some bad days and responds in ways that their not proud of. The developer of actix has probably had some (many?) good days and responded politely and helpfully.

Indicting the actix developer given a small set of responses to a particular class of issues is a bit unfair.


There is a difference in the bug reports: The ureq one shows a proven error - a crash. That's bad, the author acknowledges it and fixes it.

The actix issue does not show an actual error. It just tells that some internal code does not follow the usual Rust unsafe conventions, and that this might lead to a bug. It takes then some API exploitation by a third person to demonstrate how this could lead to a bug. At that point the author acknowledges the issue, even though any real world implication is still unknown.


> Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients:

Interesting. I'm being led to believe that the actual problem lies in HTTP itself: it is too convoluted to be safely implementable and should be replaced with something else for security-critical applications. (Or in general.)


I don't think this is true. In fact, today, I privately forked one of the aforementioned libraries (httparse) and removed all of the unsafe parts in under an hour (without introducing any new memory allocations, I might add). All the tests pass.

It's not insurmountable. It just takes a little bit of elbow grease and self-discipline ;)


While this may or may not be true, it's irrelevant to the use of “unsafe” code in Rust. Rust doesn't attempt a compile-time guarantee that your code is simple or bug-free. It attempts to guarantee that mutable aliasing, use-after-free, double free, and resource leaks don't happen. No wire protocol requires such things or is even relevant to them.


But this is a problem Rust creates for itself. HTTP is safely implementable in most modern languages without any unsafe code because they're all garbage collected. For instance, Java has a mechanism also called Unsafe that lets you bypass the language's safety features, but I've never encountered an HTTP client that uses it because performance is fine without that. And the JVM developers have been working for years on safe but performant constructs that can replace the uses of Unsafe that do exist in the community, mostly, cases where very precise control over memory and concurrency constructs are needed in high performance servers.


Okay, I massaged the GitHub API logs[0] with jq to make a readable version of the issue history[1]. I was firstly (based on the blog post) feeling bad about the maintainer... but after reading the issue report, it turns out multiple people were working on the issue and the author responded... 'this patch is boring'. That's... certainly not good to people who are trying to resolve the issue. He even goes to threatening to delete the organization if people talk about the issue.

[0] https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a5...

[1] https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...


Thank you very much.

Are there some deleted comments that might have been missed?

If not the conversation was civil until the maintainer refused a patch for a "boring" reason.


As I mentioned in the post, this situation has been going on for a long time. You'd need to read a few dozen pages to get the full context here.


Not quite correct. That patch was never intended to be merged as-is in the first place:

> As a PoC

> Presumably this requires benchmarking/more exhaustive testing which I don't have time to do, but if someone wants to take the patch and get it merged feel free

Keeping that in mind, the "boring" comment comes off differently to me, like they got sidetracked from the original issue and he didn't feel like continuing - which is nearly the confirmation given in the second issue.


I don’t have the full picture here, but the source article implies that folks weren’t just complaining, but also offering PRs to fix the issues, which were rejected. That feels less like entitlement to me and more like bad stewardship of the project, but again, most of my info is biased by source article.


One must also consider the typical quality of a PR - that is, lacking in many fundamental ways. Missing documentation, missing tests, doesn't match existing style, and sometimes just plain incorrect.

At some point, a flood of poor PRs can be worse than a flood of angry bug reports. The cost of validating and cleaning up a PR is significantly higher than closing a bug.


This is why I wrote "forked". They do have the right to not accept PRs for their own project, no? Sure, someone can be a bad steward, or maybe just opinionated. Doesn't give anyone the right to be mean to the point of making them quit their own project.


All of this is second hand, where are the mean comments "making" this person quit their own project?

Were they actual personal attacks, or just criticism of the code?

If you can't accept legitimate criticism of your work, that shows a real lack of maturity.

(The article didn't give concrete examples, so I don't know which is the case here.)


Here is an example of an actual comment. I believe the thread is deleted now:

> "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?"

This is what I was thinking of when I wrote "far, far over the line."


That comment is demeaning, unhelpful, and in very bad taste. It's the comment that the delete functionality on GitHub was made for. However, one of the other participants in the thread immediately called out this comment. So you have a constructive dialog, a single bad actor, and said single actor being called out by the people having the constructive dialog. That doesn't sound like an unhealthy community to me, to be perfectly frank.


I agree that the comment is in bad taste but what I don't see this being considered a "far, far, far over the line." comment when I take into consideration that it had been posted in reply to the maintainer's also dismissive comment "this patch is boring" so, yes, the user has definitely been rude, but chances are it's a visceral response too.

Otherwise if that event is far far over the line I wonder what out of the blue insults or death threats qualify as.


Yes, that comment was not ok but as far as I have seen that is the only comment which keeps getting quoted. All but a handful of people seem to have been civil.


Not to mention that that was a comment on GitHub, not on Reddit, even though the "far, far, far over the line" statement was about "the now-usual Reddit uproar". I guess Klabnik just really dislikes Reddit.


This! It is utterly disingenous - in fact, it is simply lying - to characterise users' interactions with the maintainer here as harrassment, or abusive, or entitled.


Depending on the context that doesn't seem to be "far, far over the line."

Just about any thread on HN regarding any aspect of systemd or Google will have comments which are much more vitriolic.


I completely agree with you, especially considering that comment was posted in reply to the maintainer's also dismissive comment "this patch is boring", which to me makes it seem not as bad as if it were out of the blue...


I believe the Rust community has been trying to draw a line somewhat short of where systemd discourse ended up.


Those comments would also be over the line.


HN discussions do not always live up to HN ideals. This is not be used as a reason to drag others down to our level. Instead it should make us reflect on our own behaviour.


Indeed, and it's one of the reasons HN has the reputation as "that orange hellsite" in some places.


Just because something is common doesn't mean it's okay.


Well, that's pretty clearly terrible and unhelpful!


The request is unreasonable, but is the second question not valid?


I think it's a cultural issue, but I honestly don't see what's so offensive about this comment (I was expecting something far worse), especially if it's factual assumptions are true. Honest question, can somebody explain the issue here to me, and how one would express these concerns otherwise? I feel as if I just don't get American culture of politeness and niceness to appreciate it.


It's a personal attack. The poster is telling the maintainer to quit writing Rust, implying he can never get better and basically demeaning his whole effort.

Do you not see how that is (a) not related to the project and (b) rude in any context?

If you were, say, singing karaoke and someone came up to you and said "you're awful, never sing again, you're off-key, you don't know the words"... Is that not rude to you?


Good singing is to karaoke as safety is to Rust?

I don't claim to know much about either karaoke or rust, but from what little I know of both, that seems wrong. The Rust community expects safe code, while bad singing is expected at karaoke bars.


You missed the point then.

The comparison was about how to communicate respectfully and appropriately, not about making an perfect analogy.

Think of it this way then: it is completely possible for the Rust community to expect safe code without being entitled assholes about how they communicate that expectation.


Yeah, that is the case.

I massaged the GitHub API logs[0] with jq to make a readable version of the issue history[1]. I was firstly (based on the blog post) feeling bad about the maintainer... but after reading the issue report, it turns out multiple people were working on the issue and the author responded... 'this patch is boring'. That's... certainly not good to people who are trying to resolve the issue. He even goes to threatening to delete the organization if people talk about the issue.

[0] https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a5...

[1] https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...


The initial back and forth isn't the issue, it was reasonably civil, if putting a bit of resistance to fixing the issue. The problem was the escalation which happened when it got posted to reddit, where the suddenly things got a whole lot more virtiolic and most of the vitriol was coming from those not involved in the original discussion at all. A similar thing tends to happen with systemd issues, for example (generally in that case they close the original issue to stop more comments and make a new issue or move discussion to a different platform, but still this will spill over into making new issues, PRs, etc). This behaviour is basically worthless to harmful whenever it happens, because it doesn't further the discussion in any way and just causes headaches for maintainers.


I don't get it, why didn't anyone just fork it and outcompete the original one?


Had I known in time, I might’ve personally.


>People could have forked and worked on the issues themselves, but that's asking too much.

Forking projects should be a last resort. This is the "Taking my ball and going home" approach, and now we're splitting development efforts, potentially ending up with very different code paths where improvements can't be merged from one to another, etc. It might be the right thing to do in this situation - but people wanting to avoid it want to avoid it for good reason. It's a big hammer and not the first one you want to pull out of your tool bag.

>Why do the hard work when you can just write a comment/tweet blaming someone else, right?

Except, as the article mentions, the author wasn't interested in detailed bug reports or PRs that had code that fixed it. This wasn't a case of people just being nasty - the maintainer wasn't interested in people doing work to fix it, either.

>Your comment is precisely what entitlement looks like.

This isn't someone asking for a feature request or minor bug to be resolved and whining when it didn't happen. This is a security vulnerability in a popular package where detailed reports are provided and the maintainer has a history of not accepting feedback, PRs, etc. on similar issues in the past.

Security vulnerabilities are a big deal: They have implications for not just the user or company that is making use of the software, but also potentially any end users. This is a web framework - a good portion of projects using it are going to be public facing. A good portion of those are going to be storing user accounts and information about the users. A security vulnerability puts all of those people at risk too.

I maintain that any project that you make publicly available you have a moral obligation to resolve security issues if it is at all within your power, and to disclaim them prominently if it isn't.

If I've got a free lemonade stand, but every glass contains a toxic chemical that will activate in my body if a malicious person sprays me in the face with another chemical, people sure as hell can bitch about my free lemonade, even if they could go run it through a filter and remove the toxic chemical.


No. Fork anytime you want to use something in production and don't consider it right.

Post pull requests if you care to, and post your fork, too, if you like, being careful to keep clear that it is a different project.

Some forks wither, some surge, some re-merge. It's all part of the dance. Any of it is better than flaming somebody who makes a thing and offers it.


> Forking projects should be a last resort

No. This was kind of true in the days of CVS and SVN. Now with DVCSs like Git, it's easy enough to merge in changes from wherever; this was the whole reason Tom Lord originally developed the modern DVCS. Git workflows commonly make a new fork for every bug fix. If other people don't want to merge in your changes, they probably don't think they're good enough. But that doesn't matter; you can still use them. If they're wrong, it's their loss.


This is true for feature driven projects where features are added on top of exiting code and only some existing code is changed.

But you will have a very hard time merging two refactoring branches that both touch internal data structures.


So, it's true that refactoring isn't going to merge automatically with either feature additions or other refactoring of the same code. But if the code was improved by the refactoring, probably the person making the other change will want to merge it in before making their change. There are cases where clashes arise between different visions of what “improvement” means — XEmacs was born that way — but in those cases it's obviously best for people to have the choice of which version of the code they'd rather work on, rather than bullying one version of it out of existence.

In many cases of profound changes, different versions of the software do a better job of serving different groups of users. For example, EVE Online is built on Stackless Python, a fork of the CPython interpreter that enabled massive concurrency. This was really important to the EVE Online developers, so they were willing to accept tradeoffs that the core Python developers didn't think were good ones. Most people have gone on to use the stock interpreter, rather than choosing Stackless, so probably the core Python team made the right choice for most people. But that's no reason to deprive EVE Online of the ability to try a different approach.

Similarly, when I installed my first Linux box in 1996, there was an "NFS swapping patch" which made it possible to swap onto NFS, which was impossible with stock Linux because it meant that many operations that were normally "atomic" could no longer be atomic. (This was before SMP support, so the kernel didn't have locks; atomicity was enough.) The patch introduced a new "nucleonic" priority level and redefined the notion of atomicity, adding a lot of complexity to Linux to support the marginal use case of running diskless X-terminals and the like on Linux, rather than, say, SunOS or NCD's shitty imitation of VMS. This was not a good tradeoff for the majority of users, and it did not merge well with changes to network drivers. But for a certain subset of users, it was extremely valuable and worth the tradeoff. This complexity was eventually added in a better way when Linux got real SMP support.

Similarly, LuaJIT prioritizes speed (and secondarily minimality), while PUC Lua prioritizes portability and minimality (and secondarily speed), currently being about half the size of LuaJIT and one tenth of its performance. LuaJIT is, generally speaking, about as fast as C, but originally it was i386-only, later adding amd64, ARM, PowerPC, and MIPS support; it still doesn't support aarch64, which is what most new hand computers use. PUC Lua, by contrast, runs anywhere there's a C compiler and a few hundred K of memory. Losing either of these two projects would be terrible.

So, no, forking projects should not be a "last resort." Being able to fork projects is one of the core benefits provided to users by open source. It's the reason Tom Lord invented the DVCS as we know it today, in the form of Arch, and it's the reason Linus wrote a DVCS to use instead of Subversion: to ensure that the users' freedom to fork their software didn't become merely theoretical.


> this was the whole reason Tom Lord originally developed the modern DVCS

Shouldn't that be Larry McVoy? BitKeeper predated GNU Arch by a couple years.


I never used BitKeeper or TeamWare and consequently don't know how their capabilities were similar to or different from arch's at the time. Did you use them?

Tom had a pretty clear vision for arch which is more or less what Git ended up achieving. Everything he wrote publicly about it derived the feature requirements from his social agenda; he never mentioned BitKeeper, and I don't think he knew about it. He must have known about TeamWare, but I don't know if he had ever used it, and from the little I can glean, TeamWare lacked some very significant things crucial to what we think of as a DVCS today. But maybe I'm wrong about that.


If you make your project public, does it by definition mean you are open to other people using your release? I think there's a difference between "Hey, use this project of mine," and "If you use this project, you're on your own..." I think a lot of these debates come down to this confusion. Some people assume the former (and expect some level of response), some the latter (and say it's as simple as forking if you have a problem). Therefore I think anyone who releases should - morally/ethically, not legally/license - state what which philosophy they are following.

It'd be interesting if people could release their projects "abstract" fork-only. So they could publish releases that would be vetted and merged into the downstream forks, but would never be released as a deployable itself.


It's really hard, though, because you'll always get people who will feel entitled. In the distant past I've released things and explicitly put in the readme something like "This is provided in the hope that it will be useful; I do not have time to support it and will not accept requests for help, but will consider merging patches that fix bugs or add useful functionality".

And yet I still got people who would ask for help with it, or file bugs without patches and then get angry when I wouldn't help them.


From what sklabnik's post says, patches were submitted but the author wasn't really receptive to them.


In that case, you clone and fork. If you're just trying to get your stuff working, your fork is private. If instead you're trying to enjoy publicity, you publicize your fork. In neither case is it necessary to annoy someone who has already done a lot of free work for you.


Reporting bugs is annoying?

I want people to point out bugs in my code, so both my code and me as a developer can improve.


This isn't a serious response. As amply demonstrated in TFA and elsewhere, the harassment was far more than "reporting bugs".

And, anyway, yes, reporting bugs can be extremely annoying. Different devs respond to this annoyance differently. npm devs, for example, have decided not to pay too much attention to bugs reported by the public. [0]

[0] https://npm.community/c/bugs


> And, anyway, yes, reporting bugs can be extremely annoying.

I would never touch the product of someone who found bug reports annoying.


Strangely, I would rather deal with developers who find bug reports annoying than folks who simply ignore them. The former have a touch of pride and you have a chance to get them to see your point of view. Better that than speaking to a black-hole.


That's a good policy, both for you and for them.


I honestly dont understand people being mad at this. Every dependancy I use I don't like 100% I fork and modify and then upstream changes, and if they never get merged, who cares?

If there was a big user community that wanted different things, fork and have a seperate maintainer structure. Why drama?


Then you might end up with a bunch of different forks each with different fixes applied.


A huge number of npm dependancies I use are basically unmaintained, have tons of forks and multiple PRs with the same fixes. I choose the one I like and move on, the magic of github!


Are you saying that that's a good thing?


And?


Wouldn't it be better if there was one repo that had all of the fixes?


From a pragmatic point of view, it's very bad to have widely used libraries that are poorly maintained and that have unaddressed security issues. It's not entitled to not want that situation to exist.

If you create a project that ends up becoming such a security risk, you really should be doing something to address it, for the good of everyone. This could be as simple as adding more maintainers with commit access who will address the issues.


Although I agree with you but there is one more point to consider. Why do people write open source libraries/frameworks? You'd say they write it as a hobby or learning experience and this is totally fine. But why don't they keep their work private if they aren't or shouldn't be bothered about how people use their libraries?

I agree OSS maintainers do a lot of work but no compensation in return. I believe most maintainers actually strive to remove flaws/bugs in their projects.

But if you write a half baked buggy OSS which is used by many people, you definitely should have some sense of responsibility towards users. Otherwise keep it private or at least boldly acknowledge that your project is merely a toy project which has many bugs and you aren't bothered about those bugs.


Let's say some charitable person hands out food to the poor. Only it's cooked with bad hygiene and people who eat it fall ill. People can and should warn tell each other to stay away. Even if his feelings get hurt. Even if he was only trying to do good.

I think this is a good metaphor because how bad the food is is key. If it's just a little bad he is doing a good thing. If it's a little bit more bad it's neutral and people can take it or leave it. And if the quality is really bad that's when people need to protect themselves and each other by dragging his name through the mud.

I'm not familiar with actix so I wont presume to say which category it falls into.


Reasonable expectation does not equate to entitlement.

So what is the person who finds the flaw supposed to do:

1. announce to all the other users of the library to download his branch with just the single fix

2. report it to the maintainer with a suitable patch, discuss it, and hope the maintainer applies it sooner rather than later.

TBH the maintainer sounds like the boy with the soccer ball who ends the match and takes his ball home with him, because the opposing side scored against his team.


To me the maintainer sounds more like the boy who brought everybody cake and then left the party when the other boys started nagging about how their mothers would make much better cake and how his cake is all wrong.


It's more that he bought a cake, but it wasn't cooked in the middle, so there was a chance people could get food poisoning, and the other people at the party pointed that out and suggested ways to cook cakes more consistently, but the author really likes cooking soggy cakes, and he's never got sick from it so it must be fine, so he left the party and told everyone the others were mean to him.


It's more like he bought a cake but the brakes were faulty and it skidded off the road and killed an innocent trifle.


Nikolay works for Microsoft, who use actix-web internally. He was putting in 12 hour days for 3 weeks porting the project to async/await, so I sure hope that Microsoft was paying him for it!


So he was paid by Microsoft to handle their pain points. How much did any of the reddit guerilla pay him to be able to make similar demands?


> It's not like he was getting paid to work on this, was it?

So? If I'm donating clothes to one of those coat drives, and the clothes I donate are tattered and covered with rodent feces, should the organizers of said drive not be upset with me? Especially if said organizers point this out politely and I respond with "lol you'll take what I give you, peasant"?


No demand for work is being made here. I'm simply saying a project that isn't a toy project will be criticized if it doesn't behave according to community standards.

I'd consider it to be social norms. It certainly isn't entitlement.


> It's not like he was getting paid to work on this, was it?

That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely.

Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to play the but-I-dont-get-paid-card. You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug.

Open source is not some backyard game anymore. It involves companies and their commitment in form of infrastructure and participation.

Open source is like capitalism. But a project's success is measured in commitment instead of capital.


Everyone has different goals and different tolerances when they work on open source, whether as a maintainer or contributor.

So there are some Debian developers who are unpaid and slavishly dedicated to fixing security issues and apologizing if they screw up? Great, that increases my confidence in them (I'm a Debian user and happy with that).

But guess what? There are also open source developers who do their thing as a casual hobby and just throw things out there because they hope it might be useful. They don't want to spend 50% of the free time they allocate to the project dealing with support requests and bug reports.

And there's everything in between, and above and beyond. I think this is a mistake that so many people make: that all open source developers are exactly the same, have the same motivations, want the same level of involvement, and have the same responsibility. That's just flat-out false. Every project and maintainer is different, and yes, it can be difficult to judge what kind of support you'll get when looking into taking on a new dependency, but that's the price you have to pay when you get something for no monetary cost.

You have no right to tell anyone what to do or how to do it unless you are paying them for the privilege of doing so.

> Once you are a part of people's infrastructure and these people rely on you to not be irresponsible

Nonsense. Absent a contract and some sort of consideration changing hands, you are responsible for your dependencies, and no one else.

> You can resign gracefully and let other people take over.

No. If users are unhappy with maintainership, they can fork. It's often contentious and not all that fun, but the (unpaid!) maintainer has no obligation to run the project the way you want them to.


>you can't afford to play the but-I-dont-get-paid-card

Yes, you can. The projects that have persisted over the long term have had a long history of people being paid to work on them, Debian included. There is no need to do something to "let other people take over" either. The code is open, you just type "git clone" and boom, now you've taken over.


I’d argue that if a company has a larger than normal dependency on keeping a project running (like a cloud provider with 1 million VMs running Debian or Debian-based OSes) they should hire a full time employee whose sole job is to work on it.

I think the basic rules still apply: You’re getting this software for free rather than paying for something expensive. Though you deal in the software, you get no guarantee of its fitness for any purpose. If you want a better guarantee of its fitness, either pay the current maintainers or hire someone good who can become a maintainer. OR choose open source projects where a BigCo like Microsoft or Google has hired people to work on it full time.


> You’re getting this software for free rather than paying for something expensive.

So open source is free as in beer, not free as in speech after all. And the reason a company might choose to use open source is solely because it's free, not because they can see the source code or alter it? Because that is why companies are in it, not because they were cheap for the small cash of a paid version. And they're in it because they can watch and choose those projects that are well maintained.

If the maintainer pulls a tantrum and acts unreliable that kills the project from the point of view of any serious user. Until someone else takes over maintenance or it is forked.

This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money. If there is no money, there is probably no worth, so don't expect any. Accomplishment, dependability, positive net effect? No money, so don't expect it?


> So open source is free as in beer, not free as in speech after all. And the reason a company might choose to use open source is solely because it's free, not because they can see the source code or alter it? Because that is why companies are in it, not because they were cheap for the small cash of a paid version. And they're in it because they can watch and choose those projects that are well maintained.

In general, developers aren't auditing the source code or modifying open source code; they're assembling open source packages to provide base functionality and combining that together with business logic and glue code to produce a product. So yes, companies are most commonly using open source because it's zero cost (and easily available), not because they can theoretically audit or modify it.

> If the maintainer pulls a tantrum and acts unreliable that kills the project from the point of view of any serious user. Until someone else takes over maintenance or it is forked.

There's no single definition of "serious user". There have been projects with no technical issues that are maintained by massive assholes that are widely used, so I would disagree with your statement here.

> This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money. If there is no money, there is probably no worth, so don't expect any. Accomplishment, dependability, positive net effect? No money, so don't expect it?

1. Unsurprisingly, any discussion within the context of how businesses make decisions or should act is likely to revolve around money.

2. The fundamental issues is that there's a massive disconnect between the worth/value provided by a project to users and the value it provides to the creator.

3. The license dictates what users should expect as far as "what they get" from a library. It almost all cases with open source, they should expect to get nothing, and anything beyond that is a bonus.


> This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money.

I mean like... yeah.

If I'm maintaining an open source project as a side gig or for fun, I might be able to review and merge some patches. But if the corporations that use my project submit a busload of PRs (or worse, just issues with no solutions) and I end up spending so much time on them that I have no time to work on my dayjob and make rent... that's not gonna work.

Now if those corporations each chuck a hundred bucks a month (less than the cost of a single Developer's Enterprise MSDN subscription) my way, then sure! I'll scale back my freelance web dev work and spend half my workweek dedicated to maintaining this project!

So yeah, I think the corporations who make money off open source projects should be kicking back a bit of money to those projects if they want an expectation of reliability. It doesn't have to be a ton of money either:

- If we're talking about a tiny header parsing library that needs occasional security patches, maybe expense a few bucks at the maintainer's Patreon so they can spend 10 hours a year on those patches.

- If we're talking about the web framework that underlies your big newspaper's CMS, maybe have a developer spend 20 hours a month pushing well made PRs to fix the problems you care about.

- If we're talking about an OS like Debian and you're AWS, maybe hire a 3 person team to work solely on keeping it secure.


What rubs me the wrong way is the notion that if it's for free it has no worth. This "free == shit" idea that is expressed in "you can use it but don't expect much of it because it's free". Maybe I'm just too much of an old school open source idealist.


Some floss developers choose to work for free. That’s fine or even admirable.

That doesn’t mean that everybody needs to. If a dev isn’t being paid then they should have the absolute right to refuse all maintenance or even just destroy the project.

I’d keep my code closed source if there was a risk that it would start getting used and suddenly I’ve got an extra job for zero pay.


> Some floss developers choose to work for free. That’s fine or even admirable.

Uh, yes. I agree.

> If a dev isn’t being paid then they should have the absolute right to refuse all maintenance or even just destroy the project.

Where in my post did I say they cannot quit?

> I’d keep my code closed source if there was a risk that it would start getting used and suddenly I’ve got an extra job for zero pay.

I'm with you.

I have the feeling, you are replying to a different post or didn't read mine fully.


I absolutely read your post fully.

I disagree that there is an obligation to "resign gracefully". If people choose to depend on your code without some sort of contract then that is on then and you absolutely can continue to play the "I don't get paid" card if you so choose. The fact that the Debian maintainers don't play this card does not mean that everybody should behave the same as they do.


Let me help you: > You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug.

Where did I say I believe there is an obligation to "resign gracefully"? I said, that you will burn your reputation. Not that I think that is how should be. Just like a politician burns their reputation with something you or I might not find offensive. And that is where shitstorms come from. "I'm just minding my little own business down here" doesn't work once there's a spotlight on you. Do I like it? No. Do I get downvoted on HN for describing the world as something people take offence in? Apparently.


    > Open source is not some backyard game anymore. It 
    > involves companies and their commitment in form of 
    > infrastructure and participation.
I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too.

What I'm reading in your comment is that once it becomes widely used, it becomes my responsibility to meet the needs of these people and organizations who have started using the work I freely give to them. The act of having it used by other people obligates me to them.

That perspective seems like it will eventually force the people who share their work in this way down the path of burnout.

    > Open source is like capitalism. But a project's success 
    > is measured in commitment instead of capital.
I would argue that the goals of any given open source project - and therefore the measures of its success - are under the control of the owner(s) of that project. If one of the goals is to make a widely distributed and used thing, then yes - there are obligations such as you've described; they are inherent in that goal.

If the goal is only to build a thing and share it, there can be no such obligation - regardless of how popular it gets.


> I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too.

I don't believe that every little open source project is automatically held to the rules I described. But once your exposure gets bigger, you suddenly enter different waters. Hopefully you might have maintainers of a distribution shielding you from the biggest impact.

> What I'm reading in your comment is that once it becomes widely used, it becomes my responsibility to meet the needs of these people and organizations who have started using the work I freely give to them. The act of having it used by other people obligates me to them.

That is precisely what is happening in many places. I didn't say I like it. In most cases people can move. Sometimes the "market" moves on or forks it. But this is what I have been seeing more and more.

> If the goal is only to build a thing and share it, there can be no such obligation - regardless of how popular it gets.

This is tricky. Viewed from the moral standpoint of the starter of the project, I agree. But once you got into the limelight with your project and other people started depending on it, every misstep suddenly becomes a jackass move. You essentially lost the project.


> But once your exposure gets bigger, you suddenly enter different waters.

I fundamentally disagree with this. Just because my exposure has gotten larger (possibly through no action of my own), it doesn't magically give me more resources, more free time, more motivation, a team of developers, etc. If people (or companies) want to depend on a one-person open source project for something important to them, then they should pay to fund it, either by giving that developer money directly, or by hiring people in-house to contribute to that project.

(Not doing so is just foolish and risky on the company's part, too: depending solely on an unpaid volunteer for an important part of your infrastructure is not a winning move.)

Also consider that more users generally means less free time for developing, and more time handling bug reports and support issues. If an open source project grows, it's absolutely critical for users to step up and pitch in, either with their own skills, or with monetary resources that can help the maintainer (who might have a day job) focus more on the project.

Maintainers do have a responsibility to decide what they want their level of involvement to be, though, and to communicate that. Potential users should have the information they need to decide if the project they want to depend on is well-supported and sustainable. They have no right to demand that the maintainer change their approach or level of involvement, however.

> But once you got into the limelight with your project and other people started depending on it, every misstep suddenly becomes a jackass move.

I really dislike the lack of charitable interpretation given here, and this just contributes to the "entitled user" image. The unpaid maintainer of an open source project does not owe anyone anything. Full stop. Users are responsible for their dependencies. I'll repeat that: users are responsible for their dependencies. If they are going to take on a dependency for that's given away for free and not do their due diligence to make sure it is reliably and sustainably developed, that's on them. If they're not happy with the maintainership and want to use it anyway, that's on them. Users do not get to tell unpaid maintainers how to maintain their software. If they want to be helpful and constructive, that's great, but anything less is rude and unwanted.


>> But once your exposure gets bigger, you suddenly enter different waters.

> I fundamentally disagree with this.

Don't get angry with me over this. I'm just the messenger

> I really dislike the lack of charitable interpretation given here, and this just contributes to the "entitled user" image.

Again, I'm just explaining to you how the world is not how I want the world to be. So don't call me entitled! Just read my posts maybe?


Commitment can't be measured. It isn't a quantifiable thing, like dollars.


That is true and that is where the analogy ends.

I originally invented the analogy to make some friends of mine who had a very strong market oriented mindset, understand open source. This was many years ago, when the likes of Microsoft painted open source in the light of anarcho hippie communism. I needed to explain to them that open source is closer to their thinking than some Fortune 500 behemoth that is capitalism on the outside but basically socialism inside.


According to https://github.com/actix/actix-web, it appears that the author did accept the security concerns (when an actual use-after-free was found, but maybe not the previous, generic “unsafe oh noz” shitstorms), and wanted to explore some other way to fix the problem instead of accepting the patch as is.

Just because there’s a patch that fixes the issue doesn’t mean the maintainer has to merge that patch.


The maintainer still shouldn't dismiss a patch + test case with "it's boring".


Why not? The only reason I work on personal open source projects is because it's interesting to me. Otherwise, why would I bother?


He can reject the patch. But the tone is important as well. And that was that "it's boring" reply that triggered an angry response from a passerby about "you shouldn't write libraries" (or something in vein).


He didn't. From what I can tell from reconstructed logs posted elsewhere here, he rejected a proof-of-concept the poster suggested someone else continue with.


I'm not sure which license was used by actix-web, but let me quote the last section of the MIT license as a reply:

> 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. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


IANAL but I'm fairly certain this protects you against legal action and not negativity on the internet.

Furthermore, if we're to interpret this clause as "do not place any trust in this software whatsoever" then I guess that's really bad news for the security community at large.


From the grand parent:

"If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project."

The reply:

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

Furthermore, from the GP: "No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them."

Nothing in the license implies any such guarantee.

> "do not place any trust in this software whatsoever" then I guess that's really bad news for the security community at large.

I mean, that's what the license says. If you want assurances, get it in writing. Otherwise, when you use code, it's on you to make that guarantee of the code you are using.

Entitlement. Gimme gimme gimme. It's a shame.


I didn't think it could be so difficult to separate legal contracts from social ones.

If you have voluntarily assumed the role of maintaining an open source project, it's perfectly reasonable for people to expect you to address merge requests and issues on the issue tracker. It's reasonable to expect a maintainer to process technical arguments and justify their technical decisions.

The maintainer of course has no legal or moral obligation to perform any of these tasks. If he should ignore these assumed responsibilities, the users of the software can react in multiple ways. They can fork the project or use something else. In both cases they are also completely and utterly within their right to put into question the reliability and credibility of the aforementioned maintainer. Especially where it concerns software that people rely on for critical processes.

All the "as is" clause means for security concerns (apart from its legal implications) is that the burden of making these guarantees lies on the community, and not the emitter of the software. It does not mean you should have no expectations of it at all and to suggest so is, frankly, nonsense.

Lastly, I think if anyone is "entitled" to anything, it's respect. If the developer of actix truly felt like he was not getting the respect he deserved then his reaction is completely justified.


Legal statements aren't special. They are also plain old social statements, which I think was his point. It's not solely a "don't sue me".


However, that disclaimer exists in all major open-source licenses, including all such software explicitly marketed such that a Reasonable Person (in the legal sense) would interpret it as a statement of fitness for purpose.

Thus, the disclaimer in the license cannot double as a disclaimer in the social arena.


We're not expecting a warranty and we're not asking for damages.

It's not really surprising that the Rust community is made out of people who've chosen to take extra effort in security, and that they wouldn't tolerate a cavalier attitude to it. It's disappointing that this was expressed in an unconstructive way.


Sure, so in the case of actix-web, the decision of many has been to stop using the project because it wasn't safe.

I didn't see any discussion of legal liability, just a community deciding to stop using and supporting this library.

(Just going by Klabnik's article, I knew nothing about this library before reading it. There may be more context of which I'm not aware.)


I am not aware of anyone bringing legal liability into this situation, in any form.


I am replying to a comment citing legal liability language from a license?


I was trying to address your "There may be more context of which I'm not aware," and all I was trying to say is that nobody was making claims that somehow the author was violating some sort of license duty or whatever.


> I'm not sure which license was used by actix-web, but let me quote the last section of the MIT license as a reply

This is a really bad answer because the most reliable and robust free software projects out there all use this same boilerplate license warnings. This is just for legal protection.


No, that is actual scope of warranty and assurance those developers intend to promiss. Everything else is beyond and above.

I pretty much guarantee you that if the "clearly mark your project as toy project" thing would become something people actually are expected to use, it would be everywhere too.

As if now it is nowhere, not on very clear toy projects and not on serious looking projects thay are sparsely maintained. The ones with license are all clear on limited warranty.


I think it is a fine answer, albeit incomplete. Many of those robust projects you mention are supported by contracts which do guarantee some work is being done. If you’d like some guarantees of quality, you are free to negotiate a contract with the maintainers for those guarantees.

Think of MIT’s warranty disclaimer as the “free tier” of service.


A similar disclaimer is contained in the GPLv2 and therefore applies to the Linux kernel. Does that mean we can not impose any expectations regarding security on its maintainers either?

Why can't we have legal disclaimers like this so that the legal system with its tech-oblivious case law and multi-million-dollar penalties is prevented from interfering while also retaining softer sanctions such as the threat of community ostracism/obnoxious messages to incentivise some degree of quality?


> Does that mean we can not impose any expectations regarding security on its maintainers either?

Yes. If you want a secure version of Linux, pay a vendor like Red Hat who’s willing to provide those assurances.


OpenSSL's license (Apache v2), also has the "AS IS" clause. I guess we should just wholesale dump any concept of security since the very basic technique of protecting oneself from litigation on the possibility of something going wrong should instead now be interpreted to mean "this is a toy project with zero guarantees".

There is a difference between "Hey, this is a silly side project so definitely use at your own risk, as far as I'm concerned its a place for me to learn and should be treated as a toy" and "Hey, I think this is worth your time, you should use this in your production stack, and obviously I've set up legal protections so you can't sue me if something goes wrong, but I am trying to push this as something lots of people should use and trust".

If someone walks into my house and tries cookies I'm clearly learning how to make and then throws up, that's very different than me putting up a big "FREE AMAZING BETTER COOKIES" sign on the sidewalk and handing them out and having people throw up. In both scenarios, the cookies are free! What are you blaming me for! How entitled! In the first, I think that position is more defendable. In the second, ehhh.....

For the record -- I'm not super familiar with this project, but I think that a lot of people don't consider the ramifications of being successful sometimes: your project could be used by a big company and lead to people's information getting hacked (and those people had nothing to do with any of these decisions). The only thing asked is to be upfront that this is not intended for that, as opposed to the temptation of calling your thing the best and telling everyone to use it. In the run up of a project, I think it's easy to forget that and get really hyped on showing how your thing is better than some incumbent for example. Just something to keep in mind.


> OpenSSL's license (Apache v2), also has the "AS IS" clause. I guess we should just wholesale dump any concept of security since the very basic technique of protecting oneself from litigation on the possibility of something going wrong should instead now be interpreted to mean "this is a toy project with zero guarantees".

Essentially: yes. If you want any guarantees beyond that, you have to pay for them, or trust that others have paid for them.

Absent that, you have to make your own judgment as to whether or not the maintainers will run the project in a way you feel comfortable with. If they do; great. If not, move on (or contribute, or fork it), because you have no right to tell them how to maintain their project.


But I can't fork it, not where it matters, that's the point. Me forking it doesn't get it distributed to all the services I use, some provided by the government for example. This is my point, as a customer, my forking doesn't affect my usage, usage that may be completely out of my control.

There have been times when society has decided that some utility was important enough to "transfer ownership" (imminent domain for example). Obviously that is an extreme case, and I am not advocating for that (in fact I am against that), but I am demonstrating that precedent exists for the feeling that some things ingrain themselves enough such that if you want to abdicate responsibility you should perhaps consider abdicating ownership. More than anything, I am trying to help explain how the other side feels.

But, as a trivial example, it's certainly not the case that they owe you nothing in the strictest sense. Under that model, they could technically put in code to forward all data to their servers and fall back to "well, as is, that's how we wanted it". I think that wouldn't hold up in court. There appears to be at least the basic expectation of good faith (and lack of criminality). Given that, perhaps it can be extended to negligence too. Perhaps not.

My position is actually a rather soft one, it's "If you heavily pitched your project and it ended up in the control systems of nuclear reactors, you should maybe expect people to be pissed at you if you willingly block critical fixes because you deem them boring". See, I'm not even saying what you should do, just more of a like "well, what do you expect".


What must have gone horribly wrong during the course of software history that led to people acting so entitled about free open source projects?

You use it, you evaluate then accept the consequences. You don't? Well Patch it. You can't? Use an alternative. Nothing else available? Fork it and fix it.

If nothing works for you, then either you're the problem, or the entire field has an unsolved problem (and you're not helping, especially when slamming people working for free trying to solve it, even if not correctly or the way you'd like).


The thing that changed is we began building off of more and more open source, and so it became more and more important. Nobody is expecting a project's original creator to slave over it eternally. They are instead expecting them to clearly signal their intentions. A "Not Maintained" flag, or "Read my design philosophy before using", after understanding community expectations, is no effort and a reasonable expectation. Counter arguments like to think we are islands and that because we never signed an official contract, we have no responsibilities to anyone but ourselves. But that is not how society ever has or ever will work, and there never has nor ever will be any such thing as "leaving" society (other than death). There's a social contract that you are (unwillingly) a part of, and that's reality. Entitlement here is merely people implicitly recognizing that fact.

EDIT: This rant is a general reply to your general sentiment, not a specific reply to this particular case. I have no idea whether the author did in fact signal appropriately their design, risk, etc.


This is an oversimplified view. One could say the same thing about eg free services from Google or Facebook.

It doesn't prevent us from saying "operating in this way is bad/destructive", even if one chooses not to use the code or service.


It all went wrong when the number of users exceeded the number of programmers.


No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them.

Looking at the postmortem[1], it looks like the patches provided were not good enough in the developer's eyes:

I believed it held mutable aliasing invariant and I was very happy that someone found real problem. I wanted to solve the problem, just with a bit of creativity. And use RefCell solution only if it would be not possible to solve it with any other way. Btw, I like the solution I found, it is in master and solves the problem at least one from the issue. If you want to push boundaries you have to touch this boundaries and sometimes you push too hard.

That sounds very much like the developer was headed to fixing them, but I guess the harassment and need for now won.


Maybe that is what the developer intended, but afaik it is not what he communicated. What he communicated was a flat out dismissal of the issue along with the proposed fixes. Followed by deleting the whole issue from GitHub. To be fair, there were some very unpleasant things said in there, but he could have just deleted those and maybe locked the conversation telling people about his plans.

This whole thing was a feedback circle of increasing hostility between the community/contributors and this developer. At some points the developer was very unresponsive, leading to disappointment from the community, but then some very uncalled for personal attacks came from the community. I think the developer received some justified criticism, but I still understand his perspective, putting work in and getting abuse back sucks.


So, how fast do people expect developers of open source projects to respond before someone is considered unresponsive?

I'm not sure combining social media with code control is going to be such a good thing for a lot of developers who might not like to program in a fishbowl.


From what I saw, the problem wasn't response time but response tone.

If he'd said "I'll write my own solution" rather than calling it boring, his response wouldn't have been a problem.


Expecting a reasonably-quick response to security concerns is certainly appropriate.


In a free project where the author isn't paid? What if he's on vacation? What's the SLA there? Is it reasonable to expect him to cut short the vacation?

If you want to be able to place expectations on the author, pay them and get a contract.


Then it is about communicating exactly this. Security and trust hinge on properly communicating what is going on.


That's like expecting your boss to double your salary because he is paying you salary. Opensource expectation should be in general if you are not happy feel free to fork and fix yourself. Then submit PR if you want to push your fix upstream.

But still so many PRs getting rejected, because they do not pass code review and usually it does not cause reporters of those failed PRs to open whole big flame discussion. That + overreaction on reddit was a last drop after which Nikolay decided to close the thing.


What is reasonably-quick time wise?


I'll be blunt too.

If you use other peoples work for free and makes demands, then you should really stop using others free work and start paying for what you need.

It's your responsibility to choose what code you use, and unless the author has explicitly given specific guarantees they promise to uphold come hell or high water, it IS a toy project until proven otherwise.

It's such absolute nonsense to expect other people to submit to your wishes and whims without any compensation or prior consent.

But chastising someone in public for not submitting to your wishes?

That's straight up bullying.


Backing up another level...it’s concerning to me when a language relies heavily on single-maintainer libraries for commonly needed functionality.

If actix-web was this important, it should have been adopted by the community before now. Maybe languages need a way of setting the expectation to that if your library becomes essential to the community (and if licensing allows) the core developers are going to fork it and find a way to govern/maintain it the same way they maintain the rest of the project.

I think about this a lot with Racket lately. Some of the core packages that everyone uses for date/time, Markdown parsing, etc., were written by a single guy in his spare time, who a few months ago was making noises about quitting the language (so far so good though).


The developer actively fought against this for a very long time, even before the reddit shit storms. Yes the community could have forked the project and started independent development.

I'd argue that forking and developing independently of the developer is as big of a middle finger as a developer taking their ball and going home. It just depends on who is on the receiving end.

I don't think either side is right here, but I don't think creating a public fork and building a community around that is an unbiased and neutral response either and should only be done in extreme circumstances... Which is does seem like what happened here.


> I don't think either side is right here, but I don't think creating a public fork and building a community around that is an unbiased and neutral response

Linux distro maintainers routinely create "public forks" even of actively-maintained packages, and no one sane views that as a hostile move or something to complain about. It's part of curating a well-kept ecosystem around your solutions.


> Linux distro maintainers routinely create "public forks" even of actively-maintained packages, and no one sane views that as a hostile move or something to complain about.

https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop...


The way jwz's website treats links from HN should probably give you a clue as to his personality and approach to communication. I wouldn't hold him up as a role model in this regard.


Forking can be a middle finger — a schism, dividing the church to do it your way. Or it can be the most normal thing ever where no one would even bat an eye.

The distinction is if there is tribalism entering the discourse. If the reddit-community-tribe argues gathered around their digital fireplace how bad that one maintainer is, it will naturally become a tribe vs. maintainer conflict (a good way for tribesfolk to proof they are part of the tribe).

This is exactly what saddens Steve: it shouldn't be the "we know real Rust"-tribe against the heretic maintainer. If anything the "heretic maintainer" should be seen as part of the tribe: it is not in our interest to "win" but rather to convince and to take him with us.

I find it shocking at times how low people go just to defend their newfound beliefs within their newfound tribal community.


I like the direction .Net is attempting to go here: there is a foundation and if you want your project to be taken seriously, you should join it. You still get to maintain your project (mostly) the way you want to, but if you stop maintaining the project, the foundation will take over.

(.Net is probably not unique in this regard, but it's what I'm familiar with.)


If you're a developer of an open-source project and people start using that, it's on the users to verify that the project is security-conscious.

I open-source lots of my fun hacks for free in the hope that they're useful for someone, but I'm not going to do free unfun work just because someone decided to use my hack in production.

Users of open-source software are acting way too entitled.


More like you should be expected, as a user, to look at the code youre using and determine if it fits your set of criteria. If you dont think its updated enough, or the authors free labor isnt fast enough for your needs, then dont use it. You come off super entitled and arent the only one. This is the kinda stuff thats making me start my new projects closed source instead of open by default.


People reading your comment as entitlement really need to pay more attention to the last paragraph. People really need to stop bandying about "entitlement" as if it deflects any and all criticism.

You are, of course, free to write whatever unsafe, insecure code you want. You are, by leaving the issue tracker in Github enabled, inviting public feedback on the quality of the code you write.

When you implicitly rescind that invitation by closing issues demonstrating concrete safety problems, people are well within their rights to call out the safety issues in the project as well as your violation of reasonable expectations and community norms. And don't bother posting the "warranty disclaimer" from FOSS licenses, that's not what anyone was ever talking about.

Deleting the entire project as he did is an incredibly petty and immature response. If he just wanted to quit, the project could have been archived (made read-only) and marked unmaintained.


I generally agree, except for this part: "Deleting the entire project as he did is an incredibly petty and immature response."

If he no longer wants to participate in the community, then deleting the repo was a good decision. It's not like the code is actually gone, other people have copies of it, and now that the original repo is gone nobody will mistakenly go to his repo and find it abandoned. It's basically the equivalent of boarding up the windows before you abandon a building.


Archiving the repo (which disables new commits, new issues, etc) would have served the same goal and not wasted the time of the larger community.

Here's an example from one of my own archived projects. Is there any doubt in your mind as to the state of this repository?

https://github.com/karunamon/concourse-resource-bitbucket

Inconveniencing countless others in a fit of pique is a pretty good definition of immature, petty behavior.


Who is we?

People who write security sensitive toys and don't care enough to vet their deps?

Professionals who profit off security sensitive programs written on top of others' free work without paying a dime?

I don't think either group is in a position to make such demands.


I'm sure both sides are being childish here. Users thinking they can abuse a dev because they know better, and devs deciding they'd rather take their ball and go home. No one looks good at the end of this situation.


Taking the ball home when other kids abuse or bully you is correct action.

That is actually one of the things we teach the kids who are in these situations to do. It is ok to have a boundary, it is ok to leave the situation and it is ok to stand your ground. You don't ask for abuser validation nor permission.


How is taking your ball and going home childish when an angry mob is after you? Seems like a rational response to me.


Your analogy is stupid. People are still able to fork the project. Taking the ball and going home means that you prevent everyone else from playing,


what code does not run in a “security-sensitive context”? who’s responsibility is it really? The person who wrote the code with a disclaimer saying they were presenting it to you AS-IS? Or the person who’s choosing to run the code in the “security-sensitive context?”


The popularity of a project doesn't change it from "toy" or "personal" to "primary focus of developer's time". The developer might still only have so much time to spend on the project.


If you aren't satisfied with the code, fork it and fix it yourself. You are owed nothing. What right do people think they have to call someone out on it? Why do they feel entitled to other people's time and energy?


("bear the brunt" It's one of those weird words that only exists now in that phrase. Brunts are borne but otherwise unmentioned. It's kinda like how you can be over- or underwhelmed, but never just whelmed.)


> If you're a developer of a project that is used in a security-sensitive context

Working in the context of Security does not grant you a blank check to be an asshole.


Why should a project author dictate in what contexts their project can be used? It's on the coder to manage their dependencies and ensure they are a good fit for their needs... not the project author.

And what exactly are you contributing to this project author to match your demands of them immediately fixing flaws that are found?


Is there anything else you would like to demand about people's code they you are not paying them to write?

I demand you go write a tool that lets me query projects and tells me if you think they are a toy or not. I'll wait.


"we do expect you to fix flaws when you learn about them."

If hope the plural we is also ready to monetarily compensate the developer for their time. Otherwise you don't have any basis for your expectation.


> you either be receptive to security concerns or you clearly label your project as a toy project.

Or, assume all OSS projects are toy projects unless stated otherwise.

Usually the serious ones offer a support license for a fee, or are supported financially by companies. Otherwise, it's just someone building cool stuff for free.

Also, it's probably fair that most OSS maintainers aren't marketing their projects too aggressively outside of a blog post or a Reddit submission. When they take off, it's usually other developers hyping them and that hype usually comes from being lightweight, easy to configure or super fast. It's not until a project has been hyped by the community do people start trying to put it into production and looking into security issues.


I think that https://actix.rs/ counts as an implicit "the author doesn't intend this to be seen as a toy project" in people's eyes.


One thing that nobody here seems to have mentioned is that, as far as I can tell, the actix.rs website was not created by the author of Actix itself. Just compare the writing on the website with the author's own postmortem. I don't know who wrote the website; I can't find an author's name or a Git repo for the site itself. But whoever they were, it seems that they, not the author of Actix itself, did the marketing that gave many of us our primary impression of what kind of project this is. If anyone reading this knows more about the history of the website, I'd appreciate any additional background or pointers to more details.

Edit: After running some git blame commands on the https://github.com/actix/actix-website repository (thanks Nikolay for keeping it there), it seems that the most eloquent marketing for the project was written by Armin Ronacher. I'm sure this was all done with Nikolay's permission, since it's under the actix GitHub organization, but my point is that Nikolay himself didn't say the things that have been quoted from the website, and they didn't necessarily reflect his own attitude about the project. So that might have caused some confusion.


> bear the blunt

It's "bear the brunt".


How about instead of pushing the responsibility on someone else, you take responsibility for YOUR security-sensitive context and do the research before you start installing libraries?


Isn't that exactly what happened?

This article is someone who did that research on multiple Rust HTTP clients and reported what they found:

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

Which I believe is what kicked off the events leading to Klabnik's blog post?


That’s fine. “Hey, this project has bugs maybe don’t use it” is fine.

Dog piles on Internet forums because the dev isn’t doing what you want isn’t fine.


> Dog piles on Internet forums because the dev isn’t doing what you want isn’t fine.

Therein lies the problem. You cannot reasonably expect to link a blog post that says what that one did on Reddit and not have people dog pile. They will, every single time.


exactly. the dev has to take responsibility for what they write but there’s no responsibility required when you run something??


>people who already volunteer their time for my benefit have to follow my rules when doing so

Ok.


This. The project is considered one of the (if not the) go-to web frameworks in Rust, lives under its own organisation, is promoted and discussed by many other people. It's not a sole property of the maintainer any more. The maintainer does not owe anyone any new code, nor accepting any PRs. But he does have to set correct expectations. If you want to be the sole BDFL and not care about others opinions or contributions then don't promote it as production code, keep it under your own profile, and/or make it clear in the README. Now it's a community project, "fun" is not necessarily the most important quality anymore. State your position early.


This seems to be a case of mismatched expectations.

Many want Rust to save us from our current nightmare hellscape of vulnerability-ridden foundations.

So actix-web comes along-- a Rust web framework that is faster than everything else including the C and C++ frameworks-- and people are filled with hope. It's fast and safe, right?

But the actix-web maintainer says he built actix-web just for fun and to see how high he could get in the TechEmpower benchmarks. So he took license to use a lot of unsafe Rust code to improve speed. He apparently was not trying to make the world's best web framework, one that is safe and fast. Just one that is fast. Oops, expectations busted.

Everyone is to blame. No one should believe that all Rust code is perfectly safe, and we need better ways to know which Rust crates are trustworthy. And the actix-web maintainer could have taken more responsibility for setting people's expectations that the project prioritized speed above security.

I love the Rust Book by Steve Klabnik and Carol Nichols. But I think Steve is off base in this post when he implies that Davidoff is wrong about unsafe code increasing a library's security risk. Of course unsafe poses a risk. Of course it's legit to avoid libraries with lots of unsafe code, especially unnecessary unsafe code. Actix-web was taking a lot of risk, more than people expected.


I do think it's legit to avoid libraries with a lot of unsafe code. I myself started avoiding actix after these situations. If folks had simply stopped using it, that would have been a fine outcome here. That's not what happened though.


Thanks for the correction.


I am not a Rust guy (yet?). Are safe and super fast mutually exclusive? As I reas the article I sensed your explanation was probably the case. Did the many safety-making patches cause the performance to go down?


Not so much mutually exclusive as "safe, fast, easy, pick two", at least sometimes. It can take a lot of design effort to come up with a safe and efficient way to do some things, so it's often tempting to do something unsafe and efficient and hope it works out.


They are not mutually exclusive, though some people will try to suggest it.


I want to give a heads up to everyone who runs, or is thinking about running an open source project. If your project sees ANY notoriety and you are the maintainer, you will quickly find yourself in this situation. In 2013, I started a little side open source project and put it on GitHub which now has 5.2k stars. I've seen tons of arguments in my PR's over the previous 7 years. My project isn't even that large and I've seen lots of in fighting to the point where I've had to lock threads. The skills required for you to run a successful open spruce project are the same skills required for you to run a business. You're going to need people skills and understand how to de-escalate situations because once the community is large enough, there will be a lot of culture conflicts. The main challenge with open source is that if you're not getting actively incentivized (Paid for me) to maintain something that's super popular, it's easy to abandon it when things get hard.


It must depend on the project in ways I don't understand. Certainly while working on Firefox I saw tons of toxic behavior from users, and sometimes potential contributors. I've seen it in lots of other projects that I haven't worked on. But for rr (4.7K Github stars) I have seen none whatsoever. I wish I could explain the difference, but I can't.


rr is only useful to people with a minimal level of knowledge, and in most cases to people who have stood in your shoes. Firefox is useful to any six-year-old with a cellphone. Maybe that explains the difference.


That could explain the difference between rr and Firefox, but it doesn't explain the difference between rr and all the other developer-oriented projects with toxicity issues.


There's variance in developer experience and skill as well. The software's purpose functions as an audience filter. There are still probably toxic people out there using your software, but not as many so they're less likely to bother you.

From what I've read about rr, it sounds like awesome black magic, and I'd imagine most users appreciate how difficult its task is.


That's true.


While I much appreciate Steve's work on Rust, this does seem a little high on drama and low on substance. Rust really does seem to be a nice language and here for the long haul so bumps in the road are opportunities for improvement rather than moments to sow seeds of doubt. From the link title, I thought that someone had died or that Rust was fundamentally broken, but:

- The internet will be the internet and that's, unfortunately, here to stay.

- Being a maintainer can be a less than thankless job and that's a bummer but also a fact.

- Reddit can be toxic, news at 11.

I had assumed that 'unsafe' was a rarely used aspect of the language (as it is in Haskell and as duck-punching is in Python). It seems necessary (to me). It might be used more often than it should be? Hmm. Okay a little unsafe-coverage tool should allow for quick assessment. Of course, FFI libraries will be heavy on unsafe but use them at your own risk...

All successful software projects pass through previously-small-problem-becomes-big-problem stages ("Argh. Looks like it's time to move from Pivotal to JIRA..."). I don't find Steve's melodramatic response to an opportunity to "level-up" to be particularly helpful.

I do think it'd be great to have an unsafeness analyzer (if there isn't one already) and to expose those values in cargo.rs. And to follow other safeness-flag recommendations in this discussion. Were those in-place or in-flight, most of TFA would have been "the internet has driven away the maintainer of a good project and that's not good".


Perhaps we can get at a deeper, more durable insight if we assume for a moment that most individual actors are well-intentioned, and that the described vitriol on one side and perceived stubbornness on the other is an externality of the unfortunate incentives (or lack thereof) that are parasitic on the open source community.

It's almost instinctual/natural to misjudge the popularity of any project for some false sense of security or acceptance. Just think about the numerous issues that plagued the Node community around NPM packages with large amounts of downloads and GitHub stars that turned out to be problematic.

For me the deeper insight here is that we all sort of want our cake and eat it too. Project maintainers/owners want the freedom and enjoyment of working in open source building fun and useful things without any explicit commitments, and that's fair and understandable especially without any formal compensation. And the users want to be able to have access to a growing collection of projects without having much skin in the game, i.e. paying for it.

This isn't a problem with people, this is a problem innate to open source, and the double-edged sword that it is.


It is a problem with people, people wanting to have their cake and eat it too. Open source is made of people.


You're right in the sense that, at the end of the day, almost every organizational/social structure is made of people. The interesting thing for me is to see what incentive structures are at play that incentivize otherwise good people to do apparently bad things.

We can think about these larger, emergent structures like programming language and open source communities independently of the individuals that comprise them.


I can see where Steve is coming from about the difficulties of maintainer-ship - I only have a few projects that I am actively maintaining and obviously nothing close to the scale of a popular library. But at the same time I really think almost all of the blame in this case rests solely with the reception (or lack thereof entirely) of PRs/issues that are intending to improve the quality of a library that many people have come to rely on.

Our entire ecosystem that we have built (for better or for worse) by using these libraries as the foundations for countless projects necessitates that when a community is willing to give their time to improve a library that you maintain, the minimum that is to be expected is that you treat sincere contributions respectfully and not dismiss them out of hand.

It's unfortunate that the maintainer has stepped down entirely instead of changing how they are interacting with the community, but purely from a security standpoint I would rather a slower (but more secure and receptive) library take it's place than have a very popular library maintained by someone who doesn't seem to care about the overall code quality of the library they are a steward of.


Publicising a project doesn't imply anything.

If people come to rely on your project, you are not more responsible.

I've been in the business since before open source was much of anything but a dream, and frankly, I wish a lot of more people would shutter their projects when/if they face these kinds of unreasonable expectations.

The vitriol and entitlement towards maintainers is sickening at times, and unless those affected close the doors, I'm afraid it'll continue to be ignored, and maintainers will continue to burn out.

Burn out is a real problem in the industry, and we really shouldn't help burn people out when it comes to work they do for free!


The problem is that people didn't choose Actix only for performance. I personally haven't used Actix, but it seems that all other contenders were lacking in some way, not only performance but also feature sets and flexibility and easiness. And thus we are now left with a horde of safe but otherwise lacking libraries instead of what could possibly be the best of breeds.


That's entirely fair - and I wasn't saying that choosing actix was a bad choice at the time for the users - but I also think that the people who were willing to contribute to Actix to make it safer are probably also the type of people who are willing to contribute to those other libraries to make them more useful.

If there is one trend that has been consistent in the development world it has been that there are always people willing to keep iterating on libraries to get better and better implementations.


Well a lot of the reason other rust web frameworks were lacking was that actix-web was so dominant in the space. If the actix-web project is indeed dead, some other projects (such as warp/tower) will get more attention and hopefully become more feature-complete.


I love Rust and use it daily.

Unsafe isn’t something you live without, you just avoid unless there’s a decent reason. Setting aside actix-web, the community has this really annoying obsession with not using unsafe anywhere. You’re not replacing decades of computing overnight, though, and it’s not the end of the world if it’s there sometimes.

It often feels like newcomers and zealots preaching the unsafe issue, too. I have to wonder if the Rust docs couldn’t better point out “the goal is less unsafes, but unsafes will exist - this is fine”. I know it kind of explains this already, but perhaps being more blunt?

Actix-web even with a few unsafe is still more sound than most frameworks IMO. I’ll take slightly better with crazy good performance over not better at all with no guarantees.

Also, look, the other problem is Reddit: I’m starting to think larger projects should squat their name there and redirect to better discussion places. I comment on Reddit sometimes and I roll my eyes every time I’ve done it lately.

End rant, I guess.


I think the issue with Rust and unsafe is that people can't really handle and don't really want ambiguous shades of grey. Rust is harder to use than C or even C++, let's put that out there at the start. It expects a high degree of developer effort and skill, in return it gives memory safety without a garbage collector.

But if the Rust ecosystem has developed in such a way that most popular libraries don't actually give you guaranteed memory safety, then this quid-pro-quo breaks down. Now you're making a lot of effort to use the language and in return you get ... maybe sorta safety, some of the time? That's a rather difficult tradeoff to weigh up. How unsafe is the Rust ecosystem, really? As a Rust outsider I had thought it was used only very rarely and mostly in the standard library, by way of analogy to the Java ecosystem where that's the case. From this situation it sounds like it's widely used, and often for unclear reasons. So does using really Rust deliver the advertised benefits?

The fact this question even has to be asked is going to upset the Rust community because Rust is like most non-JVM languages, it has very poor interop with other codebases which makes it reliant on building a large community to be sustainable. The Rust community has to make Rust as attractive as possible for its own competitive survival. High profile libraries that undermine Rust's only value proposition is therefore a self-destructive trend. Actix Web gets great TechEmpower benchmarks, but at the cost of undermining that whole community's marketing pitch. Not surprisingly things get heated.

As for Reddit, I don't think that's the problem. Reddit is just threaded discussions with a large userbase. There are plenty of languages with active reddits and way less drama than Rust seems to have. Java, Kotlin, C++, Swift etc all have big subreddits and all have had zero community dramas that I remember in recent years. The issue is pretty clearly something related to Rust and its userbase. My guess is it's a combination of small size, lack of interop and the Mozilla leadership setting bad examples. There was a huge Rust drama a few years ago where they went ballistic and censored an entire discussion from Reddit because they appointed as their community manager a feminist ("kill all men" being one of her slogans) who had just finished creating a massive idpol drama in the NodeJS community, and not surprisingly the community didn't like it. That sort of immature move is something you don't see from more professionally managed languages.


You can't squat and redirect subreddits to external sites. I have personally been granted mod of a subreddit that had been redirecting to another website. Its against the rules and the subreddit will be banned at which point anyone can use /r/redditrequest to take it over.

Even if that did work however, people would create adjacent subreddits that would end up to be defacto sureddit, for example /r/competitiveoverwatch.


I’ll defer to you on this, but I definitely know I’ve come across subs where this has been happening for years and they’re not shut down.


Its completely possible that nobody has reported those subreddits to the admins.


> It often feels like newcomers and zealots preaching the unsafe issue, too.

A little knowledge is a dangerous thing. This is true for so many topics.


> there’s this style of response

This type of reprehensible response will keep happening until society finally learns how the internet fundamentally changed the nature of fame. The best explanation of the problem is the video "This Is Phil Fish"[1] by Innuendo Studios. If you haven't seen it, please watch it. It's not about Phil Fish; he is simply a useful example of how fame works on the internet. Please watch the video!

The core problem is that fame used to be opt-in. Becoming famous required infrastructure. Gaining access to that infrastructure required the permission various gatekeepers, time, and resources. You had to work to become famous, because media access was a scarce resource.

On the internet fame became something that happens to you, because the internet IS media access. We're used to seeing fame as something that was chosen; if you didn't want to be famous, you could walk away from the media infrastructure and go back to your "normal life". The famous band could quit touring. Now that everyone has media access, that "normal life" can become famous directly. When that happens, walking away from fame means walking away from your normal life.

[1] https://www.youtube.com/watch?v=PmTUW-owa2w


A few years back I started using Rust after spending many years working with Go full-time and the first thing I noticed was that the team really focused on only providing the language, that libraries like HTTP were being pushed out to the community to contribute. It's a totally fair position for a language to take, but I found it disappointing coming from Go where I knew I could just use 'net/http' and move on to solving problems.

This is the first I've heard of this conflict in the Rust community, but honestly it's not at all surprising. People write lots of web servers and if you're relying on your community to provide critical libraries (http is pretty critical in 2020) things like this are bound to happen. I really wish Rust core could provide a standard library of tools more akin to Go as I really enjoyed working with it when I was learning it.


The language team has been focusing on providing the primitives needed for an efficient HTTP client and server, that is, async/await. That only got stabilized a few weeks ago. If we had put HTTP in the standard library before then, it would have only been synchronous. That would have been a huge drawback.


Oh absolutely, you actually mentioned that to me a few years back when I was first looking at Rust, and that’s a totally reasonable place to have been in. It’s just unfortunate that so many people decided to depend on an external library/framework and then got upset like this. For me it meant Rust wasn’t a language I should use for web servers at that moment, which hopefully won’t be the case for too much longer. I will say that as a user it’d be great to see an officially maintained lib like ‘net/http’, even if it isn’t a part of the std lib itself.


This is very difficult. I feel badly for the author of actix-web, and I agree with Klabnik to the extent that Reddit can be a terrible place.

What I think this is, is a sad day for the Rust community.

But it is probably a good, and necessary step for the Rust ecosystem. The bottom line is the creator of Actix made something really attractive, but not necessarily good¹, which pulled a lot of people in to using it. It did extremely well on benchmarks, which brought Rust positive attention.

But the project was fatally flawed unless another maintainer forked it. The author was not obligated to accept patches from anyone else, but it was and should be unacceptable to the Rust ecosystem for the most popular web framework to have severe vulnerabilities that can be exploited. And for the author and maintainer to disregard patches to those issues as "boring" or other derisive terms should also be considered unacceptable.

Perhaps that would have been the right way to fix this actix-web issue, to produce a better project. This is basicaly what happened with cabal (package manager for Haskell) and stack (a wrapper that made it easy to build Haskell packages). But at the same time I can't in good conscience recommend anyone use cabal, nor could I recommend anyone use actix-web. It may very well be for the best that they just won't be used.

¹ - Good has lots of different connotations. Is there a lot of code? Yes. Is it largely well written? I think so, based on what I've heard. But in the long term having a benevolent dictator for life controlling a major piece of the Rust ecosystem is extremely dependent on them being benevolent, and rejecting critical security fixes and declining to engage the community in any meaningful way is not this. On the other hand, I think projects like async-std and tokio have a much more benevolent (and less dictatorial) leadership.


Not the point of this thread, but cabal is quite good now with its Nix-style local builds. The meme of "cabal is bad" perpetuated during the rise of stack is just wrong now :)


Question: why didn’t the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.


Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.


> Forking is extremely aggressive

This is not so. If you said "forking can be perceived as an aggressive action"* I would not disagree with you, but in the context of an FOS ecosystem, forking should not be perceived as aggressive, and it definitely is not inherently so. If someone doesn't want anyone to fork their project, why release it under an open source license? Free/Open source, full control: pick one.

I object to the characterization of forking as aggressive first because it's not, and second because it cuts off another potential avenue of redress or action. We already agree that "shouting on twitter and reddit" is not a good response. If you declare forking off limits or "impolite," what alternatives are left in a case like this?

I acknowledge the complicated ecosystem impacts of forking a popular project (I'm from the JS world where the impacts are extreme), but I don't think "let a project stagnate or yell and shout because the maintainer has other priorities" is a better alternative.

Forking a project in a case like this should be seen as "putting your money where your mouth is"/"stepping up to the plate"/taking on responsibility for change if you think a project is going in the wrong direction. Personally, I fault bitter complainers who don't fork a project for being lazy: do you care enough to actually do the maintainer's job, to take on that responsibility? If no, then what gives you the right to condemn them? If yes, great! Your problem is solved and you can maintain rather than complain.

More forks please.

* just as asking someone "where are you from?" can be perceived as aggressive but that doesn't make it objectively/inherently aggressive.


I actually agree with you in a general sense, but our own opinions don't really matter much. What matters is the opinions in the aggregate.

I wish that it wasn't perceived as such, but the reality is that it is. Ignore that at your own peril.


Why? What's the danger here? Is the original maintainer going to send someone named Vinny to break your legs if you fork a project that won't accept a security patch you need?

I think you should just fork it privately, apply your patch, and move on with your life.


If you're keeping it private, none of this applies. I'm talking about "hey that project is bad, I am now maintaining a competing project, please use it instead."


Instead of framing it as "that project is objectively bad, my one is better", why not say "my project is a fork of this project but with a bit less unsafe" and then see what the community does?

Forking isn't provocative. Forking and then claiming your fork is objectively superior is.


What peril? Why is everyone treating online outrage mobs as if they had any power or authority? Who cares if some unimportant anonymous commentator thinks a fork is aggressive?


If you are trying to get people to use your project, understanding how those people perceive your project is step 1.


Agreed. But how do we define "people"? Are your prospective users all hanging out on Reddit and Twitter? Or are these two communities, as I believe, vocal but unrepresentative slices of a much larger potential silent user base?


Totally, I think that sometimes, forks do make sense! Sometimes, you have to be aggressive, and people will find it justified. io.js is a great example of this happening and working.


On the consumer-dev side, more forks make discoverability much harder. It really helps when there's a canonical place to find a given piece of software. Having to follow comment threads across various platforms to find the most stable version with that feature you want is a huge pain.

Also the core dev(s) for larger projects are usually somewhat responsive, whereas devs who fork to add their one feature usually aren't signing up for that core maintainer experience when they do so.


Forking can be friendly too.

I wanted SimpleProtocolPlayer to be in F-Droid. This requires the author's explicit consent. Unfortunately, the author had not been seen active on the project for a while and did not respond to our questions.

I forked the project so I could be the "author" and give my consent (yes, clearly a hack), told them about it, and my willing to merge back at any time. See [1] if interested.

They eventually told me they were fine with the fork, and preferred having a fork for the F-Droid version of the app so we did not have to rely on their responsiveness.

My fork included a fix that they merged.

Some situations warrant a fork, and if communication (about the intents, the means and the expectations) is handled as best as possible, the fork can be seen as friendly by everyone.

You are right though, I would not want to become the maintainer of projects I sent a patch to. And by the way, I did not really want to become the maintainer of the F-Droid version of SimpleProtocolPlayer at first, but this is fine.

[1] https://github.com/kaytat/SimpleProtocolPlayer/issues/21


> Forking is extremely aggressive

Shouldn't we disabuse ourselves of that notion? Forking a project to solve an issue is just that. We shouldn't attach any sort of emotional connotation to it.


Ah, emotion. Both the greatest strength and the downfall of humanity;


> Forking is extremely aggressive

We are already WAY past that line, just because people don't fork

> and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

So DON'T run a project. Fork it, fix your problems and be done with it.

This seems to be at the core of the disagreements in this thread, one argument being that you shouldn't be expected to maintain a community project just because you put code on the internet.

Expecting that will lead to less open sourced code, which is bad IMHO.

Lastly, your last argument argument reads a little bit as "Not everybody has the desire or time to run a project, so what they want is somebody else to do it"

I might be reading in to much into it though. This thread has a fair amount of pronounced entitlement.


> and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project

But at the same time, why should the original author do it? No one is paying for his or hers time.


> Forking is extremely aggressive,

Is it really, though? It is more of an "agree to disagree" situation.

Just like the maintainer doesn't owe you anything, you don't owe the maintainer blind loyalty, either.


Forking is an act of love. If you fork a project of mine, you show that you care enough about it to maintain it yourself, but your time and energy into my "original" code.

Forking can be aggressive if you write deprecating things into the forked project's readme, but of course you don't have to do that.

You could also talk to the old maintainer before forking; maybe they are happy to give up some responsibility, or maybe they even endorse a fork.


When there is so much discontent in the community a fork is a very natural consequence. This, in my opinion, is open source working well.

https://en.wikipedia.org/wiki/Ethereum_Classic


Forking for their own use would solve their problem though wouldnt it? Just forking doesnt actually mean they are trying to take over a project.


Ah, point taken. But perhaps it’s better in situations like this where the original maintainer feels harangued by the community?


In theory, but that doesn't really matter if that person doesn't exist, you know?

In that case, simply moving to another project is the best option.


Forking someone’s project because they won’t accept your PRs will definitely make them feel harangued by the community. I’m not sure if it necessarily has to be that way, but creating a hostile fork is conventionally considered very rude.


This should change though. That's the correct course of action if a maintainer won't mainline what you want them to. Or is absent altogether.


What makes it hard is that upstream users have no attention bandwidth to dedicate to your project's (meta-project's?) internal disputes. They're just going to decide which fork they think is the main one and use that. If you look at Presto, that's a good example of how hostile forks tend to go; both sides have to insist they're the real project, the main project, because otherwise nobody will use them.

Maybe there's a solution to that other than avoiding forks, but I'm not sure what it would be. It seems like a pretty fundamental challenge.


Not every problem can be solved by new tech.

But… are there ways forking could be made less aggressive (perhaps easy re-joining, community-based PR review and testing)? I remember this was a huge deal in the NodeJS community a few years back—it took a hostile fork to get the conservatives and progressives to agree on a way forward together.


Forking the code is "easy" (OK, maybe not based on the other comments), but anyway...

Another (persistent) problem has been the crates.io namespace.

You can fork actix, but then you'll need to come up with a new name for it, and then educate the wider community of that. It is a big hassle, and slows adoption.

Adding onto the issue is that crates.io does not (yet) support the username/projectname naming scheme as on github and other popular code repositories. So it isn't enough to just people to go to a different username, you must use a new project name.


I don't see that as a major problem in this situation.

Given that the actix author already wanted to take a step back after the last incident, and also seems to be generally okay with giving the project away, a fork could also be officially advertised.

Word also travels fast in communities, and if a viable fork does come up, people will quickly start to recommend it.


I think it's worth pointing out that this is about an article and a Reddit discussion posted literally yesterday. A fork might already have been on the way. Maybe someone was working in a private repo. It's clearly a worse solution than fixing the original so even assuming someone was willing to maintain a fork, it's not surprising that they wouldn't do so at the first sign of trouble.

If you do look at comments by safety-focused developers from earlier actix drama, you'll see that quite a few simply use a different project. The answer might be that actix doesn't provide enough value compared to alternatives to be worth forking for those people. The people aggressively attacking actix might not even be interested in the project for their own use, but merely there for the outrage.


Exactly. Like the GraphicsMagick fork of ImageMagick.


It is so much less work to whine and complain and poke holes in other people's work than it is to roll up your own sleeves and dive into the shit yourself.


The larger pity, to me, seems to be the maintainer's decision to not only quit the project, but to take down the repo with the intent to delete it:

https://github.com/actix/actix-web

I get it, they feel personally harassed and slighted. And it's their project, they can do with it what they like. But it still feels like the decision is motivated more by spite than by a desire to simply wash one's hand of the project. Surely there are not hostile developers who would've been willing to take over the maintainer role.


I see what you mean. But how about seeing it in the other direction:

Imagine how much the maintainer must has been burned, in order to take the decision to shut down their entire love-work – in hope that the toxic situation will stop.

From our point of view, this may not be the best decision. A desperate one, maybe. But to imagine how the person must be feeling to think this is the best way out.


It got moved to their personal github account, not deleted.


He said he is going to move it to private in his [post mortem](https://github.com/actix/actix-web)


This seems to me the most relevant quote:

"(Btw thanks to everyone who provided prs and other help!)"

So the maintainer was grateful for the PRs, but worn down by all the people complaining without contributing.


He says that he might do that, depending on how the next couple of days go. Regardless, it's not gone yet.


Here's the reddit thread in question:

https://www.reddit.com/r/rust/comments/epoloy/ive_smoketeste...

I have no doubt it led to some github issue brigading, but it's not really that big of a deal. Ostracizing /r/rust in a mealy mouthed way probably won't make that community better...


Yeah, I feel people here attack /r/rust with even more vitriol than /r/rust attacked the author of Actix. Plenty of kettles here.


Yeah, I agree. “It’s all reddit’s fault” is not helpful at all and simply wrong from reading that thread.


You cannot get the full context from a single reddit thread; as I mentioned in the post, this situation is the product of multiple events. You'd at least need the posts from all of them, let alone that this is only one of the posts from this situation on reddit in the last day.


I mean this in the most respectful way possible, but have you considered your own antagonism against Reddit is not healthy for the community? Throughout the years I've seen you talk down about Reddit and the people there quite a bit. I get that they're "rougher" than the ideal Rust citizen but they're also real people and members of the community. It's probably best not to judge one of the largest sites on the internet if for no other reason than it breeds hostility.


I go back and forth on it. I try to also say that I think /r/rust is better than most Reddits, but I think the core problem is structural, and what I say doesn’t matter that much.


Fair enough.

FWIW what you say matters a lot, pretty sure you have a ton of respect from a lot of engineers across multiple language communities (myself definitely included).

I definitely appreciate how difficult it is to be the "custodian" of a) a language community and b) an open source project within that community.


I think that's where some of the confusion comes in.

You say:

"Some people go far, far, far over the line."

So some people are assuming this is just the maintainer responding badly to people pointing out problems with his or her code, but you are saying it went far beyond that into personal attacks?


Yes, they did. I posted an example of a particularly egregious one elsewhere in this thread.


Yeah, saw that. Criticism of code should turning into personal attacks is never justified.


There were some personal attacks on GitHub.


This is an unfortunate, but I think necessary part of community growth. I really don’t think it’s possible to create a large community around a language that is business critical, and not have these kinds of setbacks where people get worked up and hurt each other’s feelings.

Python has many of the same issues, where core devs and key maintainers go dark or behave badly. What Python does do pretty well, and what I like about it, is placing its core user front and center. For Python, that is the beginning programmer, and Python has a lot of empathy for him or her. What I also like about Python is a general willingness to have difficult conversations and back rebuttals with code snippets.

I read difficult conversations by Bruce Patton a while back, and it wasn’t an easy read for me because I have problems of responding sometimes in a constructive manner, but I learned a lot and I would highly recommend it .

I’m confident the Rust community will survive this and come out stronger than ever :)


Yes, but I wonder how many of those 50K users are "business critical" and how many are there just for trolling, gossip and drama.


I love Neil Gaiman's "Entitlement Issues".

To sum it up: "George R.R. Martin is not your bitch."

I would carry this even further: "Open source maintainers are not your bitch."

I see a lot of whining and entitlement from engineers on open source repo issues pages. Open a pull request, fork it and host it yourself, and just relax in general.

Not to say maintainers can't be jerks. But again: That is their choice. They are not your bitch.


This is a sad day for Rust. Situations can spiral out of control. Who started it? Who escalated it? You can't really define these because communication is sloppy and difficult, especially when there are cultural and language barriers involved. The only way to not get these situations to spiral out of control are a thick skin, forgiveness, and assuming noble intent.

There have been times on here where I see discussions around `unsafe` as if it was a curse. I think the discussions, over time, have gotten more nuanced which helps.

I also wonder if expectations were unclear. It now sounds like the focus of Actix was on performance and creativity / cleverness and not on being a mature product. I never heard that before. Maybe even the author didn't even originally articulate it so clearly but discovered it through these discussions.

Going forward, I hope someone archives their clones of actix and that people fork that and get it moving forward as a product. I hope people don't take a religious view of removing `unsafe` during the fork but instead follow best practices (benchmark to confirm the need, abstract it to test it, offer a feature flag for the paranoid to disable as much of it as possible).


No, it's a happy day. This won't be the last such event. People who care will learn to keep track of details they care about, and certify -- and de-certify -- without drama. Not all modules are right for use everywhere, but all are right for use somewhere, including those only trusted for personal projects.

Some of the latter will be forked, and the forks certified to higher levels, and those forked again and the forks certified or de-certified again.

This marks a step on the way to maturity, right on schedule. By the evidence, in ten years Rust will be a mature language, much more quickly than some. Most don't get there.


> I also wonder if expectations were unclear. It now sounds like the focus of Actix was on performance and creativity / cleverness and not on being a mature product. I never heard that before. Maybe even the author didn't even originally articulate it so clearly but discovered it through these discussions.

That's actually my main sticking point on this being mostly on the maintainer. From the actix documentation, releases, and promotion, I never got the feeling that it was _not_ meant for production. Even to the point of the comment "Microsoft uses this in production".

And suddenly, "It's creative/fast/research/whatever"? That really feels like trying to sidestep findings because you don't want to lose your spot in the techempower benchmarks. Even more so, when the documentation, etc. is not updated to reflect this new focus, and there's no announcements about it.


I really want to like Rust. Every time I try to use Rust on a project, I end up down a rabbit hole of internet arguments and unnecessary drama. When I finally give up on Rust, I find I can accomplish the same task in a fraction of the time with a more mature language. At this point, I think Rust is best reserved for very narrow use cases that can be shown to fit neatly within Rust's current ecosystem before coding begins.

Rust is a macrocosm of a phenomenon I've noticed in my own career: My productivity is inversely proportional to how dogmatically "correct" I'm trying to be with my implementation. The Rust community embodies many of the negative aspects of perfectionism that tend to stall real world progress. That perfectionism doesn't necessarily carry over to your code, but I find myself wondering if I'm doing things "the right way" far more in Rust than other languages.

Some growing pains are normal for any community. I really hope the Rust community can settle into a healthy environment. Until then, I'll reserve Rust for only smaller projects where I can afford to bail and rewrite in another language if it starts to spiral in complexity.


Tried reading through this but without context it’s very unclear what has happened.

Can someone familiar with Rust and it’s communities explain from a high level what all this is about?


The really short answer seems to be: actix was a Rust web framework. It did some things internally that some people didn't like. The Internet echo chamber picked that up and amplified it to a volume the maintainer couldn't justify working through. The Internet echo chamber is now going to pick this up and amplify it to a volume that probably isn't justified either.

I think this is another story about the destructive power of the internet echo chamber, where the asymmetry of one person vs. a mob of people who are in reality probably not all that engaged with the problem but nevertheless have enough engagement to send a nastygram or two creates a distributed denial of decorum attack that no single human being should be expected to deal with "nicely". Our ancient instinctive tribal signals of whether or not you are approved by the tribe, tuned for tribes of 150 people or so, receive a message that 15,000% of the tribe thinks you are a bad person, and our natural human response to that is a lot of stress at best (our ancient instincts tell us that eviction from the tribe is a bad thing, even though in practical terms eviction from this particular tribe won't be much of a problem at all in the modern world).

(I phrase it this way because I think this is, well, not strictly speaking independent of the question of whether or not the maintainer was guilty or innocent of any particular thing, but because the story is the wild disproportionality of the response you can get on the Internet regardless.)


"Denial of decorum attack" is a great description that deserves broader visibility. It's also a pithy summary of Twitter.


That is actually an awesome explanation.

And absolutely correct in my view. I have been on the receiving end. I have friends who have been on the receiving end. It really is overwhelming to receive that 15,000% signal, nudged along by the dynamics of the rest of the tribe.

I really like that you found a way to cover this aspect.


Good explanation. One could argue that you see this playing out in Politics and News Media.


Background: Actix-web is a small, fast web framework written in Rust.

Then just read the second last paragraph:

> This means, on some level, this situation is over: there will not be a fourth huge actix-web drama. But it’s really left a bad taste in my mouth. It’s unfortunate that a well-known project had soundness issues. It’s unfortunate that the maintainer wasn’t receptive to fixing them. At the same time, I’ve been there: being a maintainer is tough. It’s also unfortunate that there’s this style of response, and kind, and volume. It is true that the situation was dangerous. But did it have to be handled this way? You have to understand a lot of nuance here to even know the main points of the story. One version of this story that will certainly be told is “The Rust community says they’re nice but they will harass you if you use unsafe wrong.” Is that what we want? I, for one, do not. If you’re a part of Rust, you gotta ask yourself: are you happy with this outcome? How did your actions (or lack thereof) contribute to it? Could you have done something better?


You can take a look at the actix-web repo, which has been wiped. A message has been added:

https://github.com/actix/actix-web/


I'm glad git is decentralized.


And you find it here: https://github.com/fafhrd91/actix-web (the author moved it to his personal repo)

See this comment at GitHub: https://github.com/actix/actix-web/issues/5#issuecomment-575... — it also links to a mirror.


Repo wiped after receiving criticism. I think I'm beginning to see another side to the story other than reddit being a swarm of jerks.


[flagged]


Actix was not at all "shit". People just took some issues with a few usages of unsafe and how the author responded to issues/PRs. I've been using actix for about a year now, and was excited for the 0.2.0 updates.

That said, pulling the code entirely and deleting issues was a rather immature response.

As a rust user I just don't know what another good alternative is. Warp, maybe? I'm debating about just writing http stuff in Golang due to its robust standard library instead of picking among several fledgling 3rd party http libraries.


I'm not sure you can consider "It’s extra nasty this time. Some people go far, far, far over the line." to just be criticism.

What does it say that I wouldn't be surprised one iota if "far, far, far over the line" included death threats? Nobody should be expected to continue to contribute in a community with that kind of vitriol pointed their way.

EDIT: Even if all "far, far, far over the line" means is personal attacks and not death threats, that is still not simply criticism, and it's still far beyond what someone should be expected to endure in the name of "open source".



The Rust community is filled with Don Quixotes who treat maintainers of popular open source packages like they are dimwitted sidekicks.


A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this.

I have two simple mantras which establish my philosophy here:

1. YOU are responsible for your dependencies.

2. Open source participants are volunteers and owe you nothing.

It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change anything in the slightest. Your dependencies are your responsibility. Responding with vitrol, anger, or hate when failing to uphold this responsibility bites you in the ass is just being a jerk.

User entitlement is totally unjustified and will burn out maintainers faster than almost anything else. I don't stand for it. If any other maintainers out there are struggling with this, please send me an email: sir@cmpwn.com. I'm sympathetic to your cause and I can likely lend some pertinent advice.


Meta-comment:

Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based.

Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.)

Much of what makes online (and offline) arguments so unproductive is confusion over where exactly people are disagreeing in the first place. There's no point in discussing whether someone did the right or wrong thing if you don't even agree on the principles by which that rightness or wrongness will be judged.

If I disagree with one of your principles, we need the discussion to be at that level, or more likely, we simply must agree to disagree. If I think there's another principle you aren't considering, we can debate its relevance. If you're missing key information, I can provide it. If you're misinterpreting something, I can offer my alternate interpretation and justification for why I think it's better. In any case, if I disagree, it's clear how to proceed because your line of reasoning is clear. We can engage in a productive discussion without talking past each other.

As it stands, I agree with you 100%, but more importantly, you have raised the bar for discussion on this contentious issue. Thank you again.


In addition to the (great) framework you listed, there is another big factor - incentives. You may be aligned in principles, have the same info etc. but if your incentives are misaligned it can be hard to agree.


Thanks for this comment - mirrors my thought/question. I think the understanding incentivisation is hugely important in understanding human behaviour and choices, and this seemed an obvious omission.

However, I was trying to process whether incentives are essentially part of your principles? i.e. if an incentive to do something against your principles is so strong that it wins out, doesn't that mean you've effectively abandoned (or changed) your principles along the way?


Surely a disagreement based on incentives is not an honest disagreement?


I think disagreement on incentives plays out as how prioritized something is viewed. I may agree that something is wrong, but not worth it for me to fix during a weekend because I don't get paid overtime for it. As an example.


Aren’t incentives hidden principles?


This is a bit Pollyanna. People aren't logic robots that start from first principles and then derive all knowledge from logical reasoning. People are emotional, irrational beings. Those of us who fancy ourselves rational are constantly involved in irrational motivated reasoning helping us maintain that desired worldview.

Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But there's not some category of honest people among whom you can avoid human nature.


People are not robots, but in terms of reaching agreement between humans, "emotion" is more or less just a difference in priorities, which is one of the ways reasonable people can disagree.

If we agree on the facts and we agree on their implications, but we still disagree, it's likely because we weight things differently. Emotions are simply a large component for how we weight things.


emotionalism is strongly linked to irrationality. once someone is irrational I'm not following how that can be reduced to a "difference in priorities". I'm an open source maintainer of some very popular projects. more in the early days, I was certainly irrational on a few occasions where someone called out things that I did wrong and I refused to see it. It wasn't like I had de-prioritized "making sure the code is not completely broken". my own fear that I was going to have to rethink a whole huge set of assumptions (which of course I had to do anyway) prevented me from working with people.


But rationality (in the human sense) is completely governed by emotion. Curiosity about an unsolved problem? that's emotional regulation of the brain. Satisfaction that a problem is solved? also emotion. Beauty in a better solution? emotion.

This has significance, it's not just a restatement of "the problem" using different terminology. It's significant because the brain, like every other part of the body, evolved parsimoniously, and it does not have spare capacity lying around, so anything that "distracts" the emotional parts of the brain will diminish rational capacity. "Hangry" is not just a pun/quip about being hungry, it's empirically measurable, it affects outcomes.

Debating rational topics with your rational friends, whether at work, at school, or after hours over a beer, it's fun (emotion), can be frustrating (emotion) but does it ever not get heated (more emotion)?

The brain is an emotional organ. All the other organs are rational, they do what they do in entirely predictable and logical ways.


this does not negate the fact that a breakdown in rationality is also caused by emotion. the human brain is emotional throughout. however the part of it that has "rational debates" is not an intrinsic behavior. that part is based on cognitive skill which will perform to a greater or lesser extent based on current brain state. if the amygdala is active in a state of fear or anger, "rational debate" skill will be compromised, since that is not a useful skill in the traditional evolutionary situation that calls for fear or anger.


now this time I will employ simple restatement to help convey the point I'm making--and for you to be rational is for you to first simply understand what I'm saying; arguing back is not entirely rational, it's actually an additional emotional step:

think of rationality of the brain like a signed vs unsigned char in most implementations of C, basically a byte: you could think of a byte as 0-255 or as -127 to +126. The brain is an emotional organ. Rationality is the best possible outcome, but it's not the default state; the brain doesn't function from 0 to 255 rationality, it functions from -127 to +128.

I say it this way because you talk about rationality "breaking down" as if it's some sort of default. I don't think of it that way. Rationality is something we hope to build up to and are lucky to achieve, but our default state is animal passion.

I'm not trying to convince you to change what you think, just using some restatements to open your thinking to the way psychiatry views the brain.


> I say it this way because you talk about rationality "breaking down" as if it's some sort of default.

I'm sorry, can you please explain how you come to this conclusion based on what I wrote:

"however the part of it that has "rational debates" is not an intrinsic behavior. that part is based on cognitive skill which will perform to a greater or lesser extent based on current brain state."

I'm not really arguing with you, as your first point seemed to be some kind of "but what about...!" that didn't really negate what I was trying to say. However if you think I was saying something completely different, that would make more sense for whatever it is you're attempting to "argue".


> I was certainly irrational on a few occasions where someone called out things that I did wrong and I refused to see it.

I don't think that's a problem with the emotion itself, so much as which specific events trigger that emotion and how you chose to process them and react.

Having fear does not make you lash out at users. We all have fear, often about similar things. It's having fear associating with a person calling you out, and then failing to process that fear in a healthy way that caused you problems.

Very rational people still have lots and lots of emotions. They are not robots. They can just handle their emotions in a mature, mindful way.


I employ mindfulness on a daily / hourly basis in my own life and especially when dealing with the large number of requests I deal with every day.

In those times that I have not been able to respond politely or rationally, my lack of mindfulness as well as my own emotional reactiveness to certain stimuli (e.g. triggers) was at the core of it.

that is, if a request is not triggering strong emotion in me, I don't need to employ patience and mindfulness in order to have a reasonable and rational response. If a lot of requests are in fact triggering, this is what I would term "emotionalism", and I have to work much harder to have rational responses. Hence emotionalism is linked to irrationality especially for someone with fewer emotional maintenance skills.

emotion is not a "problem" any more than the urge to go to the bathroom is, however, both require proper training to be dealt with.


Life might be easier if emotions were that simple. :-) I've worked with several people to help them overcome emotional baggage. It is quite challenging. It's true that many emotional differences can be eventually distilled down to a difference in priorities, but helping someone discover the essence of an emotional issue can take years.

Even mature people often can't reason their way out of a conflict on their own. When people feel personally threatened, sometimes no amount of simple reasoning will bring them back to rational thinking. Most of the time, the solution is to be a genuine friend--for the long haul.


To the point of "honest people": I added "honest" in editing to distinguish from people who are just arguing because they like fighting and wouldn't agree if you told them 2 + 2 = 4. There are plenty of those online too, and their reasons for disagreeing clearly aren't covered by my "reasons people disagree" principle.

But as I understood you, point taken. The distillation of principles, information, and interpretation into an opinion does not actually occur as idealized in my breakdown. I wouldn't disagree with that.


More explictly: the hardest person to be honest with is yourself.


I’m not so certain emotion and logic are so fundamentally separate you know.

Perhaps logic is just our way of explaining our otherwise unexplainable decision making systems.


My belief is that intuition and emotion are just complex sets of logic that we haven’t understood yet.

Put in the time and focus, and one day it will just click.


I think the emotions and really the whole operation of the mental states is reasonable, but not internally logical. They arise in predictable patterns from experiences and so on, but they can very easily override logic. To understand your emotions, you have to see and admit you aren't the nice logical person you might have expected.


they will be understood someday, but only by highly advanced mathematical models developed through machine learning.

models which humans will not actually be capable of understanding.


Decades ago, my coworkers and I would draw FSMs of our mgmt on the white board with cryptic lables. While they did get complicated they were understandable.


It's biological (aka biological determination). There's the famous study of how judges handed out verdicts based on what or when they ate:

https://www.pnas.org/content/108/17/6889


What if it's actually only those who are honest who have human nature?


Hey, hey. Speak for yourself.

;-)


> 1. YOU are responsible for your dependencies.

They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back.

Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code.

Sadly, that led to some comments by people frustrated with the project, since they had likely invested considerable time at least using, if not more. But this was a situation that is entirely avoidable if Nikolay would have stopped promoting Actix as for production use.


> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish

So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one.

With those PRs written, _anyone_ on the internet can apply them and use them in their software. I agree with GP, you aren't owed anything, and that extends to any form of social behaviors online. And let's not forget that even the most 'perfect' maintainer still deals with shit on a regular basis from the masses of people demanding features as if they got paid to write the free software people are using.

This expectation of being served high-quality open-source software for free, and then outrage when it isn't, is absolutely ridiculous and will make people not want to maintain software.


> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them.

It is when they setup an open source project that has that appearance and is framed as being such a project.

It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant to be then it should have been framed as such (such as by being in a personal repo for starters). This project promoted itself for production usage, requested feedback & patches on its project page, and had a github setup that gave an appearance of being, for lack of a better word, professional. That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project.

None of that at all forgives the name calling & mud slinging they were subject to, of course. Two wrongs don't make a right. But the maintainer was still also "in the wrong" here. They needed to hand off the project much sooner than they did when they realized they were not at all prepared or ready to handle what they promoted the project as being.


> It is entirely the maintainer's responsibility to establish the type of open source project it is.

On what basis does a developer assume this responsibility? You are saying that by uploading a library that works well, and whose presentation (docs, etc) are high quality ("professional") that the owner now has the responsibility to publicly state whether this is a personal project or not, and they must state their SLA and process with respect to accepting patches? No such thing.

> That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project.

If the maintainer says "I shall provide X amount of service" but then does not, that's on the maintainer.

But if a user likes a library and starts depending on it without checking if the library is "properly maintained", that's on the user. How can it be otherwise?


> You are saying that by uploading a library that works well, and whose presentation (docs, etc) are high quality ("professional") that the owner now has the responsibility to publicly state whether this is a personal project or not, and they must state their SLA and process with respect to accepting patches?

No, I'm not. I'm saying if you setup an open source project framed as a project that is production ready & open to patches with a guise of being run by an organization and intentions of having a community, then it is reasonable to expect that you actually do that. You don't accidentally make a github organization, after all. There are community norms around what you can expect when working with such projects. Particularly when then both the github page and the webpage speak of being welcome to contributions ( https://github.com/actix/examples#contribute ) and building a community.

This was not just a high-quality library tossed out into the wild that got adoption. This is a library complete with these pages https://actix.rs/community/ & https://actix.rs/code/

The author did a hell of a lot more than just "uploading a library" here. As such, the developer assumes these responsibilities because it's what they said.

You are always responsible for what you broadcast.


Read the license, it frames the project exactly.


The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis.

Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.


> The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis.

You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user.

Therefore, any other supposed obligations only exist in the mind of the person who has created them, and do not exist in reality.

> Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.

Sorry, this doesn't make sense, because you're comparing an explicit statement of liability in the license to the social norm of not being a massive jerk.


> Sorry, this doesn't make sense, because you're comparing an explicit statement of liability in the license to the social norm of not being a massive jerk.

Of course it doesn't make sense, that was my point! In the same way it doesn't make any sense to do what you're doing, which is comparing the explicit statement of liability in the license to the social norm of how open source projects are framed & run.

You missed the point that everything we're talking about is just social norms. The license is irrelevant here, for all sides. There is no legal issue being disputed.


No, everything is not just social norms, because there is no agreed upon norm or standard "framing" for open source projects (as indicated by all the disagreements here and elsewhere on this topic), leaving the actual license as the only concrete, agreed upon description of obligations and expectations between the creator/maintainer and users.


> You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user.

There's a word for people who only fulfill their legal obligations: Assholes.


> There's a word for people who only fulfill their legal obligations: Assholes.

There's also a word for people who expect others to meet their expectations without contributing anything on their end: Assholes.

If you explicitly state up front what you're willing to do to support a project, and I come along demand you go above and beyond your stated limitations, who is being unreasonable here?


Oh yes, the assholes in this particular situation are without a doubt the people attacking Nikolay over this.

However, I read your earlier comment as meaning roughly "anyone who releases any software under an MIT/X11 license has zero obligations to anything regarding that software period" which is something I do disagree with.


My point is that consumers of software released under licenses which don't obligate the creator to do anything shouldn't expect more from the creator than that.

If the creator does act as a "good steward", that's great, but you shouldn't plan on that being the case or be surprised when it isn't.


I think we are in agreement, though I wouldn't use the word "expect" in that way.


How would you use it in this context?


> There's a word for people who only fulfill their legal obligations: Assholes.

There's also a word for people who stake their professional reputation on the work of random assholes on the internet.


The license is to a project's readme what patent claims are to the rest of the patent document: when there is a conflict, it's the one thing both sides can agree on.

However professional and well-presentend the project is, at the end of the day maintainers are doing this primarily because they like it. If they don't like doing something related to the project then no one can blame them for that.


Every open source project has a warranty disclaimer. It really doesn't tell you anything about how serious the project is.


Open-source means freedom to fork, nothing more. But that's ancillary to the rest of your comment.


Your statement is false. They called for contributors many times, last time in August https://github.com/fafhrd91/actix-web/issues/1019 .. This was public and open message and is not the first time.

Though while people are ready to open issues and complain, sometimes even supply patches and make big noise if they do not pass code review, there were nobody who could join to share responsibility in making decisions about the project.


> Your statement is false. They called for contributors many times, last time in August https://github.com/fafhrd91/actix-web/issues/1019 .. This was public and open message and is not the first time.

That thread is full of people trying to sign up and help. Either they all lied or nobody was accepted.


It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fixes: little responsibility there, but security is something that can hurt a lot of people if done wrong. The use-after-free bug this was about could've been exploited in the right circumstances.

If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.

The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.


> if you write one, advertise one, you need to care about security

The word "need" there is wrong. You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. If you want those obligations, get a contract and pay some money.

What's happened here, and you seem to have fallen into this trap too, is that people believe software abstractions also automatically abstract responsibility. It's certainly not a new mistake.

What this incident seems to show (and I'm not a Rust community person, I've just been reading a lot of the threads/archives about this) is not that the framework maintainer was terrible, but instead, that what he was offering was not what people assumed it to be - some people assumed the project would behave in certain ways, and have invested their time (and presumably money) in building on top of that project, only to discover that the project does not behave how they want and now they feel burned.

I believe that being an unpaid open source maintainer (which I am, and have been, in various small ways, for a couple of decades) means having a best-effort responsibility to your community, but never at the expense of yourself. That is, however, just my belief, and nobody is obligated in any way to share it.

The ancestor post about owning dependencies, while a little more aggressive than I might have written it, is basically right. You don't abstract responsibility for code just because it came neatly packaged - if you don't have a support contract for it, you are responsible for it. That's just basic logic really.

Having said all that, I do think that deleting the repos was a poor reaction - I believe (again, just me) that a maintainer should step aside gracefully when they are no longer the best person to lead a project. If there are people to hand it off to, do that. If not, archive it and indicate that it is unmaintained.


> You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything.

I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different backgrounds. But I think it's reasonable to hold as an ideal that there is a moral responsibility to at least make sure people using your stuff understand what they are getting into. And that such a moral responsibility would require more than disclaiming liability.


I don't think these are contradictory positions. It's a bit like defensive programming in social space: one can take significant responsibility for one's own work while remaining aware that others with no legal/etc compulsion to likely will not.


> I was taught that part of being an engineer taking a moral responsibility for the safety of your creations.

almost certainly in the framework of being employed or contracted to do engineering work. go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time.


> go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time

As an engineer, your first duty is to protect the public, then your client, then your employer. You have that duty to the public regardless of whether you're being paid by a client or not, because it comes from practicing engineering, not from remuneration.


If I build something in real life, like a playground, and ask people to come use it, but then through my own negligence it falls apart and becomes a hazard, it is my fault for having created this situation in the first place.

Idk why this keeps getting tied back to paid/unpaid. I can think of many a situation where someone gets paid, and also doesn't care at all to help.


> Idk why this keeps getting tied back to paid/unpaid

i was responding to a comment about engineering ethics. engineering is a profession. engineering ethics is taught to student engineers in the context of a job, where you're getting paid. taking the (literal classroom) lessons out of context distorts them.

if you go back to your engineering ethics professors and say "gee, but what if i do this work for fun and just stick it up on a web page on the internet", they're going to look at you like you're insane, and then not know what to say.

> If I build something in real life

the last thing this thread needs is more analogies.


> if you write one, advertise one, you need to care about security

No, you don't. The author doesn't owe you a single thing unless you have a warranty saying otherwise. Most licenses explicitly say something like:

   THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
   IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
   WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
If you don't like the terms, don't accept the code. I don't see how that could be more clear.


Half (more probably 99% actually) of our critical infrastructure software use that wording (or an equivalent one), regardless of it is free software or proprietary software.

Yet most are maintained responsibly, if they are used for serious stuff and/or advertise in a way that suggest that kind of usage can be considered.


Everything you ever used in production is "production-ready". The bar is super low, there is no deception here.

The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages may have to include such patches themselves, effectively always being forks, never using vanilla upstream code. But this is only if you care about security a bit. If you just install from language package managers into prod, you obviously do not care about security even a little bit.


So, your advice is that if you care about security even a little bit, you should write all your software from scratch yourself?


You should accept that you are responsible for all the code you run in production, whoever happened to write it. Whether you feel you are more likely to write bug free code than anyone else is your call.


I think it means you should look more closely into the contract you have with the maintainers. Either you rely on trust, like you would do if you used OpenSSL or NaCl because the creators and maintainers are known to go beyond the required minimum, or you get an official contract.


This. There is no free lunch. Either you pay for quality or assurance, or you risk you might get something rotten that wasn't obvious at first glance and you can't do anything about it. That's the difference, when you pay, you might also get something rotten, but you can do something about it. Your options are of course only constrained by what you pay.

The problem, as I see it, is that a whole generation of programmers have grown oblivious to this implicit relationship, and when that relationship is actually exercised in some way, they default to what they understand, which is paid services and products, which results in both sides feeling like they got a raw deal.


Again, in my experience there is very little correlation between how much you pay for something and how rotten it is. And I find the opposite, when you get open source software and it's rotten, you can do something about it. You can patch it locally, even if the maintainer won't accept your patches. If you have a proprietary product written badly, paying money for a support contract will not magically make it a more secure product or guarantee that they will be able to fix your issues.


I think his advice is to purchase a licensed product with a paid support package if you need an SLA.


In my experience licensed products with paid support packages aren't any more secure, they just let you pass the buck when things go wrong.


To some extent, they also come with warranties and insurance policies that could potentially be collected upon if there are damages.

But yes, a lot of it is a legal CYA, which is important.


> "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.".

This is a good opportunity for you to read up on the license you explicitly agreed to in order to use said software in order for you to discover that that's precisely what you agree to when you use said software.

You don't owe the maintainer anything, nor does the maintainer owe you anything at all. The project maintainers donated their work to be used freely as is, and that's the full extent of what you are entitled to.


That is why the Apache license has a responsibility disclaimer, that to the extent allowable under law the work is offered with no warranty and no guarantees, not even of correctness or usability for any particularly purpose. Words still mean things, even after we get so used to copying and pasting licenses that we forget that they mean something. If you expect a project maintainer to take responsibility, ask them to use a license where they take responsibility.


> If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.

This is less building the playground and more providing architectural plans to build the playground with common building materials. If some part is unsound, people might also be upset, but they weren't forced to build using your plans and could have reviewed the plans themselves. Where the blame lies is much more ambiguous than how you present it, IMO.


Holding people legally responsible for bugs in their FOSS code would be a good way to ensure that no FOSS code got written. Ever.


Legally, absolutely agree with you. GP's playground analogy was a particularly bad choice in that context.

Socially though - I don't see an issue with holding major projects socially responsible for egregious failure to fix security flaws. Public criticism is part of the open source model, it's the "many eyes" defense in action. Social pressure would be appropriate if Ubuntu just said "ahh, so, a worm is stealing every user's keystrokes. There's a fix for it but we won't merge it because we'd rather spend our time working on PulseAudio and systemd. If users want to use a forked version that will stop the keylogger, they are free to do so, but we make no guarantees our future changes won't break those forks."


They actually do exactly that. The only goal of Ubuntu is to provide usability. They will care about security to an extent it does not interfere with that goal.

Such as maintainers being overloaded fixing visible issues.

You want a security oriented distribution, you picked the wrong one.


I didn't mean legal responsibility here (perhaps the example was somewhat poorly chosen), but surely there's some level of responsibility here? Bugs happen, security issues happen, facts of life, but actively rejecting security patches is another level of irresponsibility.


> ...surely there's some level of responsibility here?

No, there isn't.

> ...actively rejecting security patches is another level of irresponsibility.

No, it's not, because the project owner has literally no responsibility to you or anyone else in the context of this project.

If you care, you need to fork and patch the project. If you're feeling generous, you can share that fork and maybe others will use it.


> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them.

I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illegal or anything. They can choose to be irresponsible, yes. But personally, I think that maintaining the repo is the maintainer's responsibility. And I think the responsible way to do that involves "following best-practices, responding to feedback/PRs, or responding in any coherent way to anything asked of them."

I'm NOT saying a maintainer should have to add features to satiate the masses. I'm merely saying that a "maintainer" has some small duty to "maintain" a product, and also acknowledging that they have a legal right to abdicate that responsibility.

I'm not sure anyone should be immune from social criticism. They can always make someone else the maintainer and avoid any future work/limelight/criticism.

I won't touch the childish vs. adult debate as it pertains to abdicating one's responsibilities.

I am also NOT saying that people should "expect to be be served high-quality open-source software for free, and then outrage when it isn't." But it seems like it's a maintainer's responsibility to allow (and maybe even facilitate) competent, motivated individuals to contribute to their open-source project.

I also don't know exactly what the reddit brigading involved, this is the first time I've heard of this story. Harassment obviously is not okay and, not coincidentally, is illegal.


Not everyone who uploads an open source project to some random cloud hosting service (i.e. Github) is qualified or wants to be a maintainer. Remember that being a maintainer is equivalent to project management. A lot of people publishing open source code don't seem to care about this and just want to write interesting programs. And that's fine. I personally have sent patches to lots of people who just never responded and their activity trailed off. Doesn't bother me in the slightest, that's what the "fork" button is for.

You also say "legal right" but it's incredibly vague what this is supposed to mean. Nobody cares about this stuff unless the project reaches a certain level of popularity. So once you get over 1000 github stars, should github force you to sign a contract saying you'll respond to emails in a timely manner or they take away your stars? I don't think I need to explain why that doesn't make any sense.


No, no, no - none of this is about legality. Just sometimes people bring it up as a framework for determining responsibilities, so I addressed it ahead of time. I don't think (legal requirements) == (responsibilities). The sets may have some overlap but clearly they are not identical.

Instead, I am just saying that if I upload a "cool tool" to github, and I notice that it has become super popular, and I don't have time/interest/inclination to maintain it --- I would personally feel a RESPONSIBILITY, and probably social obligation (not a legal obligation) to either put a note saying "this is not actively maintained, please find an up-to-date fork. user/cooltool seems to have community support but I can't personally endorse it." or simply make some other people additional/replacement maintainers for the project which I'm not interested in maintaining anymore.


Maybe you do, I'm sure people would appreciate that, but it's not necessary. The nature of these things is that the users are already "following the herd" to a degree. So if the maintainer becomes inactive and a fork picks up the interest, they will just move to that. No ceremony required.


It's not their responsibility. If you want to use the software then use it, if you don't want to use their software then walk away. They don't owe you anything outside of what they are willing to pay with their personal time. No one forces you to use the software. It's open source and YOU are free to take the code and run with it if you don't like it.


Notice how every single line in your comment starts with "I".

You alone decided that maintainers have all these obligations (which I would consider reasonable things to do for the record), but the maintainer of this library doesn't agree, and the license doesn't require it, so you're just setting yourself up for disappointment here.


It seems much of the disagreement may stem from lack of consensus around the semantics of:

'responsibility'

'requirement' 'obligation' 'should' 'can'

I believe responsibilities are personal/societal. They're part of a value system. However, I think I could collate a breadth of sources from landmark open source discussions which show that there are existing major themes for what a maintainer has a responsibility to do (that the open source community has a somewhat predefined value system existing wrt to topic).

I accept that it's not a consensus.

I just don't think we should conflate obligations, requirements, and responsibilities. That leads to vehement disagreements.


> I believe responsibilities are personal/societal. They're part of a value system. However, I think I could collate a breadth of sources from landmark open source discussions which show that there are existing major themes for what a maintainer has a responsibility to do (that the open source community has a somewhat predefined value system existing wrt to topic).

I agree with all of this, but I also feel that you need to be mentally prepared for any maintainer to fail to meet these moral responsibilities unless you want to be disappointed and should act accordingly (not saying you don't already do this in practice).

> I accept that it's not a consensus. I just don't think we should conflate obligations, requirements, and responsibilities. That leads to vehement disagreements.

I agree 100%.


You are correct in general. I'll just add the nuance that when an open-source project gets beyond a certain popularity and usage threshold I'd expect the project's governance to take a stance that's more responsive to PRs.

That doesn't include any money incentives and that is likely the problem here.

Maybe `actix-web`'s author should apply for GitHub sponsorship. Maybe small sums of money every month will motivate him to take PRs more seriously.


This is quite an unusual topic but I find myself in agreement. But that's mostly because I don't agree with the general expectation that everything has to be a 'community', that the maintainer now has stewardship over. And the community is almost impossible to please as it grows larger and makes greater demands.

At one point it would have been code that anyone was free to use, before it becomes distorted as some bizarre social endeavour, and then people who've never used the software find themselves part of this 'community' and start to weigh in to add social pressure.

Use the software or don't; if the patches are rejected, fork it and go that way. If the maintainer won't merge the patches, because he has his own vision, you are perfectly welcome to branch out and follow your own. Or just use something else.

Having a maintainer adhere to a set of standards that only start to apply once 'the community' get involved and take control, is super unfair to the maintainer.


if a maintainer is a jerk to their contributors, that is of course their right, but...they are being childish.


Seriously, you can just fork the source repo and do what ever you want with them, and pull from your repo.


It's his project. If he wants to act in a way you call "childish" - not that I agree with the characterization - neither I, you, or anyone else has much of anything to complain about.

If he says it's production ready, I have to assume he thinks it is. If you don't think so, you don't use it.

Open source projects dependent on a single person goes away all the time. If you aren't prepared to maintain it yourself for your use, don't use it.

Honesty is something we should expect, as well as some amount of mutual respect.

It's abundantly clear that anyone expecting him to dance to their tune was clearly lacking in respect. If you do a patch that isn't accepted you haven't lost anything, and have no grounds to complain, unless possibly if you had a prior agreement between you about you making that particular patch.

Many maintainers are absolutely inhumanly awesome, but that doesn't give us the right to expect anything at all from those who is "only" giving us tons of more or less awesome code!


You cannot change other people, you can only change how _you_ react to other people and the world around you.

If Actix is that important to so many people, eventually there will be a person and/or organization that will step up, fork the projects, apply the patches, set the principles and code of conduct (or not), keep as much "unsafe" code as they deem necessary and try to rally the community around it.

The open source creators and maintainers gave you something and asked for nothing. They are people with their weaknesses, faults, insecurities, and other passions and commitments, like we all are. Get the best of what they are willing to give, give them the best you are willing to give and they are willing to accept, and move on.


Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?


Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep.

Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Readme.


It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time.

If you don't like the way a project is being run, fork it and own it yourself.

I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.


The PR contributor was not paid either to investigate the bug, reproduce it, write a patch and test it.

However instead of raising a "don't work, please fix" bug s/he took the time to do all that.

Anyone that went to such length deserve basic courtesy, whether the code is accepted or refused.

Refusing a patch because it is "boring" is not respecting the time people dedicated to your project.

I would understand refusing because the patch makes an unwanted compromise on performance and the maintainer considers performance regressions as bug.


These are merely your expectations, and this will probably disappoint you in the future.

I have replied to logged issues with the question: "I don't work on this, unless you have set aside a budget that pays my hourly rate".


And when maintainers respond to a significant amount of work involved in a PR for a bug with a note that they aren't interested because it's "boring" then they can be critiqued for being a jerk, because they decided to be a jerk.

If the maintainer had said, "Hey, I don't have the time to review/test/verify this PR so I'm closing it for now," the backlash probably wouldn't have been quite so severe.


I thought basic etiquette was issue to discuss before PR?

Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better".

Is that wrong?


I agree that should be the basic etiquette.

Perhaps it needs to be said more clearly on project pages and codes of conduct and participation.

(Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales. Luckily, if you don't get the response you wanted, you can fork and hire someone else or do it yourself, and keep your fixes in the queue for others to review eventually, if they want, at whatever timescale suits them.)

Unfortunately, there seem to be quite a lot of people who would, rather than discussing ideas respectfully, instead prefer to bully and shame the maintainer.

Such as, for example, calling out perceived issues in the code publically (sometimes incorrectly), and making out how unskilled the maintainer must be, in order to put pressure on the maintainer to sacrifice their personal life and do what the bully wants.


> Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales

I absolutely didn't mean to imply that. I also think that a pre-PR discussion can be useful because if the maintainer doesn't have time to say they want a PR that's a decent hint they won't have time to handle the PR.


Sorry if you thought I thought you were implying pressure. Not at all.

I thought your comment was helpful and supportive.

I just wanted to clarify, for readers, that expecting anything at any stage from a maintainer can be expecting too much sometimes. It is time and work for them after all, and usually it's in their limited personal time, for free.

Sometimes, they have already exhausted all the time they could put into the project; even a brief "thanks" email is too much when you have too many for whatever available time and energy you have. People don't always realise that, when they say "the maintainer should just [...]". A lot of people wanting [...] adds up.


> Sorry if you thought I thought you

No problem at all.

> I thought your comment was helpful and supportive.

Thank you. I'm glad you saw it that way.

> A lot of people wanting [...] adds up.

It sounds as though you've had some tough experiences with this. I'm sorry to hear that.


For what its worth I agree with you


I worked with a person who happens to have one of the most popular OSS Packages of my industry.

He has a kid and works 8hs a day like all of us... some merge requests are two years old, he doesn't have time for all the feedback / suggestions he receives and just keeps coding in his very limited time because is what he is passionate about... people keep using it.


This isn’t true at all. Many projects even say “we won’t accept PRs” in their README.

When the code is being used internally at Microsoft, it makes even more sense they wouldn’t take PRs.


There's been a request going for several years now to disable Pull Requests on GitHub[0]. They allow project maintainers to disable Issues, they should also be allowed to disable PRs rather than use automation to close any opened PR. Other SCM products (e.g. GitLab) offer the ability to make PRs available only to project members, or disable them completely.

[0] https://github.com/dear-github/dear-github/issues/84


Which is exactly what I suggested - avoid strife over mismatched expectations with a one liner. I would take your first paragraph to actually strengthen my assumption that Kinder treatment of PRs is the norm and that's why the many projects you mention add that line.


I'm not sure the practice is that common when the maintainer works for one of the largest 5 software companies in the world and that company is using the code.


Did the patches obviously maintain the exact same behavior? If so, why should the author care about them? If not, it’s not the author’s responsibility to ensure they’re correct patches, but it is the author’s responsibility to ensure their package is correct. If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well), they have no responsibility to vet incoming patches that do nothing besides change internal workings for the sake of changing internal workings.

I don’t write Rust, I write TS. If I produced a package that was had a clean and correct TS interface, but internally was filled with dirty dirty `any`s, I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.


> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.

Out of curiosity, isn't a focus on that kind of things precisely the goal of Rust? I understand your point, but this was software built for Rust, which has this kind of thing (safety, the right types, etc) as a primary goal.

From https://www.rust-lang.org/:

> "A language empowering everyone to build reliable and efficient software."

and

> "Why Rust? Reliability: Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — and enable you to eliminate many classes of bugs at compile-time."

So I can understand why someone bypassing this kind of things and then (for whatever, possibly understandable reasons) rejecting PRs to patch them because they are "boring" can be perceived as seriously mismatched with Rust's community. If someone finds this kind of thing "boring", is Rust really for them?

Note: I'm not saying he has any obligation to do anything. I'm just saying his attitude may seem mismatched with the community and goals of his chosen language, which is no small problem.


> If someone finds this kind of thing "boring", is Rust really for them?

Are you kidding? Rust is a tool, not an ideology. You don't have to share in the beliefs of the tools designers to use a tool...


Agreed on all counts: Rust is a tool and you don't have to agree with the tool designers. It's just bizarre to ignore precisely the aspect of the tool that singles it out, the reason it was created to begin with, the one thing this tool is very opinionated about.

You can also write all your Haskell programs with all functions with type IO. You can use a hammer to paint portraits.

Just expect eyebrows to be raised.


> is Rust really for them?

Maybe he likes rust because of other things. He had a very successful project with rust, it seems weird to think that rust was not the tool for him.


I don't disagree. But a tool can be successful in adoption and still not be correct from a technical point of view.

"Who cares about correctness or safety?" one could ask. Well, Rust's designers for one. It's why they created the language.


> If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well)

Oh my. This was not about code aesthetics or some purely philosophical problem. It was about experimentally found undefined behavior that opened potential security vulnerabilities in the wild. The ”well it works fine so it must be correct” mentality is exactly what led us to this situation where the vast majority of critical net infrastructure code is full of vulnerabilities, the very problem that Rust attempts to alleviate in the first place. The problem with the existence of malevolent actors is that it matters little if your program works correctly in all common cases. Someone out there is going to be actively looking for the uncommon case and their goals may not align with yours.


> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.

Why would you possibly not? Increased correctness, no change in runtime behavior, and a resistance to code rot and mistakes on your next concrete change.

Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.


> no change in runtime behavior

That's the problem: how does the maintainer guarantee this? And when flooded with multiple such PRs, the task rapidly becomes overwhelming. If you have a robust suite of unit tests and a CI system you have better guarantees but still about as much work to ensure the new functionality is properly tested. That's not to say the maintainer's attitude in this case was excusable, but it's his project and this style of maintenance is definitely not for the feint of heart.


In many cases, you're right. But here, specifically? If somebody goes through your code and annotates it with types, TypeScript is gonna scream if it doesn't build clean and is going to emit the same code it did in the first place. This is literally complaining that somebody might write helpful documentation for your system and that you'd refuse to merge it. It's a pathologically bad statement.


> Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.

It's a bit disingenuous that you can accuse someone of being absurd for not doing something, and then mentioning in the same breath that you "might not want to" as well.

I'm merely saying that for the sake of pointing out that maintaining a project is a PITA and we should all really accept that.


It's not disingenuous; I have a number of open source projects on my plate already. I probably can't take on more. But if somebody hands me, for one of my projects, a set of typings that compiles clean in TypeScript (and, seeing as how it's a compiler, that's a really trivial thing)? I'd be literally-not-figuratively out of my mind to not say "thank you" and take them. Failure for another maintainer to do so means that they are a business risk for me that I should not entertain.


> they had likely invested considerable time at least using, if not more.

I think your choice of the verb "invest" implies a highly flawed mindset about the incentive structure of open source.

A lot of open source consumers have a mindset that by using someone's open source project you're giving them something or doing them some kind of favor. "Hey, I'm investing in your project!" You aren't.

From a maintainer's perspective, simply using a project is likely either a zero or net negative. You are not investing your time, you are using their code. You may be asking questions which consume their time. You may be filing bugs which are on code paths they personally don't hit and fixing those uses up their time. For open source projects that pay for hosting things like their repo and issue tracker, you're consuming network resources.

We have a finite time on Earth, and supporting users is time the maintainer cannot spend with their friends and family, relaxing on a beach, taking a stroll, etc.

A consumer of an open source project may cancel out that drain by offering other things in return: popularity, kind words, the feeling that the maintainer has created something that benefits other humans. Filing issues can help a maintainer fix bugs and feel good about the improved quality of their code. Pull requests can add functionality they want.

But none of that is a given and often does not happen.

In my open source projects, I have certainly receive kind words, but also many angry words in bug reports. I've had demands to spend huge amounts of time making sweeping changes, pull requests that needed be basically be rewritten, the feeling that I'm letting people down by not replying to issues quickly enough, etc.

I believe the right mental model is that if you use someone's open source project, you are in their debt by default. They have used their labor to create an artifact that provides clear material value to you. They did work. You got personal value. They clearly owe you absolutely nothing and you reasonably owe them something approaching the material value you get from their code.

This doesn't mean you need to pay them, but it should inform how you interact with them. Filing issues and sending pull requests may pay off that debt, but even then it is not a given that every issue and PR is a net help to them. Maintaining an open source project can be gratifying, but it can also be hugely draining. It would be less so if consumers were more sensitive to that fact.


> 2. Open source participants are volunteers and owe you nothing.

The two rules work in concert.


> It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change anything in the slightest.

I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library. And regardless of how strongly you feel about 2), the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care". These statements aren't mutually exclusive


>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care"

Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in maintenance - these are the correct solutions.


> They were hateful and virtrolous

Who's they? Most of PR commenters were courteous. The last few were rude, but so was the fafhrd91. https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...


> Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?


This was posted after fafhrd91 was rude. Also...

> The last few were rude, but so was the fafhrd91


Cherry-picking a comment doesn't give a good representation of the community. The GP is right - most comments were courteous. The point is that saying "the community" was hateful and vitriolic needs more evidence than a couple of bad eggs, because those exist everywhere.


The parent comment still stands. Whether the maintainer was in the right or in the wrong, whether they were being a jerk or not, if he wasn’t listening to the community why not just fork the code? GitHub’s UI makes that super easy.


Just because it's easy to fork in the UI, doesn't mean it's easy to get people to switch. Some people are actually concerned about the community as a whole, rather than their own projects.


He explicitly made the repo private over handing it to someone else.

https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...


Counter: what about the tension and potential community split when a fork starts getting popular?

I was there (as a user who closely followed development) during the nodejs > io.js split. While it worked out in the end, it felt like a bitter battle at first. Node survived by chance perhaps.

We have our async-std vs Tokio right now, I'd imagine having another split (at least in opinions and preference) on actix would still keep tension high.


nodejs <=> io.js split was a great evolutionary step.

It allowed for the chaffs to fall through making node a stronger project because it was clear that neither of the sides was going to "win" outright.

If the argument is that "maintainer is not doing his/her job of being a maintainer" and this argument is accepted by the users, then should the project be forked by someone who will do his or her job of being a maintainer, the users will flip their source repo pointer and move onto the fork effectively killing the original.


The risk was worth it, node was stuck (in 0.12), and it was the whole thing, not "one of the things that you use to run JS on the server". A fork of actix wouldn't enjoy the same conditions that existed with Node.

Does the fork care as much about TechEmpkwer benchmarks? What happens if it is slower because it forbids unsafe even where it makes sense?

There was a looming cliff in Async/await, which caused a split to some extent (some old libraries that no longer have maintainers, changes that make updates difficult). A fork with those changes looming would mean divergence when rewriting to support Async/await.

Maybe I'm being too cautious, but I doubt we'd have had a successful fork earlier. Let's see if it happens now ...


You're lumping a few bad apples (apparently recruited from Reddit) in with "they". The users who found the bugs and provided patches were largely courteous considering the circumstances.


Steve Klabnik makes this point in his write-up, but I'm restating it here for clarity. You don't get to cherrypick who is part of your community or not when these situations arise.

Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour.

Good thing that those who submitted the patches and PRs were polite; they're not the ones who caused this maintainer to quit though I'd wager...


Should a politician be held responsible for every unhinged, vitriolic tweet by one of their supporters?


Maybe not the politician, but the general group of “supporters of politician X” should be.


I wholly agree with your viewpoint in this comment.

There is a prominent "Fork" and "Clone" button in every GitHub repo. If you're so fucking sick of the lack of support from the maintainer, fork it, fix the flaws that you've found, and assume some of the responsibility for the project.

This whole situation is a bunch of people getting angry because of what they view as a lack of accountability. That's preposterous - the nature of GitHub and open source makes it super easy for you to assume some of that accountability yourself. The fact that so many people chose to get upset rather than assuming accountability speaks volumes to me.

Pull requests welcome, jerks. </s>


As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.


> As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.

Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security.

Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.


> Sure, but that DOES NOT mean you're immune to criticism

The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.

You can criticize open source maintenance by creating a fork in which you outline your vision (e.g. "much less use of 'unsafe' in the web package") - and deal with the burden of being a maintainer.

Everything else is just trying to force people to do stuff for you, and that's rude.


FWIW, I don't have a dog in this fight. On the one hand, there is the maintainer who is within his rights to accept or reject patches as he wishes (although it's not great that he's allegedly falsely advertising his project as secure) and you have critics who are within their right to criticize (although it's not great that much criticism is vitriolic, etc). As TFA says, it's a sad affair all around.

> The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.

Of course it implies that the maintainer should change. All criticism implies an expectation of change, at least when the opportunity to change is still available.

> Everything else is just trying to force people to do stuff for you, and that's rude.

Criticism isn't "force" or "attempted force". This is just criticism. If you think criticism is rude, that's fine. Hypocritical, but fine.

You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.


> Criticism isn't "force" or "attempted force". If you think criticism is rude, that's fine. Hypocritical, but fine.

No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.

Hiding that behind "I'm just criticizing" (you didn't, but it's a popular refrain in such "debates") is more than only rude, it's also cowardice.

> You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.

The author of the package didn't force their code onto the users.

The authors of the criticism forced their criticism on him by throwing it his way in the form of bug reports etc. even when it was clear that there's no interest in it.


> No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.

Unless the critics are engaging in threats, intimidation, and/or violence, we're talking about criticism and not force.

> Criticism isn't "force" or "attempted force". If you think criticism is rude, that's fine. Hypocritical, but fine.

No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.

> The author of the package didn't force their code onto the users.

No one is arguing this. Weird straw man.

> The authors of the criticism forced their criticism on him by throwing it his way in the form of bug reports etc. even when it was clear that there's no interest in it.

Wow. I really didn't anticipate the "bug reports == force" equivalence.


I don't know that I agree with the parent post equivalence of "bug reports == force" but I think there is a point to be made that this wasn't just people speaking poorly or offering criticism. There is a real difference between posting your criticism on a platform you control and filling up the issue tracker used by the project. There is an aspect of coercion in that the maintainer has to choose between expending effort to combat the flood of unwanted issues or abandon the use of the issue tracker. They can't just decide to ignore the criticism.

Re. "The author of the package didn't force their code onto the users," it's not really a straw man. People are arguing that the author has moral responsibility for their use of his code. That ignores the fact that they actively chose to use his code. The only way the author would be morally responsible for their use of his code is if he had forced them to use it somehow. So yes, people are basically arguing this.


> Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.

No, if you pay for things, you have a contract and things are immediately different.


No, I am allowed to criticize a corporation which is obviously acting against public good.

Even if I'm not paying them anything.


So basically, if you use open source code in your code, you should expect there to be security vulnerabilities which people know about and are keeping quiet about because it'd be unfair to the unpaid creator to criticise them? Tbat sure makes it sound like it's morally irresponsible to use open-source rather than purchased commercial code in something like a web-facing service in 2020, especially given what we know now about the damage compromises can do and the resulting legal climate.


You can report on security vulnerabilities in a library without being vitriolic.

Find vulnerability. Already, awesome of you to have done. Issue patch request. That's 10x even better, you're a boon to the community. You submit it, it gets rejected, you find out why and it's the maintainer is just not feeling it or some other irrational reason. Fork, put in the readme why you forked, write a blog post without being a dick about it, done.

The article we're talking about is referring to the bloodbath of a Reddit pile-on. That's totally unacceptable behavior from an adult.


Please don't twist my words. I never said you have to keep quiet or that you're not allowed to criticize. If you see that a project has serious issues, feel free to write a blog post about it. Maybe offer to help, but don't demand your help being accepted.


> if you use open source code in your code, you should expect there to be security vulnerabilities

You should be able.to fix them yourself

That's the premise of OSS

if you don't want to pay for a cab or a driver, you should be able to drive


You can fix them yourself, by duplicating the car and fixing it yourself. You can't force someone else to fix the locks on their car


The only guarantee OSS gives is

- full access to the source code

- full rights to modify it and use it as it was your own

There's no other guarantee.

So if someone writes some code that becomes highly popular, they have no obligation whatsoever to maintain it the way people want.

They don't even have to maintain it at all, if they don't want to!

It's out in the public, it's free, that's the end of the agreement on the creato's side.

If a writer gave away their writings for free, could people pretend that they write what people want them to write, the way they want?

Is it fair to judge the writer because the answer was "WONTFIX"?

But the reality is worse than that.

A lot of companies are literally making billions using OSS, but they are not paying for it, a lot of programmers are making a lot of money by assembling OSS for their clients, but they are not paying for it, hell most of them are not even contributing in _any_ way, what does entitle them to pretend the attention of the OSS maintainer or that the maintainer should act in a way or another, according to the "community" desires?


Yes. I would expect there to be vulns and inconsistent patching for all OSS that I depend on and where I don't have a professional contract with its maintainers.


>Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security.

But our society does not just openly accept giving criticism. There are rules. Unwritten and extremely vague ones, no doubt, but still social rules. This is especially so when criticizing something a person is providing for free. In this incident, did the criticism cross the boundary and violate those rules? It seems so. Many people likely gave respectful criticism that followed the rules but they appear to have been drowned out by those who did not.


Security isn't a special license for being nasty. Criticism is fine, even with some urgency due to security being important.

But software done for free by volunteers carries no obligation of a legal or even a moral kind, whatsoever. This is completely different from selling software or doing work for hire or donations. There a moral and often even legal obligation exists.


The problem here was not that there was criticism, it's the TYPE of criticism (anger, hate etc).

And you know what's a good form of criticism? An issue with an attached PR


no your argument isn't useful. the question is never about rights because we all know what the maintainer's rights are (so it's always a discussion of obligation).

if you accept that the open source projects are voluntary as an axiom then you in fact cannot criticize choices made by the volunteer.

here's an analogy: a homeless person asks for money. you don't give him money but buy him food. can the homeless person rightfully criticize you?


Here's another analogy:

A homeless person asks for money. You don't give him money but give him some advice. Can the homeless person rightfully criticize you?

You can absolutely criticize choices made by volunteers. I don't think you need to think too deeply about this to imagine situations where few would object to criticizing a volunteer's behavior. An obvious one would be if an open source maintainer willfully included malware/etc. into their project - which, to many people, ignoring glaring security issues is vaguely equivalent.

I obviously don't think vitriol is warranted ever, but criticism obviously is from time-to-time.


what is the relationship of your analogy to this situation? is the maintainer the homeless person in your analogy?

you can criticize all you want as an exercise of your critical thinking faculties but the volunteer is not in anyway obligated to heed the criticism.

"it's my money/time and I'll spend it how I want, which includes burning it"

is the fundamental axiom. Given that that is the foundation what sense would it make to criticize that person for burning the money - it's right there in the premise that they're allowed to!


> what is the relationship of your analogy to this situation? is the maintainer the homeless person in your analogy?

It's your analogy, you tell me.

> you can criticize all you want as an exercise of your critical thinking faculties but the volunteer is not in anyway obligated to heed the criticism.

Nobody said they were. Nobody's trying to punish the maintainer legally. That doesn't mean criticism won't be offered or warranted.

Here's another analogy: You have a right to be a jerk in real life. Nobody's going to physically or legally stop you, barring extreme circumstances. People will still criticize you for being a jerk, as is THEIR right.


in my analogy you're the homeless person and the maintainer is the charitable person. in your analogy the homeless person is getting advice from ...?

>People will still criticize you for being a jerk, as is THEIR right.

completely specious. code in a github repo is not active participation in society. the fact that it's public does not mean it's been submitted for evaluation in any way. criticizing a thing that wasn't critically submitted is meaningless. it's like calling my practice sketches inferior to commissioned pieces - no shit that's the point!


> in my analogy you're the homeless person and the maintainer is the charitable person. in your analogy the homeless person is getting advice from ...?

the maintainer?

> completely specious. code in a github repo is not active participation in society. the fact that it's public does not mean it's been submitted for evaluation in any way. criticizing a think that wasn't critically submitted is meaningless. it's like calling my practice sketches inferior to commissioned pieces - no shit that's the point!

Uh, what? By packaging something as a crate, by listing it on crates.io, you're submitting it to be used. If you don't want it to be used or evaluated, at all, why in the world would you publish something as a crate on a public registry?

This is more like submitting your sketches to a public art gallery and then being upset when the public criticizes it.


>This is more like submitting your sketches to a public art gallery and then being upset when the public criticizes it.

that's not what happened. there weren't simply discussions of the viability or soundness or the crate. there were implicit/explicit demands for changes. so your analogy is wrong again - it would be like submitting public sketches and then facing demands that the sketches be improved. does that sound like something that i as the artist should be comfortable with? more importantly does that sound like something a reasonable person would do (make demands for alterations to sketches submitted to a public art gallery)?


what are you talking about? The code was submitted to be used by the public as a crate on a public registry. There were ABSOLUTELY discussions of the soundness of the crate - that’s literally what sparked this issue, security flaws in the crate.

Are you sure you have a firm grasp on what actually transpired here?


Please edit personal swipes out of your comments here. It evokes flamewar from others, which is what we got in this case.

https://news.ycombinator.com/newsguidelines.html


Fair enough. My apologies.


[flagged]


And people are allowed to criticize his reluctance to accept those vital security patches, because he submitted code packaged as a crate to be used by others on a public registry.

By publishing something to be used by others in a public registry, you are opting in to receive criticism from the public.

Criticism is not the same thing as vitriol and I’m not endorsing the latter even one iota.

Is that not crystal clear to you?


[flagged]


You've broken the site guidelines egregiously in this thread. Since you also have a long history of breaking the HN guidelines, we'd normally ban an account for this, but it has been posting pretty well in recent history, so I won't ban it this time.

Please review https://news.ycombinator.com/newsguidelines.html though, and stick to the rules from now on.

https://news.ycombinator.com/newsguidelines.html


you know what would be useful mr. arbiter-of-what's-appropriate? if you would point out exactly what you believe i've done that is "egregious" instead of just vaguely alluding to the guidelines page and leave it up to interpretation/divination/mind-reading. as far as i can tell i've engaged in a good faith discussion/debate and it was solely this other person that shouted/antagonized. the only informal (could be perceived as antagonistic) thing i did was remark on how that person was moving goal posts after i clarified and produced reasoning for my position and how i'm glad that one valuable thing that came out of the exchange was i learned to avoid them in the future. as far as i can tell in the comment chain, it was the other person's that got flagged first and was the source of the tension.

there's something so aggravating about how you preside (note i didn't call it moderation) over these forums. what is the point of a voting system if you can unilaterally censor and censure? you know what the pretense to "objective" and "rational" discourse of this forum does? it inspires the kind of arrogance you see here on so many posts - absolutist positions on everything from tech to healthcare to history. the brand of yc and you and the rhetoric of the guidelines and you all function as an aegis.


For starters, "man i'm glad there are identifying details about you in your profile so i can avoid working with you" is an egregious personal attack, certainly something we'd ban accounts for, especially when they have a history of breaking the site guidelines.

> what is the point of a voting system if you can unilaterally censor and censure?

HN is a constitutional democracy. I can see why you'd find it annoying if you're assuming otherwise. We can't go by upvotes alone—if comments break the site guidelines, it doesn't matter how upvoted they are.

The voting system alone doesn't regulate itself—it leads to flamewars because indignant and unsubstantive comments frequently get upvoted. That's why there need to be countervailing mechanisms like flagging and moderation.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...


i would love for you precisely identify what part of

>man i'm glad there are identifying details about you in your profile so i can avoid working with you

is an attack. it's an expression of my personal exasperation. there's literally not a single ascription of any qualities to the other person. you can ctrl+f "you" or "your" in this subtree

https://news.ycombinator.com/item?id=22075698

and i in no place ascribe any qualities to anyone. my only other remark was pointing out the other person's belligerence which i still didn't make personal.

so either you can claim that there's something like a "zero tolerance" policy for antagonism or you can retract what you've accused me of.

this is my overarching point and has been for years on hn: it's evil to paint with a broad brush people that are actually antagonistic and those that don't feel they should toe the line in response to those people. your constitutional moderation is this brush.


> i would love for you precisely identify what part [...] is an attack.

It's basically the same as saying "I hate you". You hate them so much that you will go to great lengths to never work with them.

Maybe it's true—maybe you really do hate them—but stating as much is absolutely a personal attack IMO.

> it's an expression of my personal exasperation.

"Comments should get more thoughtful and substantive, not less, as a topic gets more divisive."


Sounds good.


I reject the axiom. No one is above criticism provided the criticism is rooted in fact (i.e., defamation is not criticism).


it's not about whether someone is above criticism - it's about whether criticism makes sense in the context of what's being proffered. in another part of this branch of the thread i make the analogy with a an artist's sketch posted to a public art gallery. it's not that you can't criticize, it's that it doesn't make sense to criticize because the artist isn't attempting to achieve anything.

maybe a better analogy is if i play a pickup game of basketball and i get labeled a bad player for not trying my hardest. it's not that the criticism is misplaced it's that it doesn't make sense at all - i wasn't trying to be a good player! i was trying to have fun.


That’s not the issue at all, and we know this because the project was advertised as secure and the critics were arguing that it wasn’t advertised as such. This is characteristically different than your basketball analogy because it is neither explicit nor implicit that the project was unsuitable for production. Drew is arguing that the criticism is invalid because maintainers are within their rights to even lie about their projects because all responsibility lies downstream. Note that security DOES indeed lie downstream, but Drew is mistaken for arguing that this downstream responsibility immunizes maintainers from such criticism. This is a non sequitur.

I don’t understand the desire to make this out to be a sort of dichotomy—both groups have the right to do what they did (the maintainer to reject patches and even allegedly lie about the security properties of his project and the critics to criticize even in bad taste) and both parties could have handled it better. TFA did a fine job for implicitly acknowledging this by simply referring to the situation as sad all around.


>That’s not the issue at all, and we know this because the project was advertised as secure

this is so weird to me. i have a really difficult time on hn often because i don't understand why people that claim to be intelligent can't distill out the fundamental/primary issues.

it's a free/proffered/donation/voluntary/no strings attached piece of code. that is the first thing that defines its use/understanding/existence/ontology whatever other words. everything else is contingent upon that. you can debate this point - you can say something about the social contract of open source software and your responsibility to the community if you yourself have benefited from other open source projects and etc but no one is debating this. everyone is debating aposteriori things.

if i put a mattress out on the street with a sign "no bed bugs" and you pick it up and it has bed bugs in can you be mad at me? can you take action against me?

i don't know what kind of framework i need to appeal to in order to underscore this issue so that people address it directly instead of things further down the line. i would really appreciate someone showing me how to either do this (put the focus on the thing i'm engaging with) or tell me why i'm wrong for focusing on that.


> this is so weird to me. i have a really difficult time on hn often because i don't understand why people that claim to be intelligent can't distill out the fundamental/primary issues.

I feel the same way, but not about /u/weberc2's post.

> it's a free/proffered/donation/voluntary/no strings attached piece of code. that is the first thing that defines its use/understanding/existence/ontology whatever other words. everything else is contingent upon that.

This is another of your own axioms. These aren't universal. In particular, if a maintainer states or otherwise implies that his project is secure and suitable for production and then behaves otherwise, criticism is warranted. Even if he doesn't, criticism is still permissible.

> you can debate this point - you can say something about the social contract of open source software and your responsibility to the community if you yourself have benefited from other open source projects and etc but no one is debating this. everyone is debating aposteriori things.

No one is debating this because it's not necessary. The maintainer's explicit assertions about his project (its security, etc) override implicit "social contract" responsibilities.

> if i put a mattress out on the street with a sign "no bed bugs" and you pick it up and it has bed bugs in can you be mad at me? can you take action against me?

Not sure, but I can certainly criticize you.

> i don't know what kind of framework i need to appeal to in order to underscore this issue so that people address it directly instead of things further down the line. i would really appreciate someone showing me how to either do this (put the focus on the thing i'm engaging with) or tell me why i'm wrong for focusing on that.

In general your arguments are based on your own axioms. If your axioms aren't widely-shared, then you will run into these sorts of disagreements.


>This is another of your own axioms. These aren't universal.

how is this my axiom? it's on github. no one has paid for a license (the license is completely permissive).

>In particular, if a maintainer states or otherwise implies that his project is secure and suitable for production and then behaves otherwise, criticism is warranted.

is that part of the TOS of github? is that part of the bylaws of the guild of software engineers? is that in the bible? where is this codified except in this thread around this issue where everyone is mad?

>Not sure, but I can certainly criticize you.

you can do whatever you want. you can stand on your head and recite the star spangled banner. i'm posing the question whether it's reasonable. is it reasonable to criticize me for putting that mattress there in that state?

>In general your arguments are based on your own axioms

again they're not mine in the least - i did not coin the phrase "don't look a gift horse in the mouth". that is much older than me and fairly universally understood/accepted.


It's your axiom because others don't believe it being on github or free immunizes the maintainer from criticism. Licenses and GitHub ToS have no authority over who may or may not be criticized. You reason that it's not eligible for criticism because you hold the axiom that it is unreasonable to criticize open source projects. The "gift horse" phrase doesn't apply to situations where the "gift" is a liability; i.e., something that could leave you worse off than before--the Trojans would have done well to look their gift horse in the mouth, for example.


Criticizing someone for lying is generally accepted. Criticizing someone for an accidental mistake is often frowned upon.

The trouble is distinguishing the cases.


This has been the argument throughout the various discussions -- that somehow if there isn't a payment structure between party A and party B, there is full immunity from criticism, questioning, expectations, etc. It is absolutely insipid and is a logical non-starter that doesn't pass the most basic of considerations. Yet it keeps recurring. It's bizarre.


As a maintainer, I treat almost all PR submission with kind words.

What actix developer did was, to pardon my French, inexcusable. Deeming security patch boring? Making your own `Cell`, implementing it badly and misusing it, because it's faster on some stupid benchmark site?

If we designed cars like that, they would have no breaks, no gears and no cabin.

Honestly, I think it's better Rust abandons `actix` asap. Before it gets any real traction.


The same "stupid" benchmark site let to dramatical improved .NET Core performance , re-engineered the .NET Server stack and even changed the C# language on the way.

I do not know how the Rust community manages performance comparison, but the .NET bubble was broken by that page and resulted in awesome results for the platform.

PS: just pointing out what the page achieved somewhere else. The discussion about the maintainer and what happened there is a different topic.


That might be true for Dotnet.

But from what I heard, to get where it is, actix developer took some really bizzare shortcuts. E.g. hardcoding parts of response. On top of general unsafe usage.

I think the benchmarks are flawed, since they don't account for such "optimizations".


The benchmark is very smart in that sense. It has multiple stages (e.g. plaintext, db access,...). It proves with each stage deeper into your stack. You can disable there parts of your stack (e.g. middlewares, views, controllers, ...) and just operate on low level http request response pairs. And there you can hardcode on top then (as the application). The stages of the benchmark are optimized for testing individual disciplines like the connection and memory management of the low level http server and parser.

In .NET case they changed the language in response to the needs of the Techempower benchmark (and the Unity3d engine) to allow safe and performing ops. .NET also has the unsafe keyword for low level ops and is surely also used. The advantage of .NET is that it was a team with a central manager who pushed all areas, http framework, base class library and language into the same direction. A community like Rust does not have that privilege.


The "boring" was in response to the comment above it, which was discussing if the patch is large enough to merit a statement that they are contributing under the projects license.

The patch was "boring", not substantial to claim copyright.


It's not. It's boring because people want to fix unsafe. Read

https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...


Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure.

Adding to this, you might still transitively depend on the upstream through your other deps in ways you can’t change without either forking all your deps... or getting them to switch.

And what does “getting the ecosystem to switch” look like? It looks a lot like complaining about the upstream, such that others in the community understand what the problem is that your fork is solving.


The level of entitlement here is absolutely insane.

If the community cares about security then should this happen:

> Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure.

The community would move onto your secure fork and the author of said fork would become a maintainer. As Dave Rand, the CTO of AboveNet used to say to newcomers who used to say 'X should be done!' -- "Thank you for volunteering - you are now in charge of X."


Following Dave Rand's framework, the conversation went something like:

"Atrix-web should not use unsafe"

"Thank you for volunteering - you are now in charge of making atrix-web not using unsafe"

"Thank you for delegating responsibility of making atrix-web not use unsafe, to me. I accept responsibility for this piece, but you are still the leader of $PROJECT." <workworkwork> "Here is a PR that makes atrix-web less unsafe."

"I don't accept your PR."

Dave Rand's advice doesn't apply here, as several people picked up responsibility for making atrix-web less unsafe, put forth the work to do so, but were rejected. It's one thing for me as a user to feel entitled to everyone else doing what I think they should, while not putting in any effort, but IMO it's less clear cut when I'm putting my money when my mouth is, and submitting PRs.


None of the people made it safe because it is not in the code.

Fork it, make it "atrix-web-safe", post about it on whatever rust announcement list/forum/group is and have people move to the "atrix-web-safe". That's leadership. The rest is moan-fest.


> you want others to know of your fork

If you fork on GitHub, they take care of letting people know.

I've forked a few abandondedish projects, and other people seem to find the patches. The best example I can think of is stud, which the people behind Varnish adopted and renamed to hitch; they surveyed the landscape and took good patches from most of the forks.

I might not look for forks from a more active project, but it's definitely something I look for when I run into problems with software without a lot of recent updates.


If enough people support your idea you will get a new community around your fork.

Or you can pay the cost of bringing in changes from the upstream project. This happens a lot for commercial software. I remember having to maintain a “fork” of BEA’s WebLogic server for a year or two until they incorporated changes my employer needs.

It’s not so bad.


Or you could pay someone to do it

If you depend so much on that code, if the security of your software depends on someone else's free work, why don't you hire that person to fix the bugs?


That doesn't mean it's wrong to criticize his choices, so long as it's done without being insulting.


Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.


You are right that he didn't have to do any of the things people pointed out but that doesn't mean choosing not to do them isn't fair game for criticism and "he should have labeled it as a toy project" and "he should have given reasons why he didn't accept the patch" seem more like fair criticisms than making demands.


> "he should have labeled it as a toy project" and "he should have given reasons why he didn't accept the patch" seem more like fair criticisms than making demands.

Those are demands. The toy project one is relatively low cost, but "he should have given reasons" brings with its lots of effort to do right - and then you get to do it over and over again, because the masses can fling shit at you faster than you can reason about it.


demand: an insistent and peremptory request, made as if by right.

critcism: the expression of disapproval of someone or something based on perceived faults or mistakes.

"he should have ..." is clearly an expression of disapproval.


> he didn't have to do any of that

Of course he didn't, in the legal sense of the term. And then people didn't have to stop criticizing him, in the legal sense of the term.

And obviously for the ethical / moral point of view, people have vastly different opinions, otherwise there would not be this debate.


You can criticise but you are not allowed to COMPLAIN. That is my view.


You know, there is a lot of "He isn't required" but I will say there are reasonable expectations that people have when a project gets to a certain level of exposure/downloads/etc. and while someone should not be "cancelled" or tarred and feathered for not accepting a merge request, if your project is a leader in its niche (Rust web frameworks) you should do better.

You publish your code to Github, you're part of a community. You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.


> You publish your code to Github, you're part of a community.

Hell no. It that were the case, I'd never publish anything.

> You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.

It is YOUR responsibility to see that for yourself by watching how the project is actually maintained.


Both are true. I obviously can't trust that maintainers will do what they SHOULD do via common sense and online civility, so I SHOULD vet them appropriately.

Why do so many people insist on being aloof and unhelpful in communicating to users of their software? What is so hard about offering a modicum of context for what people can expect of you as a maintainer? It's so ideologically rigid and unreasonable.


> You publish your code to Github, you're part of a community.

Maybe. The main issue I see with github is that it's impossible to disable pull requests there. We have that issue in the coreboot project, which uses github as a read-only mirror.

Maybe we should just shut that down to make clear that coreboot is not part of the "GitHub community".


I urge you (or anyone else who feels similarly) to seek a full refund for what you paid for the maintenance of that piece of software.


I urge you to stop thinking about how aloof and unhelpful you are permitted to be, and consider how minimally helpful you could be in communicating to users of your projects.


Ah! Imagine the joy of the maintainers! They are "permitted" to not support software for free.


Correct.


Seems like the premise of Klabnik's article is that it was not done without being insulting.


It's also the choice of anyone else to criticize him for not accepting security patches.


The community's response might be valid if it were limited to that. But, quoting TFA, they went beyond that.

"It’s extra nasty this time. Some people go far, far, far over the line."

When someone polite says this, I picture some of the nastier attacks on the internet - doxxing, death threats, and swatting.


In this case it meant people saying things like "you are bad and you should stop writing rust, forever" possibly with some more colorful words in there. Very hurtful things but at least not threats and actions...


If someone poorly implements something, potential causes harm in doing so, doesn't accept that they have done so poorly and express a desire to learn and improve in future endeavors, it isn't even necessarily incorrect to express that they may not want to pursue that particular field anymore. Of course it should be done tactfully which I doubt most of the comments on Reddit did. I see this same sentiment expressed fairly often on HN in usually but not always more polite terms.


In what way is it correct or even helpful? Even if done tactfully, I have a hard time seeing that being taken by anyone as anything other than a personal attack.

The correct response would be to organize the community to create a fork that is more focused on correctness and security than on performance.


It is correct and helpful because it can prevent continued poor behavior which impacts others. Trying to protect someone's feelings only goes so far. Sometimes you have to be straight and to the point with people whether they take it as a personal attack and it hurts their feelings or not.

Whether it would be appropriate in this I case I don't know but I disagree that it is never the correct response.


> it can prevent continued poor behavior which impacts others

I highly doubt that it would do anything to prevent that continued behavior. I cannot imagine a situation in which there is not a better and more appropriate solution to mitigating poor behavior that telling people "don't participate in this field". At best you will alienate them in such a manner that alternative approaches are less feasible and at worst you convert bad behavior from being passively to actively malicious. I'd be curious if you have a concrete example for when you think this approach has been beneficial in any context.

Note, I consider revoking credentials (e.g. disbarring an attorney or revoking a medical/engineering license) to be something entirely different as there is an active endorsement that needs to be terminated. Relevancy in this case would be to removing a package from a package/dependency listing service/manager.


This is just your opinion, and not a fact or some kind of social rule. In fact, I would say that using your logic, I can say that you should never ever express your opinion on such matters again, since you clearly don't know what you are talking about. Just giving it to you straight. My opinion is fact. Respect it! Do you see the irony?


> it isn't even necessarily incorrect to express that they may not want to pursue that particular field anymore

Can I express that to people who think a volunteer project owes them anything & couldn't be arsed to implement the project's functionality themselves in the first place? Somehow I don't think that would be a constructive use f time.


Rust is a programming language. Nothing more, nothing less. It is a tool. If I like the typing and macro systems used by Rust, but I do not care in the slightest about “memory safety” I can write my dirty, filthy ‘unsafe’ C style code with casts, and raw pointers, and multiple mutable references in a giant unsafe block and get a compiled binary out of rustc. And if I use the above style of coding to write a neat CLI tool and offer the code as open source on Github, so be it. What the purported ‘Rust community’ thinks the language professes doesn’t mean a thing. Use the tool or don’t.

I don’t want to come as negative toward Rust or developers using it, but there is a whole lot of using Rust’s ‘security’ focus/features to say the Actix developer needed to do things a certain way. He wrote he, he could do whatever the hell he wanted.


> Open source participants are volunteers and owe you nothing.

I can't agree. Not for all participants.

Let's take Linus. He's in charge of the Linux project, which thousands (millions?) of people contribute to every day. If Linus suddenly stopped merging any and all patches—but refused to officially step down—what do you think would happen? Oh, the project would more than survive—someone would fork it and that would become the de-facto new mainline kernel—but there'd probably be a couple weeks of chaos. Does Linus bear zero responsibility because he's a volunteer?

---

Every Saturday, I volunteer as an assistant teacher (they call us "facilitators") at a Girls Who Code club, a free weekly class to teach computer science to young girls. I don't get paid for it, but that's okay—the kids are adorable and teaching them is fun. The primary teacher is also a volunteer.

If we both decided to just not show up one week, and parents brought their children to the library and found an empty room, would that be okay?

Personally, I do think I owe something to those students, and to the primary teacher. I've made a commitment to show up every week and do what I can to help a group of children. My commitment is what matters, not whether it generates income.

Now, there's actually second GWC class for slightly older students which starts right after the first one. Sometimes I help teach that one, and sometimes I go home. I told the primary teacher I'll stay "when I can", which actually means "when I feel like it".

There's certainly a place for doing work without a commitment to continue, but your intentions need to be clear. Most large projects are not going to function without a commitment from someone somewhere in the chain.

One weekend in October, the primary teacher had plans to go traveling in Europe. She asked if I could cover both classes that week. I said I would, and I did.


"Owe" is a very strong word and can quickly get people into trouble once you start trying to break down human interactions into transactions where certain things are owed. Part of this is because to owe something is to indicate some level of force to cause a person to comply. It touches on topics of forcing a person against their will. I'm not saying that it is wrong, but that it makes people extremely uncomfortable and can even lead to people attacking your character for trying to do such a breakdown.

I think what we are running into here is a matter where different groups have different expectations of what is owed and why it is owed, but due to the difficulty of talking about what is owed to others makes it hard for us to verbalize or sometimes even concretely conceptualize what we are talking about. There are also different extents one can owe something (legal being the most extreme, as you will be forced to by the courts with possible violence if you don't).

If a one of the parents tried to get a court to order you to teach the class on penalty of contempt of course, would you find that reasonable? This sounds quite extreme, but there are plenty of cases of owing someone something that the court does enforce in a similar manner. My guess is that you would find such an reaction unreasonable to an outrageous degree, but would find far less extreme enforcement measures (such as being disappointed) as being reasonable. I would even go a bit off topic and say that this level of being owed is proportional to the payment you receive. As a volunteer you likely get no money, but are still 'paid' in social recognition.

So you can owe something on the level of being disappointed, but not on the level of court order. So what level does a project maintainer owe others and why. And what do those others owe them in return?


Linus is paid to carry that responsibility. Others are not.


This is factually correct statement while apparently downvoted. Linus Torwards is paid for his effort. Which is also actually right state of things, not an insult.


True, but for the reasons I detailed above, it's not the payment that matters. Linus could also probably make more money on a different project, but he's committed to Linux.


> but there'd probably be a couple weeks of chaos. Does Linus bear zero responsibility because he's a volunteer

Linux Foundation would appoint somebody else on his place and have him sign similar contract. It would be likely a person that is already employed in similar capacity - one of current paid maintainers. No fork would be needed. Linus Torwalds is not a volunteer at this point.

Linus Torwalds will leave linux one day. He wont stay there forever - most likely to retire, but possibly to do something else.

Also, Linux is particularly bad example, because most contributors are paid for their effort by someone.


It is a bad example but most major open source projects are in that regard. However, the community driven ecosystems (Rust, Go, JavaScript ..) have significant components in that particular unpaid maintainer situation. And that is a problem.


Go is done and maintained by google employees. JavaScript specification has syndicate behind it. Rust has clear governance, through I cant find who pays for it all.

Any big enough project will formalize relationships at one point or another - latest when they need to raise money or organize conference. These projects are too big to be run over the weekend, they do have to pay regular staff.


I think there's a huge distinction you're missing here. As a volunteer teacher or facilitator, you've made a personal commitment to a group of individual people. I think there's a difference between that and sharing code with the faceless hordes of the internet. Personal interactions differ strongly online vs in person. It would be quite unusual for a large group of people to start screaming at you in person but this happens commonly on web forums etc., as was described in TFA.

If Linus is truly a volunteer, then he owes me and the rest of us nothing beyond what he's done already. I haven't sent him any money and have no relationship or agreement with him; he owes me nothing. The chaos will resolve itself and the world will go on.

In this case there's nothing to prevent someone else from forming the code and moving forward with it, until they also tire of the abuse this poor fellow experienced.


I thought I was going crazy when nobody seemed to express this point of view. These are exactly my feelings about this. Perhaps maintainers get the brunt of entitlement and lack of appreciation, and don't have any interest after all that in stepping back and seeing it from this perspective. I think that there may be a disconnect in understanding of words such as "owe", "expect", etc.

I think that we could use some norms around this. Perhaps there could be an EXPECTATIONS.md in each project where we lay out exactly what to expect from the author, if anything. Maybe even specify a monetary incentive to take things further. And then the rest of us know exactly what to ask for if things aren't up to expectations. But no matter what, make sure to show appreciation to everybody who does what they do as a volunteer.


I partially agree. I _do_ actually think that you have a certain obligations to your users.

For Rust, my personal mantra was always that _usage is contribution_. Why? Because we have a high interest in adoption. It's literally one of our top-priority goals.

But not everyone taking part in these discussions is a user or someone I have some kind of relationship with. And a relationship goes both ways.

To take your example: if a kid showed up and was _constantly_ loud, didn't respect you or showed no interest in learning? What if _most_ of the kids were like this?

Would you still like to go every Saturday?

I do teach in similar settings (RailsGirls, RustBrige) and a crucial part of the experience for me is that many attendees have a progress that they are thankful for. The deal and the relationship works, even if it is just short.

My big frustration is that the debate is often "Maintainer vs. Users", but I don't believe that boundary is as hard as people make it to be. Still, user entitlement exists and is _very_ rampant and this is what people are up against, even if they put it less nuanced. (maintainer entitlement also exists, but that's a story for another day)


I think you're missing a point. If you promise something, people will get upset if you don't deliver. There were no promises made here. If you want to compare it to your example, it's more like your "primary teacher" would ask you to cover one week after other and after 3 years you'd say you just won't do it anymore - should anybody be upset at you?


I don't know enough about the specifics of this situation. My point is, I don't agree with the idea that volunteers inherently owe nothing.

And to focus on a different part of the analogy for a moment—if somebody looks more closely at what I'm teaching students, and sees that I'm actually showing them how to use flamethrowers, yeah, they have a right to be upset. Again, it doesn't matter that I'm a volunteer, they've placed a significant degree of trust in me.

People should still audit their dependencies, just like people should observe my teaching. But it's also fair for them to have expectations.


He's the author, not a voluneer. He didn't promise/volunteer to do anything.


As someone who works for a dod contractor this whole situation sounds crazy. Just because something is available as a crate doesnt mean you are to assume it safe or appropriate for your use. The onus of verifying the dependencies should always be on the consumer.


Haha - also a dod contractor, and sometimes wonder whether I'm the insane one who can't handle the wild west behavior of HN people surrounding npm packages...


I have some side projects that use react and I dont mind cuz they are small time and react is fun, but seeing that list of dependencies scroll on the terminal makes me extremely uneasy everytime.


No, you guys aren’t the only ones. Not currently a defense contractor but was one in a previous life. Whenever I read articles and comments here on HN about dependency management I break out into sweats. It’s shocking how cavalier people are about pulling in third party dependencies, and this dismissive attitude about risk management: what exactly it is that the dependencies do, how suitable they really are for the project, what happens if they become not suitable (contingency plans), how auditable and traceable changes are, etc.

It’s just “npm install” and YOLO for a lot of developers!


Its not just you.


That's what they were doing. They vetted it, provided patches and examples of triggering UB, and the maintainer called it "boring".


> 1. YOU are responsible for your dependencies.

This is an understatement.

I work in regulated environments where a software error has consequences. Dependencies must be vetted. If we end up relying on a dependency with known vulnerabilities the auditors are going to want to know what we did to mitigate the risk of this out-come. You need to have an answer for that question.

I recommend packaging your upstream dependencies. That way you can patch vulnerabilities you find and ship those fixes today before those patches make it up stream. That's a risk mitigation strategy and often good enough to fend off auditors.

Many (all?) open source licenses provide the software without any warranty or guarantee of merchantability or fitness for use. None. At all.


My viewpoint is as follows:

1. Just because a thing exists, does not give you the absolute moral right to criticize it, especially in a way that is toxic for the person or persons that created it.

Criticism affects both the people criticized and the community/universe at large, and not always in positive, productive ways.

2. Just because a thing is free, does not grant the thing or its creator absolute immunity from criticism.

Things that exist have an impact on communities or the universe in general, and people are going to be affected. And not always in positive, productive ways.

1 and 2 can both be true, and I think they are both true.

There is a judgment call involved as to when criticism is unfounded, unproductive, a distraction, and/or outright toxic, just as there is a judgement call involved as to when a thing’s existence in its current form is a net negative.

You are not wrong about user entitlement being a problem, as noted by #1, and you are not wrong in a commercial sense about maintainers not owing any one person anything.

But as per #2, I do not believe that is an absolute blanket injunction to never have an opinion about their choices or about the net positive or negative effect of the existence of the thing they maintain in its current form.


#1 is imprecise to me in one respect.

Critiquing someone's actions and choices is a founding principle of open source software, politics, and in general most human culture. "I think it was wrong to delete the GitHub issue because my belief structure XYZ" is acceptable.

Critiquing someone personally based on their technical choices is not acceptable. Reddit allows it, and thus Reddit is unusable as a social platform for positive outcomes. "I think you are a bad person because you deleted a GitHub issue" is NOT OKAY.

That distinction appears to be what led the creator to quit today, because the GitHub issue they deleted (perhaps incorrectly) contained personal attacks that linked their technical choices to their quality of human self (definitely incorrectly). I personally would have chosen to XYZ and I think they'll do so in the future if that comes up in a GitHub issue again — but focusing on that is incorrect here.

The focus needs to be on those who wield personal attacks on others over technical choices, and on rewriting communities to prohibit and evict these participants in all cases where such can be done. Shun them, ban them, and prohibit them.


I agree with your point. Personal criticism should be extremely rare, and very carefully handled. A thread in a public forum is almost never the right place for it.

Here is an entire essay touching on the subject:

https://github.com/raganwald-deprecated/homoiconic/blob/mast...

And the HN discussion at the time:

https://news.ycombinator.com/item?id=589200


Exactly this.

If it doesn't meet your standards, don't use it.

Alternatively, go fork yourself.


Personally I plan to vendor all dependencies.

It would be nice to have cargo/rustc support 'allow_unsafe' per module and also for dependencies, so you know you have to review a dependency really well.


>If it doesn't meet your standards, don't use it.

>Alternatively, go fork yourself.

I think this could be the new template for Open Source Author to include in their OS work description should they choose to.


This is my new CONTRIBUTING.md file for personal projects. Thanks!


But then you get drama about Not-Invented-Here, why are you creating yet-another-X-framework instead of improving the existing ones.

Or you get drama like ffmpeg vs libav/avconv.


Indeed. Many times, making a real effort and doing something has a real cost and risk associated with it. This is unlike demanding that someone else offer services which solve one's problem(s) while not offering any payment for it. The latter approach has minimal cost: it only harms one's dignity.


The only time ever on earth where a homophone actually has been done well. Thank you.


> 1. YOU are responsible for your dependencies.

This is a nice idea, but in an era of one-button package managers it just doesn't work like that. You're trying to fight against New Jersey style. Which in the entire history of software has never been a winning approach.

The reality is that for 95%+ of active software developers, done is better than perfect. Yes there may be a small subset of developers working on super-critical defense systems or nuclear reactors. Who have the time, resources, know-how and organizational support to meticulously and carefully audit all of their dependencies.

But the vast majority of developers are not in these types of environment. The mantra of the entire tech industry is "move fast and break things". Try being a Silicon Valley startup engineer and trying to justify to your manager that you could standup functionality with one call to "npm install", but that's not sanitary and you need to audit the entire dependency tree. Now assume that the next round of VC funding for your cash-strapped startup is on the line. How well do you think that concern will go over?

The reality is that if something can be instantly installed in 30 seconds, then it will be. We can give as many "caveat emptors" as possible, but convenience trumps safety every single time.

The way to solve this is to enforce consistency on an ecosystem level. The best example of this is the Debian project. There's very firm guidelines about QA and safety before a package is allowed into stable. The Debian people are probably right about another thing too: language-level package managers should be considered harmful.

Many of these problems could be avoided if we strictly used apt-get instead of pip, crate, and npm. For one distro maintainers tend to have a lot more experience and competence at evaluating stability and safety. Two, since a system only has one distro package manager, but potentially many runtime environments, it prevents a race to the bottom. Harried developers will just gravitate towards the least strict runtime with the most low-quality packages.

This lesson is probably very tough for the Rust community to swallow. Crate is considered one of, if not the most, compelling features of Rust. If we acknowledge that it was a mistake, it really undercuts the argument for adopting Rust.


Very well stated. I'm jealous of your ability to articulate your point.

The underlying contradiction seems to be a theme in software development. People who haphazardly slap together inefficient and buggy software assume the safety-critical software I've worked on must be engineered to an impossibly high standard in formally-proven Ada. We don't use Ada or formal proofs, for the same reasons nobody else does. I can say we are a lot more careful than 99+% of other projects, but we still live in the same software ecosystem everyone else does. I can't audit every platform and library we use with a fine tooth comb. A few million dollars will buy you a lot of reviews and testing (internal/external/penetration testing), but it will never be the platonic ideal of well-written software.

And Debian is a funny example for you to bring up. It's hard to take the temperature of a crowd online, but the HN attitude towards Debian's slow-and-careful releases in any other type of thread is that they're old fogies that don't understand the needs of modern software. I don't think even Debian lives up to this thread's level of code scrutiny that everyone should be doing all the time.


It sure does work like that.

Our package managers have in-house mirrors, only validated dependencies by legal are allowed on those mirrors.

Installing in 30 seconds is not allowed by design.


> It was never Nikolay's job to vet actix-web for you

Imagine if the linux maintainers took this attitude.

This attitude severely undermines the credibility of opensource.

If users of opensource libraries can't have confidence that those libraries are written correctly, we might as well all go back to commercial software.


What would be the basis for confidence that those commercial libraries are written correctly since you can't audit the source code?


They do. It is right there, in the LICENSE file.

It is a simple cost/benefit analysis. Your risk of presuming that Linux today is sufficiently good for what you need to do is lower than it was 10 years ago, which is why Linux today is more popular than 10 years ago and a lot more popular than it was 20 years ago.


Following this logic, if a popular rust crate doesn't prioritize security, it can potentially change people's risk assessment of the rust ecosystem as a whole. So this maintainer's actions could have negative effects on other rust projects with no relation to his. He may not have an obligation to do anything about it, but it's kind of "not cool".


> Open source participants are volunteers and owe you nothing.

Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something.

Yes, I agree, volunteers don't owe anything but there are some unwritten rules that when broken should be frowned upon and I'd probably go as far as saying should be held against them.

As a reader of this, you could be thinking, wow this sounds extreme but here is the easiest example I can give.

- Someone writes library

- Library comes insanely popular

- Author refuses to allow the community to take over original project

- Author wants to maintain status, ownership, etc

- Entire community now suffers because the author doesn't owe anyone anything

"Just fork the repo", is the most common response but let's be real, nearly nobody uses the forks and every other repo that uses this popular library is using the non-forked repo.


Here's another one.

1. Someone writes a library

2. Library becomes insanely popular

3. Users receive value out of library

4. One day, users stop receiving value from library

Is the author not responsible for the value generated by this library? At what point does the author become required to continue providing value?

"Just fork it" is an excellent response to (4), anything else is what entitlement looks like.


There should be a "then take over maintenance" option. A good maintainer also steps back and hands over the project. That is less troublesome for the community I think this is a good practice.

But ignoring good practice: a unpaid maintainer owns nothing to anyone.


> Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something.

In most countries they actually have written laws which require you to help in such a situation though.


> In most countries they actually have written laws which require you to help in such a situation though.

"I wasn't aware someone got hit. I thought it was an animal."

What the law says & what people do :P


I'm glad you said something because I felt like I was going crazy reading some of these replies. People sometimes seem to forget the phrase "Remember the human" when they interact with maintainers. It's a really frustrating situation to watch because one of the main reasons I make software is as a creative outlet. So, I can see where Nikolay is coming from being frustrated and upset. Sometimes people want to just go around kicking over other peoples sand castles.

P.S. Thanks for making Sourcehut.


Seems like there should have been some sort of response from the maintainer about the _philosophy_ of why he was doing things the was he was, and people could either get onboard with the connecting points of that, or get lost. So far, in all of this drama, I have yet to see where any of that might have been explained. I don't use Rust, but I understand the significance of the experiment, and I think I for one, would have liked to read the author's thoughts about "why."


Why is the maintainer responsible for that? They're just another dev who wrote something that became popular.

It's almost like watching lottery winners having their lives ruined.


> Why is the maintainer responsible for that?

It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like this? I know, I know. I'm taking my crazy pills again. Sorry.


> It just seems to me that there's a give-and-take to being the maintainer of a popular open source project.

Sounds like a whole lotta give to me...


> You get help on the project in the form of people contributing patches, right?

It seems like you're trying to make it seem like there is always a legitimate exchange, and so they owe you something. Some projects want help, others don't. In the latter case, it's just a gift from the author, and they don't owe you anything.


> You get help on the project in the form of people contributing patches, right?

Any open source maintainer will tell you that many PRs, even well-intentioned ones, end up being a net negative. Often they don't further the maintainers aims, they need detailed review, take sometimes a lot of effort to manage the communication tactfully, etc.

Yes, many PRs are a win and it can be really gratifying seeing your project become bigger and better than you could have made on its own.

But also, many PRs are just a chore and a hassle.


And this is why I honestly don't ever want to release an open-source project.

At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license just to reinforce my "you take what you can get" policy.


Why? I mean, if you're that hostile to collaboration, why not just keep it closed source and maybe try to charge for it?


If I write something useful, I'm willing to share it with people when I can. It makes me happy knowing I contributed something that might make the world a smidge better.

That doesn't mean I'm willing to accept your patch. As soon as I accept collaboration, I need to worry about copyright on the contributions, whether they follow my coding style, and whether I'm willing to accept additional complexity for features I don't care about.


> Why? I mean, if you're that hostile to collaboration, why not just keep it closed source and maybe try to charge for it?

- There exist open source licenses (with copyleft) that disallow making it closed source.

- There exist other reasons to publish the source code: for example allowing the user to study it.


Python is my language of choice, so posting projects means publishing the source code.


> Python is my language of choice, so posting projects means publishing the source code.

Technically you could just post the .pyc bytecode as long as you didn't care about it working on anything but CPython and compatible implementations.


This might make it a bit harder for someone but wouldn't really stop people from reverse engineering it.


> Maybe I'll even use a non-free license just to reinforce my "you take what you can get" policy.

Consider CC0 instead.

As a veteran open source contributor, I totally understand that dealing with open source communities has a huge cost to go with the huge benefit. Even just vetting patches can be a pain when you care about security and architecture and don't want to spend time endlessly explaining your choices.

CC0 allows you to provide maximum benefit should you opt out of "social coding". People can go ahead and fork your stuff, or just use bits and pieces, without needing to deal with licensing or crediting headaches. (Significant consumers still have to track provenance, though.)


Please don't blindly attempt dedication of your works to the public domain based on this comment.


What is your objection? Do we have a disagreement about licensing, for instance because you'd advocate a copyleft license instead? Or do you disagree with the notion that open source contributors should have the option of opting out of social coding?

Certainly I would expect amyjess and anyone else reading to exercise due skepticism and perform their own research and I respect them enough to expect that they will "consider" my suggestion rather than "blindly" follow it.


I think people shouldn't ill-informedly attempt to waive their legal rights, especially not in ways that are legally murky, and I think people shouldn't ill-informedly encourage others to waive legal rights in murky ways they may not be aware of. You didn't even mention "public domain" once and implied "CC0" was a form of license, despite attempting a public domain dedication being a very different thing from licensing copyrighted works.


Well, for jurisdictions where dedication to the public domain is not possible, CC0 includes a fallback license. I suppose I could have used the words "public domain", and that would have made the intention clearer — so thank you for raising that point. However, if you are going to do a public domain dedication, you really should use CC0!

PS: Why assume everyone is "ill-informed"? We're all learning together forever: you, me, amyjess, other readers...


While that might have made the community feel a little better, I don't think the maintainer had to do anything, certainly they don't have to explain why they made this or that decision.

People should decide if it's a big deal for them and if it is, fork the project to fix the issue or move to another library. I have had to do this many times myself, I kind of thought that's just how things worked with smaller projects. More than once I've found someone of a like mind has _already_ forked and made the change.


There is absolutely no obligation to even reply to mails. Otherwise you fall into the trap of having to explain everything to everybody and not doing your project.


Indeed. I am glad you point this out.

The level of entitlement in the discussion astonishes me. Someone has done a lot of work and offered it for free along with a license that lets people modify it and redistribute it and that is not enough. Instead of being grateful for it, people are demanding that the giver also make the changes that these people need and take on the burden of maintaining them.

To all those people: Why should he? Do it yourself or pay someone to do it. It need not be any more complicated than that.


I believe he already included that in the README https://github.com/actix/actix-web


> User entitlement is totally unjustified and will burn out maintainers faster than almost anything else.

That's correct. Here's Rich Hickey's take on it: https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...


+1000. That should be required reading for anyone starting or using an open source project.


Do you think we get software like zlib and libjpeg and BLAS and linpack by people shrugging off working for the community and failing to fix bugs?

Otherwise we get dozens of half broken forks all over the place. That's no fun for anyone.

This wasn't a drive by beg. This was a patch solving real demonstrable problems and at minimum there should have been a transition plan due to basic decency.


"The maintainer owes the community something, simply because the community decided to adopt the project."

Doesn't work that way, I'm afraid. The maintainer already gave the community something, and doesn't owe them anything more.


They owe people who write PR basic courtesy, not refusing patches on ground that it is "boring".


"Basic courtesy" is one thing. Accepting patches because they don't find them interesting is another thing, is different, and not required.

Giving someone the mere ability to make a PR is already a gift far beyond what the original author owes.


I'm not advocating for or against accepting the patch. I'm saying that the tone of the refusal is inappropriate.


> Open source participants are volunteers and owe you nothing.

And a lot of the internet has this wrong, including you.

Let me start by saying that Open Source is not a zero-sum game. I can make a library like your library and it doesn't have to be an adversarial relationship. I have users, you have a few less users.

But there are costs to having more. There is still only so much space in the ecosystem for so many actors. The more logging libraries we have the harder they are to find, the more drama there is over picking one...

The best analogy I have is a party. If I throw a party this weekend, and your birthday is next month, then I'm not hurting you. If I throw it the weekend of your birthday, knowing it's your birthday, I'm kinda being a dick. That's not cool, and you have every right to be upset.

Okay, but what does any of this have to do with Open Source projects, hinkley? I'm within my rights to throw a party. But my guests are within their rights to be upset if I throw a shitty party. They showed up. They could have been doing something else. But I insisted on taking up space and now I'm being ungracious about it. It's my party and I can treat people how I want is technically the truth, just like "I can do Open Source and ignore the concerns of my users" is technically the truth.

What I'm saying is that the people who show up don't have to like it. They're entitled to complain to people about it, especially if I don't apologize and say I'll do better next time, or get help.

It's my party, I can cry if I want to, but people are gonna talk.

[edit to add]

I think the problem is that we have a bunch of people who throw themselves into software at a young age because of or at the expense of social awkwardness, and we insist on treating things and other people as if they are machines instead of people who are also just trying to do the best they can. I'm fully aware that this observation cuts against my argument as well as supporting it, but we can't go on coddling people and organizations for ignoring the very real social aspects of our work. For being poor hosts.

And it's really hard, believe me I know. But people want to see that you're at least trying, or they will paint you the villain.


I completely agree. This is why, as a small company, we prefer languages that have large organizations backing their open source libraries - such as Java - and prefer not to touch things like Rust with a ten foot pole.


The article was not about that, this is not about vetting anything.

The problem was that PRs which would have fixed security issues where not accpeted.

Do I expected perfect code from maintainers or a answer the next day? No, never

Do I think maintainers/creators should merge prs in a timely manner, or ask for help if it get's too much? Yes, otherwise you have multiple forks and the project is not usable anymore.


If this is the issue, one of those forks will become the new mainline repo everyone contributes to. Expecting a maintainer to behave the way the community wants is unreasonable. Maintainers are not public servants.

I mean, anyone can fork it and become a maintainer, and create new guidelines and inclusive rules that ensure the project is steered in the "right" direction. Isn't it the case?

I understand the "we just want a better actix-web", but there are two conflicting concepts, "better", and "actix-web". The way I see it, "better" is whatever the maintainers think it is, and "actix-web" is a project belonging to its maintainers. No community should ever be entitled to try to steal that. They are welcome to build upon it and fork it. This doesn't mean they have to separate ways forever: some forks live happy parallel lives, as so many Linux patchsets have demonstrated over the years. Projects are free to be born, forked, cross-pollinated, merged together, even die, all at the will of their maintainers.


> If this is the issue, one of those forks will become the new mainline repo everyone contributes to.

I know that is how it is "supposed to work". However, I've very rarely seen it actually work that way.

The problem is the "first-mover advantage" and it is a hard one to overcome. If you make a "maintained actix-web" fork, most people will still find their way to the dead project. Even worse, many resources and tutorials will point to the old library. A search for "actix" will almost certainly give confusing and frustrating results to the novice.


Just as you shouldn't eat everything you just picked up from the sidewalk, you shouldn't just use any code thats available out there.

check, check and check again...


What is "a timely manner"?

When I signed up for a GitHub account, I don't recall anything about having to agree to an SLA.

I've seen many small projects that I use or monitor where someone will raise an issue or make a PR, and the owner will respond along the lines of "Great, looking into it, but I'm kind of busy right now, will get to it when I have time," and then people going off on them if "when I have time" isn't right now. Usually this is followed by an offer from the owner to give the reporter access or pass the ownership to them, which is invariably followed by crickets.

There has been a lot of talk in this thread about the obligations of project owners. This seems to boil down to fundamental philosophical differences. My view is that if you want people to do shit work and jump when you say frog, you have to pay them for it, rather than bully them.


> The problem was that PRs which would have fixed security issues where not accpeted.

It actually was not. The article is quite clear that the problem was created by the way the Rust community, particularly the one at Reddit, acted and reacted so poorly with regards to the way a project was maintained.

Let this be as clear as possible: the problem is not nor it ever was any PR. The problem is the appalling way the Rust community attacked the maintainers of a project.


Based on the noise the "maintainer shall/should/must/ought to" crowd is gigantic. It should not be an issue for this group to fork whatever they are kvetching about and do whatever "shall/should/must/ought to". So fork it and implement it!


That's good advice on how to treat others-- don't act entitled toward open source maintainers. Thank them for their work.

But what exactly are the responsibilities of a maintainer? How far should you go to fix bugs? How thorough should you be about your code's limitations?

If you're doing a project just for fun, should you discourage others from using it in production?


Given that Chromium is a open source project, and lost of people here are strongly against Google's proposal to limit the ability of ad block extensions, with much stronger words compared to this incident. What's your opinion on that?


Google is a gigantic, profit-making corpration, not a guy doing something for free as a side project/hobby.


This is a good reason to use Github only as a read-only mirror and just do all development elsewhere. That way you don't have to deal with drive-by issues / PRs from people who just want to complain or won't put in follow up effort.


Why even have the read-only mirror?


CI integrations, other tooling, etc can still be useful



As a someone who don't use Rust..

I started to suspect that this was satire with all the talk of inclusive and the use or 'unsafe'. I kept reading and reading in anticipation of gradual escalation that reveals it's satire. In the end there was none. I had to come here to read comments and to see if this was real or just very subtle satire. Apparently this is real.

I just can't wrap my head around the "inclusive community building". What happened to "Those who write the code decide everything" and "You are free to fork if you don't like where this is heading". Any free community is as much about exclusion as inclusion.


Rust has a strong culture of shame. The whole language surrounding unsafe is pregnant with the vocabulary of shame. Using unsafe or writing in a memory-unsafe language instead of Rust are grounds for public shaming.


> 2. Open source participants are volunteers and owe you nothing.

If this were true in the strictest sense, then they would be free to put malicious code and trick you into using their stack just to then steal credit card numbers from your database. Of course this is not true, and they would appear to at the every least owe us "good faith" or perhaps some basic guarantee that they are not purposefully trying to criminally attack you. This may seem like a useless edge case to bring up, except for the fact that the law does have some amount of consideration for negligence.

Arbitrary people you don't know owe you nothing too, and yet if you walk onto their premises and get hurt, the law has found in certain circumstances that they are indeed at fault. Expectations and responsibilities evolve with time, and as new scenarios come up. It is not clear to me that putting up a project that invites people to use it in production could not be argued to some extent to be negligent if it willfully blocks and delays fixes that could affect real world customers.

At the end of the day, if people were using my code in production, and a discovered exploit was used to steal people's data and I could have prevented this by merging in code that wasn't 100% to my aesthetic liking, then I think I would feel bad. Fault isn't binary, maybe its the fault of a random company using my framework for not being up to the minute on all vulnerabilities and manually patching the code themselves, maybe its their fault for using my framework in the first place given the youth of the project too. But I don't think I would go to sleep that night feeling great is all I'm saying.

I'm not super familiar with this particular case, but the OP blog post was phrased as kind of wanting to open up a dialog or discussion on the nature of these issues. I am bringing up some thoughts about this stuff I've had for a while and I think at least help to understand some of the moving parts involved. For the record, I don't really know where I stand "absolutely", or if its possible to have a clear principle that doesn't take into account some number of additional variables (how the project was portrayed, how many users it has, etc.).


> Open source participants are volunteers and owe you nothing.

Of course they do. It’s not legal for you to distribute software that puts others in harm’s way. You’re not allowed to give poisoned food to homeless people as long as it’s free.


Of course they don't. It is Free OSS. And you implying that the maintainer put someone's life in harms way is simply not true. And the LICENSE says - no warranty or guarantee whatsoever... Use at your one risk. And the homeless people analogy makes very little sense, excuse me for being blunt. You are comparing software developers who use FOSS to homeless people??? You are comparing someone's FOSS project on github to poisoned food??? Are you for real??


> And the LICENSE says - no warranty or guarantee whatsoever

Lol. That’s about as legal as saying you can’t be arrested because you’re a sovereign citizen.


While it is tempting to agree, I feel that if you take these principles to their logical conclusions, you lose any incentive to actually participate in any open source projects. If I cannot expect the author to even look at my code or read my issue reports, there is no reason for me to write the reports or share my fixes. If all my dependencies are my responsibility, the logical way to go is to fork every code base I am going to use, review all the code, fix whatever issues I find in my fork and never share any of it with the original project because there is no reason to.


I would add one more: your patch isn't good just because it exists. Maintainers should, in general, refuse more patches, or they're not really maintaining anything, just overseeing a disaster.


Agreed 100%. May I add one point?

The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project: how much are they open to change the project's core values, how responsive on average will they be in terms of opened issues and PRs, roughly how often would they engage in technical architectural debates -- stuff along those lines.

I feel many people get toxic if they had unrealistic expectations -- and that's of course not okay.

But IMO the OSS maintainers can be a little more preliminarily proactive in managing expectations from earlier stages.


> The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project

Why do you think they owe you this? You didn't pay them, and they didn't accept a contract.


I don't feel I am owed this at all. I feel only that it's being a good open-source citizen.

When you make something that people use and like and want to improve, you should at least have the common decency to tell them beforehand: "this is my show, not gonna accept PRs".

I don't think it's such an exhausting job to write two lines at the top of the README.


Appealing to "common decency" is just the same as "being owed". I think you're mincing words to avoid sounding entitled, and I don't think anyone is even entitled to two lines in a README, much less at the top.


All I am doing is saying that it takes very little effort to be upfront and hopefully avoid future confusion. You are free to disagree. ¯\_(ツ)_/¯


I agree that it might help avoid conflict/confusion. I do not, however, agree if you say that they "owe" this to anyone. Their (free software developers') work is already a gift to the world. Take it or leave it. No one is compelled to like it or to take it and use it - doubly so for mission critical stuff.


You can do this for your projects, but I don’t care if someone does this.

I’m grateful just to see the code and choose to use it, or not. If I think some random volunteer should do something, I’ll attach that suggestion with some money or a contract or at least a beer.

What I love about open source is that it’s a big place that has lots different people. It’s beautiful because someone can write code and never talk to anyone and their code is still good and useful.

Maybe a better, more truthful statement is “OSS maintainers will have better engagement with the community if they proactively manage expectations.” And if the maintainer cares about that, it will apply. But I think there are quite a few projects that don’t really care much about community.


While I 100% agree with you, project having chronically technical issues are bound to get a bad reputation.

So what is "missing" is a common way to discuss about that kind of issues, as a community, while staying civil and not in a way that is worse than the initial issue. In some cases the end-result could be the kind of the same (if most users flee), but the goal is obviously to improve the ecosystem and if managed more appropriately, it is possible that some maintainers are wanting to improve their software to the state of the art.


However, everything has its downsides. For example:

> 1. YOU are responsible for your dependencies.

This contributes to the prejudice against `unsafe`. If I wanted to be a full-time auditor, I wouldn't be steering clear of C and C++.

Since I'm a responsible coder, I avoid depending on `unsafe` outside of `std` or the simplest of FFI wrappers with extreme prejudice, to the point where I consider NIHing an alternative or just sticking to a managed language with a more mature ecosystem, depending on the project.


I've worked with Rust only rarely, and never built anything real from scratch with it myself, so I'm curious: what tools are available to assess the safety of dependencies? I agree with you in principle that "you are responsible for your dependencies", but how would you go about doing that for a large complex dependency like this?


cargo-geiger will recursively warn you of unsafe code in dependencies: https://github.com/anderejd/cargo-geiger

It's not a silver bullet, it will show you areas where memory safety issues could arise, but doesn't necessarily prove the presence of memory safety issues. Memory safety issues aren't the only type of security bug so them being impossible also doesn't mean it's entirely safe. You can think of issues like injection attacks or faulty ACL logic happening without memory unsafety.

There's also cargo-crev, which is an attempt at making a web of trust for reviews of third party packages: https://github.com/crev-dev/cargo-crev - for a longer form article on what crev's goals are and how it works, I found this explained it for me: https://wiki.alopex.li/ActuallyUsingCrev


miri is another good tool you didn't mention; it runtime sanitizes for undefined behavior.


Agreed. I think there is quite a lot of entitlement on the internet and as Klabnik pointed out: on reddit. And while it's definitely a maintainer's responsibility to make their code serve the interest of its users to the best of their ability, fundamental disagreement should result in forks, not vitriol.

It's moments like this that I reflect on the past and the public and virtual forums I have participated in... and how my own attitude shifts in favor of cooperation when I must couple my face with my words. And I wonder if others feel the same.


Open source maintainers have no such responsibility. Anything you get for free is a gift, and giving a gift doesn't create any ongoing responsibility for the giver. Take it or leave it.


I disagree here, but only within the confines of the language I used. A maintainer of open source code is willingly submitting their own work to be used for free by others. They have no responsibility to extend it at all, but to maintain it is to do so in the interest of the users... they have a responsibility to do it to the best of their ability, and if not, the maintenance should be given to someone who will.


No. Just no. They may do so to the worst of their abilities. Thats their prerogative.

The only limit might be publishing something that is actively intended to do harm. But I can't imagine a plausible example of that...


You might not believe this, but I agree with you! Doing something to the best of your ability includes the right to be able to suck at it also. I am pressing for absolutely no standard of quality, yet you somehow think that's the case. It's not. I just think that if you're going to call yourself a maintainer of something, then you better at least pretend.


I disagree. I really think doing an intentionally crappy job is acceptable. Not even pretend. I think it is okay to really half-arse it. Or break it. Or be lazy. Or whatever. Except maybe intentionally harm someone.


Intentionally doing a crappy job is harmful.

And if you're intentionally doing any of the things you listed above, then you're not a maintainer. That simply is not what maintaining means.


> it's definitely a maintainer's responsibility to make their code serve the interest of its users to the best of their ability

No it isn't, unless those users are paying.


If that's the case, then why open source it at all? Just make people pay.


Why is it a problem for you if someone is willing to give their work to the world in a way that allows others to benefit from it? Why is that not enough? Why do they also have to keep doing more after that?

If you disagree with the notion of someone publishing their work under a free software or open source license being useful for the world, then please post an AskHN about it and you will have _plenty_ of material to convince you of this perspective. However, I think most reasonably clever people can already come to the conclusion themselves.


It is enough, and I don't disagree with "the notion of someone publishing their work under a free software or open source license being useful for the world." I have simply no idea where you got the idea that I would disagree with that.

What you are responding to is a rhetorical response I gave as an argument against the dismissive idea that an open source maintainer should have no responsibility unless they are getting paid. I don't agree. I find that it's a maintainer's responsibility not to extend, but to maintain. That's all I'm arguing.

If someone wants to throw OSS at the wall to see if it sticks with no obligation to maintain, then that's fine. But as soon as someone puts on the maintainer hat, I think it's reasonable to say they are accepting responsibility for that role.


> I have simply no idea where you got the idea that I would disagree with that.

"If that's the case, then why open source it at all?"

This is the part which made me feel you disagreed with it.

However, may I ask if it is your belief something released under an open source license comes with an intent to maintain it (for others)? Or that releasing something under an open source license is a declaration of being a maintainer of said software?

(not trying to be snarky and am just trying to see why we appear to be in disagreement)


>> "If that's the case, then why open source it at all"

> This is the part which made me feel you disagreed with it.

I am aware, and as I already explained, this is a rhetorical device which you mistook for my own personal belief. Obviously I don't believe OSS is bad. It's friggen great.

And that's a fair question. I am absolutely not saying that open source means you must maintain it. I am simply saying if you call yourself a maintainer then you are responsible for maintaining. If you don't want to maintain OSS, then don't. Just don't pretend you're a maintainer and that you have no responsibility to maintain. At best, pass it on to someone willing to maintain it. At worst, pretend you're working on it. As I said in my original comment, others should fork as needed.

And to add, I don't believe the original subject of the article, the now former maintainer of actix-web, did the wrong thing. I am in agreement with their decision to drop out. No one should be held to an unrealistic standard by entitled users and expected to put up with that BS. The part of my original comment that everyone has a problem with is seriously the least consequential phrase. Blows my mind that everyone is hyper focused on taking it out of context as well.


Thank you. I now see where we differ in our beliefs. We have to just agree that we may never agree on what responsibilities lie with a maintainer (if he is not paid for it by the users(s)).


There are many possible reasons, and yes, one is because they might hope it's useful to other people. That's not the same as being "responsible" for such usefulness.


And I agree completely. Except when you claim you're a "maintainer." If you do, that is supposed to mean something. And I think it means you're going to maintain the code. That's the only responsibility I am talking about.


Maintainer is a term of art that just means you’re the person in charge of the project.



Actualy, it’s the maintainer’s responsibility to make their code serve their own interests. Those often, but not always, align with the users’ interests.


Then why open source at all if there is not some interest in helping others who have "aligned interests"?


So that others can pick the pieces they need, if they care to. It's an offer to the world, not a sales pitch.


If you post random code on the internet at your leisure, sure. When you have a marketing campaign for your open source tool... then yea, it's a sales pitch.


The best justification for this attitude is that it's the most encouraging of open source development. Other attitudes raise the cost of open source development -- considering that it's already a losing proposition (w.r.t. lost time + opportunity) -- and will result in less quality open source software. People just won't put the work in if all they get back is this entitled bullshit.


I feel as though there's a certain developer entitlement that also needs addressing though. Just because you made a software doesn't mean I have to use it or like it, and if you are actively trying to recruit me to use it then I am indeed entitled to complain about it.

I see it frequently in the FOSS community where someone will suggest some software they made to solve a problem, get told why their software isn't actually that good for the problem, become defensive about it, and then try to play the "entitled user" card.


The opinion that the software isn't that good for the problem is cheap to state, and unless the circumstances are exceptional, I would argue it quite reasonable to see it as entitlement.

If someone is terribly dressed according to my taste but brags about how amazing the garb is, I'm not going to tell them how they are wrong unless absolutely necessary because of exceptional circumstances.

Neither does most people who respect others right to their own body, and creativity.

I don't ring up the artists after visiting a gallery to tell them how their art is done, not unless I'm an ass.

Source code is not much different, it is an expression of technical competency, art, taste, and fashion.

If someone asks for feedback, sure, your points are not wrong.

In practicing social dancing, asking if someone wants feedback before giving it generally works out really well. Most people want feedback if you give them the power to choose for themselves, but quite a few really do get hurt if it is unsolicited. There will be some people that get slightly annoyed that you ask, as they prefer more direct approach, but neither they or anyone else get hurt.

Something similar probably works for open source projects too. Engage seriously for a bit, and only then ask if your input on your particular issues would be interesting to the other party.


> If someone asks for feedback, sure, your points are not wrong.

If they're actively asking me to use their software, isn't that soliciting feedback? If I say 'no, it won't work for me', I've apparently committed some egregious microaggression right? If I just say 'no thanks', what do expect the very next thing they say is going to be?


Who said they're actively asking you? I'd say most smaller open source (e.g., single dev) projects are "here's what I built, maybe it's useful for you too."


> Who said they're actively asking you?

>> Just because you made a software doesn't mean I have to use it or like it, and if you are actively trying to recruit me to use it then I am indeed entitled to complain about it.

That is what I wrote. That is entirely the context of what I said.


There’s an interesting gray area here: am I as a customer responsible for knowing the dependencies of a service I use? Most of the time that’s impossible. And things like GDPR seem to imply that people believe users are entitled to some degree to demand certain standards (privacy/security) from all web services.

This is the potential problem with “just fork it”. If the library is used by a great many products, and you know of a security vulnerability, merely providing an alternative that fixes it could be argued is not sufficient, while fixing it in the root library will patch the vulnerability in every product that has it in the next update.

It seems we still haven’t figured out (and perhaps never will) the exact responsibilities between all the parties at play.


GDPR binds an operator of a service. The developer can do as he likes.


My point is that GDPR raised the bar of our expectations of what a consumer can demand from a provider. As such, perhaps it is not unreasonable to expect that there would be an expectation from other services, especially if they are integral to the operation of many services that have personal information of millions of people.

As a pure hypothetical, imagine a critical bug was discovered in Rails that would potentially allow someone to attack any Rails website and extract personal information. Further, imagine someone quickly submitted a PR with a patch for this, such that Rails could then do a quick release and make sure it gets to every Rails consumer as fast as possible.

What if the Rails maintainers then ignored the patch, and said it was boring. Legally they are under no obligation to do anything really. And you could argue that it's on every one of the thousands of sites that chose to use Rails if they get hacked and expose user information. And further, you could argue that if people don't like this situation, they are "free to fork Rails" with the patched version. All this is fair, but I think others might say that the Rails maintainers at this point did fail in a responsibility. There are arguments for both sides, but I do not think it is as simple as "the maintainers owe people absolutely nothing" as at some point being the nexus of updates actually gives them an almost stopping or blocking power, not just the more passive refusal to fix the problem themselves.

This scenario is clearly different in magnitude from what happened with this project. That being said, my only point is that it is fair to expect a certain amount of activity in a project that bills itself as production-ready (and asks you to use it). I personally would be very weary before committing to telling someone something is production ready casually, regardless of whether the "fault" ultimately rests on them. That being said, this of course does not entitle anyone to treating others poorly, my only point is that the responsibilities and expectations are not well understood in this domain.


I wish I could up-vote this 1000 times.


> “ 2. Open source participants are volunteers and owe you nothing.”

Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project.

The users of open-source projects, upon which the projects themselves depend, are also not obligated to anything, and can for example (very reasonably) become angry and complain if people prioritize pet features instead of community needs, or unilaterally take projects in unsupported directions.

There is compensation for the work, and there are still social norms. Nobody cares one bit about who is entitled or not entitled to what.


>> “ 2. Open source participants are volunteers and owe you nothing.”

> They are compensated with

> prestige,

That seems associated with the popularity of a project which is largely outside the control of an author. So: how could one publish code (just in case it's useful to somebody else, which seems to be a nice thing to do) and opt-out of the popularity contest?

> enjoyment,

People can have the same enjoyment without publishing the code, so there's nothing open source about that.

> decision-making power,

In their own project? Of course. Again, they could just keep it private, with exactly the same decision-making power - nothing open source about that.

> future employment rewards,

If a developer ships crap code, that issue seems to sort itself out automatically (who would hire a proud author of unsafe code?)

> and sometimes even money,

Those paying money certainly can and do make demands. I haven't heard claims about breach of contract in this case, so that's probably not a factor here?


> “ That seems associated with the popularity of a project which is largely outside the control of an author.”

Huh?


People have a right to become angry. They absolutely don't have any right to override the will of a project maintainer.

By the way, isn't this a great opportunity? The code is open. Fork it. Seize the day. Become a better maintainer, and build a community around your fork. Ensure the community needs and wants are aligned with yours. Steer that ship. Gain prestige. And money, maybe.

If someone is a bad maintainer, there will be no community, no prestige, and no money.


> People have a right to become angry.

No. You have a right to be annoyed, and then fork the project if you want.

You do not have a right to become angry unless you're paying for it.


I'll clarify. I meant that people are entitled to their own emotions, and being angry is ok. What's not ok is to hurl the anger towards somebody. In this case, there are lots of other good options, all of them more productive and compassionate than simply grabbing the pitchforks.


No, you do have the right to be angry, even for something you’re not paying for. Absence of a financial agreement does not mean dissolution of basic community norms.


> Seems everyone believes there is large team behind actix with unlimited time and budget. (Btw thanks to everyone who provided prs and other help!) For example, async/await took three weeks 12 hours/day work stint, quite exhausting, and what happened after release, I started to receive complaints that docs are not updated and i have to go fix my shit.

> enjoyment

Riiight


I think your quoted comment just proves the point. Without community complaint / critical response, there isn’t incentive for the implementer to do the thing the community needs.

If you do X for enjoyment and it actively hinders some other group because they needed Y and using personal priorities to rank addressing X instead of Y is an egregious violation of community norms, people will take action to bring down the enjoyability of doing X and raise the enjoyability of doing Y, like complaining about X and thanking you for Y.


I didn't think I would see a "I will pay you with exposure" argument.


Why? That’s the most likely type of reward you would get from a successful open-source contribution, and should be factored in to consideration of what is a priority.


When open-source gets up in arms over some guy doing or not doing something on his own time and dime, I just can't muster that level of ire and self-righteous anger.

If you as a user don't like it, ask for a refund.


Thank You, you nailed it. There are always a high chances of being heavily downvoted on HN every time the question of entitlement comes into discussion. So I am glad this is the top reply at the moment.

And I think that is the problem I have with this blog post, It reads to me as trying to spin it as something else with anxiety or Reddit, when what I see the problem is something very different based on principles and values.


> It was never Nikolay's job to vet actix-web for you

Perhaps, but if he claimed that it _was_ vetted, then he took on some responsibility for it (which he probably should not have).

Also, the blog post article claims, that you are never supposed to use "unsafe" code without having vetted it. Honestly, I doubt that very much, but if it's true than that's some responsibility taken too.


If a fundamental plank in rust's safety platform involves "apply the honor system to random people on the internet who swear they've vetted something", then that's a problem.


That’s not true, the convention is to annotate unsafe blocks with a comment explaining why the code is in fact safe. There are even projects that automate looking for these


When you write "... the Rust project saw Rust as more than just the language. The community and the people mattered." I have to ask why anyone thinks this isn't true for ANY code/stack/dep out there?

When I evaluate a technology for its appropriateness I first look at who's using it: Literally "Who are these people and what are they working on with this stuff?" The answer to this question determines more than 80% of the decision on whether the thing is going to be my choice.

Rust seems to be being used most by people who are interested in blockchain and crypto. They tend to be of a near monolithic ideological caste, too, which has its own problems. Do I want to get into a situation where I might have my hat in my hand with these folks? Not really.

(also the rust compiler is so slow I cannot believe it)


> Rust seems to be being used most by people who are interested in blockchain and crypto.

What makes you think that? I don't believe that is true, it's like saying C++ programmers are mostly interested in high frequency trading.


Well then who are these people?


It’s a general purpose programming language. I know people doing embedded bare metal development on ARM, people writing single page browser apps and others experimenting with replacing their C++ packet parser for VoIP telephony.

edit: typo


https://github.com/search?q=language%3Arust

You can easily find counter-examples if you look for them.


> Rust seems to be being used most by people who are interested in blockchain and crypto

Where did you get that from? From what I've seen every single blockchain/crypto post on Rust's subreddit is downvoted into the negatives.


Probably related to the Reddit job ads when you read /r/rust.

That said, blockchain companies using Rust take security very seriously. It also funds cryptographic research which has a huge need of memory safety, performance and the possibility to implement constant-time primitives.

I don't see why the community of a language that focuses on safety and speed is not excited by having the language being adopted by communities which absolutely cannot compromise on safety and speed (communities referring to both cryptography and blockchain communities as they are distinct).

Disclaimer: I work in blockchain, I implement cryptographic primitives. While I don't use Rust, I do read a lot of Rust code from other blockchain projects or from cryptographers from elliptic curve cryptography to hashing functions.


Oh, everyone likes cryptography and is reluctantly thankful that "blockchain" companies fund FOSS projects. But most people don't like "blockchain" because there's a lot of good reasons to dislike it.

My reasons can be summed up as: "public blockchain" aka cryptocurrency is toxic — it's horrendously inefficient in the name of achieving censorship resistance, so people are literally burning fucktons of energy to make perfect "crime currency" work. It has fueled the rise of ransomware (and extortion in general) and all kinds of scams. Meanwhile "private blockchain" is just like good old merkle tree/hash chain stuff, infused with hilarious/awful marketing fueled by cryptocurrency hype.

Good talk about this: https://www.youtube.com/watch?v=xCHab0dNnj4


- I wouldn't conflate blockchain and cryptocurrency. Cryptocurrencies are one (infamous) use-case of blockchain technology.

- I agree that cryptocurrency turf fights are toxic

- censorship resistance does not equate privacy. The main blockchains today are actually fully transparent. The perfect crim currency is cash which is almost untraceable.

- The energy burn is to achieve distributed consensus. I don't think there is any distributed consensus algorithms that is not a tremendous energy burn today be it physical voting (transports, broadcasts, special machines, security, ...) or CEOs and diplomats flying around the world.

- The energy burn is still concerning but Proof-of-Work is not the only way to solve the Byzantine General problem via economic incentives. You only need a "rare resource" that cannot be easily replicated to avoid sybil attacks (i.e. not an email address). That can be cryptocurrency (Proof-of-stake) or storage (Proof-of-spacetime)

- I don't think you realize the scale of drug trafficking and other unsavory endeavors that use cash.

- Mostly agreed on private blockchain but there are some industry-wide private blockchains that are starting to emerge (including UNICEF and FAO) with very interesting applications (identity of children refugees and managing food).


> Cryptocurrencies are one (infamous) use-case of blockchain technology

None of the "other use cases" have been interesting in any way.

> The main blockchains today are actually fully transparent

So what? If the exchange between the cryptocurrency and real cash is not compromised, the only traceable thing is that some address which you don't know anything about got paid from another address which you don't know anything about.

Again, real world ransomware mostly uses Bitcoin.

> I don't think there is any distributed consensus algorithms that is not a tremendous energy burn today

Anything that is not trustless, even physical voting, should be vastly more efficient.

> Proof-of-stake […] Proof-of-spacetime

Yeah, when did Ethereum promise a switch to proof-of-steak? Where is that again? Has anyone actually proven the security of any of these alternatives?


I have been complaining about Rust's "unsafe" for years. There's too much "unsafe" code because there are things that you either can't express, or are very hard to express, in safe Rust. I've pointed out partially initialized arrays and backlinks as key trouble spots. Both are potentially fixable. I've gotten back complicated excuses for not dealing with these design problems. There was a serious denial problem in the Rust community. Now it's come back to bite them.

Language design that forces users to lie to the language leads to this. The classic is C's "a pointer is also an array" mindset. When you write

   int read(int fd, char* buf, size_t buflen)
that "char *" is a lie. You're not sending a pointer to a single character. You're sending a reference to an array of unknown size. That design mistake in C has probably been the cause of more serious bugs than any other mistake in the history of programming. If you have to lie to the language, the language is broken.

Rust had so much promise, too.


    there are things that you either 
    can't express, or are very hard
    to express, in safe Rust.
This is true (and in some sense inevitable by Rice's theorem) but it is unclear what can be done about this. Bear in mind that Rust's design constraints are

- decidable (indeed fast) type-inference/type-checking

- simple typing system

- you don't pay for features you don't use

It is easy to get rid of unsafe blocks if you throw complexity at Rust, e.g. use dependent types and / or theorem provers, but all the obvious ways of doing this immediately violate the constraints above. Doing it within Rust's constraints is an open research problem.

   potentially fixable.
What would you use as an objective, measurable criterion that we can use to decided whether a purposed fix is in fact a fix? If you have a concrete design proposal that works (in particular w/o destroying Rust's fast (bidirectional) type-inference/type-checking and the simplicity of Rust's types), and evidence that it's widely applicable (i.e. doesn't just allow to type some trivial edge cases of back-links and partially initialised arrays) that would easily publishable in top PL conferences (e.g. POPL) and a working prototype would help towards getting this into Rust.

I would be happy to help with implementing & writing up such work. I have quite a bit of experience with sub-structural types a la Rust. I have spend some time thinking about this problem space, but didn't manage to crack it. I have an incoming PhD student whom I could ask to help with this.


Oh, not Rice's theorem again. That only applies to infinite systems. There are useful decidable properties for a reasonably large set of programs. Yes, they're "uninteresting" mathematically, but we're talking about memory safety here. If your program is anywhere near undecidable in that area, you're doing it wrong. Any time you're close to the edge on that, you can get decidability with a run-time check. The Microsoft Static Verifier people have been down that road with some success. I went there 40 years ago, with the Pascal-F Verifier.

The question I'm asking is, what do you really need to do that you can't do in safe code. On the memory safety front, for pure Rust (no calls to C), probably not all that much. Maybe only this:

- Syntax for talking about partially initialized arrays. For a collection, you have a variable that indicates how much of the array has been initialized, and you need a statement in the language that ties that variable to a partially initialized array. Then you can do simple inductive proofs to show that as you initialize another element and add 1 to the counter, the entire array is initialized. Non-consecutive initialization would require more complex proofs. Is there a real use case for that? One with major performance implications, where initializing the data to some null value would be too slow?

Un-initialized blocks of types such as raw bytes aren't a problem, because those types are "fully mapped" - all bit combinations are valid. Only types that are not fully mapped an initialization guarantee.

- Backlinks. Backlinks in doubly-linked lists and trees obey some simple invariants. You need syntax to say "this is a backlink". That implies an invariant that if A points to B, B must point back to A. Everything which updates A or B must preserve that invariant. The pointer from B back to A then no longer needs to have ownership of A. (It's a problem that Rust doesn't have "objects", because such invariants are usually required to be true when control is outside the object, but can be broken momentarily while control is inside it. The inside/outside distinction is important for this, and Rust is a bit soft on that. Spec# took inside/outside seriously, but viewed it dynamically, rather than being tied to static scope. Haven't looked at that in years.

What else do you really need? Remember that some knotty ownership problems can be resolved by allocating the objects in an array which owns them, and using array indices for relationships between the objects. It's not like you have to use pointers.

Concurrency is a related issue, but I've said enough for one night.


I'm still unclear about this, should this be done by the typing system or by an external static verifier:

   simple inductive proofs to show 
   that as you initialize 
   another element and add 1 to 
   the counter
If the latter, you can already do this with Rust as it is, it's just a question of building such a static verifier. If the former, I really doubt that this can fit in Rust's typing system without major surgery. We know well how to add arithmetic to typing systems, but the natural approach to doing so (dependent types) will probably make type-checking / -inference undecidable.


I’m replying to your message using software written in C, so do you think that it might be a little bit unfair to call it “broken”?

I suppose I’d agree if you’re making a general argument that most of the software we use is broken to some degree, but it has an entirely different meaning to directly tell someone “Your library is broken”.


Are you? All web browsers I know of are written in C++ and always have been. In modern C++ you don't use char* to mean "pointer to byte array of unknown size", you use std::vector. Moreover Chrome actually uses garbage collected C++ (they call it Oilpan).


They may be using Linux as OS.


>You're sending a reference to an array of unknown size.

The next argument is literally the length of the array.


No, that's what the caller says is the length of the array and as we already established, they're lying. ;)

In all seriousness there is quite a difference in structures that allow themselves to have guarantees built into the language/tooling (like including the size of the array in the languages basic "array" building block) vs. the more manual book-keeping the C code above requires.


I remember when people were claiming Common Lisp community is toxic, but I find that it is the languages which tend to focus on "building community" with Community Managers and Codes of Conduct that end up becoming truly toxic cesspools in the end. See also node.js. The focus on community attracts people who aren't interested in programming, but rather those who want a playground for gaining clout and trolling. You never hear about C++ drama, why is that?


Primates tend to attack each other out of envy when they become too similar and all behave the same exact way. They look to find someone to crucify to get rid of the angst built up from being too similar to the next person.

The Common Lisp community was pretty much the opposite of the Node/Rust crowd. Everyone was different. Lots of people were using different implementations of CL. Most people even had their own custom editors. And of course everyone had their own DSL of macros they carried around with them, so basically everyone had their own language. The supposed toxicity of the CL community was from the constant arguments because they all had strong opinions different from each other.

If this were the CL community, there would be 20 different versions of actix-web or something like it. There would be no need to create drama and make whiny demands of other people, because everyone in CL actually knows how to program.


If the community is openly acerbic, toxic, autocratic, etc it sometimes becomes less of an issue because you know exactly what to expect, and expectation management is important for people.

If I in the past would have felt I needed to send a patch to the lkml, I wouldn't have felt intimidated because if my code would've gotten shredded to pieces, I was in very good company. The lkml also didn't really brigade, or bully, even if people sometimes was quite emotional. However, for some people I'm sure it would be hell.

There are however several projects with extensive guidelines that I would feel intimidated to interact with, as the power struggles and infighting is likely to be well and alive although I can't see it, there's also a brigade of attackers available to anyone who manage to convince them I was in the wrong.

Community guidelines unless expertly written and religiously enforced are unproportionally useful for those with either a manipulative streak, or those with good social and language skills, as they often grant them more power. In this respect mirroring society. However, apart from keeping the most blatant misconduct out of the open, it also becomes a weapon to be used against anyone less adept at navigating the social hierarchy. Thus, the extent to wherever a particular community ends up, in reality becomes almost inscrutable to the casual observer.

For me it's the same in real life, in contexts where the societal norms are somewhat displaced I have few issues. The selfish, aggressive, and other bad actors stand out like they would wear neon colors. In society in general, in the workplace, I have all kinds of issues because amid all the unspoken rules there will always be one that can be sufficiently well misapplied to defuse valid criticism.

We don't get pathological liars voted into various offices because people are good at arguing rationally, but they also tend get to stay there because they are protected by the rules, unless the rules are expertly and independently applied.


Oh, there is plenty of drama on /r/cpp/.


That’s an interesting point of view. I don’t know if it’s true, but if it were true I wonder what the reason might be.

Perhaps the communities that don’t “do community building” don’t need to because they already have a healthy community?

Perhaps the projects that do community building are starting from an unhealthy place and fighting an uphill battle?

Or perhaps some percentage of the “community builders” are the ones who like to rage/shame anyone who, even unintentionally, causes any offense? Which naturally escalates the conflict.

Which way does causation run?


There was incredible amount of Linux drama all the time and they did not focused on community.

The tor project was like, the most dramatic project on Internet for a while till they started to focus on community a bit more.

So I don't think premise holds.


I don't think a few compiler engineers can hold themselves responsible for the Twitter/Reddit behavior of thousands of programmers (which at this point are selected more or less evenly from the whole population of programmers), no matter how noble the sentiment might be.


What makes me sad is that someone spent a huge amount of time making something, working on something, supporting something. If you don't like that something, then use something else or write your own thing. I don't get how there is some responsibility of maintainers to turn a passion project into anything other than what they want?! Fork.


I think there are three things that combine to cause the underlying problem:

1. Open source creators own the package and they owe you nothing. Most (all?) of the major package repositories follow this model.

2. There are very few ways to officially fix a major dependency if the creator(s) take a powder beyond cajoling or forking and attempting to maintain it yourself.

3. Many people are using VERY complex and important packages that, frankly, they may not actually be able to maintain themselves. I fall into this category for some packages that I use and I'm sure most people do, especially on small projects.

So, you are left with hoping the OS creator stays on top of things or cajoling.

Once cajoling fails, and you are in a bind, a bind that may threaten your job and career; things get ugly. It's not right, but it's human nature and it's predictable.

I'm identifying the problem, I really don't have a solution.


There are a few project management techniques that can avoid a lot of this. Mainly, don't submit a PR until you get a maintainer's approval on the purpose of the issue and the plan for the implementation. Time is valuable. When I want to convince maintainers to spend their time on my issues, I try to pitch in a way that requires the minimal time investment from them. Ask yes or no questions, provide multiple proposals with pros/cons, and look a past PRs that have landed so you can replicate the qualities of an acceptable PR. A few of these lessons were learned from successful OS projects with issue templates that gently guide contributors. Most of them were learned the hard way by misguided effort wasting a lot of peoples' time.


Steve, you have done a fantastic job. Don't let these issues get you down.

As an indication of that, I've been implementing an ownership/borrowing system for D. I expect to see some of the same issues you brought up. But for the people that want to use it correctly, it will produce the benefits. And that's what I care about.


Thanks Walter. I've been following along with your work, actually, though I don't know enough D these days to really understand it fully. Neat to see though!


I don't fully understand Rust, either, so we're even!

Don't worry about the haters. If I paid attention to them I never would have accomplished anything. People are always going to misuse a tool.

And some good news, the first stage of D's Ownership/Borrowing system was pulled today!

https://github.com/dlang/dmd/pull/10586


I used to have this mental model for my (few, meager) open source projects: "I'm making something really cool in my back yard. You can come help when I'm home."

Eventually it's mutated into, "I'm making something really cool in the local park. I'll be there on weekends!"

I had to bake in the perception of not "owning" my creation because yeah, at some point it needs to grow well beyond what I had the time/energy/capability for. I'm also very human, and very insecure about my competencies, and as the youngest of three brothers, am defensive by nature.

Now practically speaking, how do you accomplish that in the open source community? I wish I knew.


I think one part of this problem is that people need to mind their own business. If you're using an open source project and you find a bug then fine, report it. Hell, maybe even do a PR for a fix. But the you're not the maintainer's boss, they don't owe you a fix, they don't owe you anything. Now here's where it goes wrong, it's not your business to go and call someone out on social media. Not least because when you post on social media you should know that you're inviting a lot of strangers who have nothing to do with your problem to come and get angry. A decade ago maybe you could've feigned ignorance. Not today.

Equally, if you see someone complaining on social media about something that doesn't effect you, then mind your own business. But let's be clear - most people can't be trusted to do that.

Social media has taught everyone that they get to have an opinion about everything, and not just to have an opinion but to go and find the people involved and tell them. That is a completely broken culture- and its actively encouraged by places like reddit and twitter.


It brings up the question — as a developer, how can you best set boundaries on your customers so that you can have some degree of control over the toxicity of the culture that you're exposed to when interacting with them?


It's a good question. I'm involved in a large open source project that attracts some of this kind of attention. Because of the project's age, much of our infrastructure is old, which actually sort-of works to our advantage here. If you want to be a jerk to us, you need to go find our mailing lists and figure out how to send an email, or register a Bugzilla account and go file some troll bug. Much more effort than posting "You Suck" on GitHub or whatever. The barriers are insulating, which has pros and cons.

The other part that works well for me is disassociating your self from your project. Set strict hours for when you will work on the project, and don't work on it outside of them. Note that checking issue emails counts as work; remove your "work" email from your phone. I'm lucky enough to be a paid developer for the project, so I can clearly define my working hours as when I'm in the office, and ignore issues when I'm not at the office. But even for personal projects, there's no need to respond to issues within hours, or even days, if doing so is burning you out.

And the obvious answer that applies to anyone who creates anything online: Don't Read The Comments. In this case, that means Reddit. Reddit is a cesspool of uninformed users giving maximum visibility to whatever is most appealing to other uninformed users; not a good place to get useful feedback. Find spaces that are supportive and provide useful feedback, cultivate them, and spend your time there.


Hm, dunno, I am tangentially involved in a big open source project which almost never gets any negative comments, neither on Reddit nor here and the feedback is usually useful. Yes, the project uses mailing lists for the development, but there is almost no negativity in other parts of the community.

I have no idea why some projects gets toxic attackers while others are almost entirely spared. One thing which the project prioritizes is taking the time to explain to people why their ideas which look good on paper may actually be missguided.


Label and present your project clearly, both explicitly and implicitly, so that nobody could reasonably get the wrong impression about what level of development and support can be expected.


As a person, can you set these boundaries for other people in your surroundings? Not yourself. Neither is that the case for developers.

Individuals can't force societal behavior; it's a social/group issue.


Perhaps popular libs should have a community maintainer volunteer to buffer these kinds of issues if developers need some distance from the community.


It brings up the question — as a developer, how can you best set boundaries on your customers so that you can have some degree of control over the toxicity of the culture that you're exposed to when interacting with them?

Personally, I don't think you really can. I think the best thing to do from a developer/maintainer perspective is to identify toxic communities and do you're best to ignore them entirely. That's probably the best long-term approach from a mental health standpoint.

Especially when it comes to social media sites like Reddit, once a community turns hostile there really isn't anything you can do to turn it around.


No idea why this is being down-voted--it's a great answer. You can't make people act civilly, but you can shun them and vote with your feet.

Life is too short to deal with shitty people.


1. fafhrd91 might not be an English "native". A simple linguistic look at his comments (esp on gitter when he answers our questions) shows that he uses very short sentences. Perhaps that comes across as harsh to some people, but for the most I think it was fine. Perhaps many of those who were offended took this the wrong way (one can't keep apologising for their English).

2. Perhaps actix focused more on TechEmpower benchmarks (if you follow fafhrd91 on GH, you'd see the number of times he forks TE's repo, presumably submitting PRs). I think having a library that's #1 for many benchmarks attracts users, not all of which will be hobbyists working on toy projects. The concerns (some valid, most not) about unsafe were bound to be there.

3. The dismissal of `unsafe` alternatives was often a challenge (from the comments that I saw, especially before his first instance of walking away), which wasn't handled well by "us" the religious cult. I don't know why he came back after the first instance last year, but what many of us saw was the toxicity of Reddit when it came to actix. I think fafhrd91 asked for people to co-maintain last time, which did see an increase in contributors.

4. Part of us building a community will be many of us acknowledging that "Performance" is not the sole goal of every Rust project. There are sometimes people who will suggest a huge deviation in a project because of some micro-optimisation or because they want a feature which might not make sense for everyone else. So I hear what you're saying about the hardships of maintainership because things can go pretty wild if one tries to please everybody. Unsafe is also still 'young' in that more tooling around it will still be worked on over the years/decades. How will we know if we're being restrictive on a feature if we forbid it?

5. Reddit is toxic. People on Reddit are toxic. People are toxic. We are toxic.

A good principle for us to follow when we type things on the internet is to ask "would I say everything this way to a person if I was standing next to him/her/them"?

Good luck Nikolay, I wish you the best, we have learnt a lot from you on what's possible in our little community.


Rust is unique in that it attracts:

- Language theory enthusiasts, a famously pedantic group

- Systems programmers, a famously exclusionary group

- Unwashed masses of web developers who have never done either of the above before

Frankly I'm amazed it's been as civil as it has been


I wish I could upvote this many times.


One thing that isn't considered is that these "benchmarks" are a rat race to the bottom in code quality. You can't blame the author(s) from wanting to win this fictitious wall of fame. I don't know why exact numbers like "6.9987 million/sec" exist. There should be a saner way to run benchmarks, which in turn creates sanity among developers.

This viewpoint is, of course, unrelated to the community discussion here. I mean other languages have unsafe (or c's void *), but they don't appear to fight about it. I don't mean to say anything bad about Rust. But it seems to attract people who want the absolute best performance at any cost. IMHO. May be I am wrong. That may be something Rust people can try to change??


I think the simple version is that too many people don't understand how Open-Source works and that they have no right to tell a maintainer what he has to do.

If you are unhappy with the direction an Open-Source project is going, you can do two things:

1. Tell, in a civilized manner!

2. Fork, if you are willing to spend the resources to maintain such a project yourself

If you are unable to formulate your critique in a neutral way, then keep it to yourself (aka STFU). If a maintainer decides he doesn't want to follow your suggestions, you should be nice and stop. After all, you still have option two.

And if you are unwilling to spend the resources to maintain a fork, how dare you to tell someone who invests his time and shares his results, what he has to do.


A necessary step on the way to Maturity. On Schedule.

Congratulations, Rust!

I mean this with no trace of irony. With maturity comes being used in ways you didn't intend, and might not want, even with unwelcome publicity. Rust will sail through more of these, and more, and they will cease to shock. People who care will start to pay attention to modules' underpinnings, and start to keep track, and certify. It takes a lot of conscientious people caring to uphold that, but maturity brings them.

Rust is designed to a high standard, and it takes extra work and extra armor to maintain it, just as it is worth the extra effort to learn it. It aims to be worth that, so we cannot begrudge that without betraying its purpose.


To start: any personal attacks against the author are unacceptable. Anyone is free to write whatever the code in Rust they like, and it is wrong to attack them about it.

But .... I think it is showing that the premise of memory safety in Rust is working. Stuff that would go unnoticed in C and C++, is being identified and called out in Rust. Does it lead to drama, personal conflicts, etc.? Maybe. But from the perspective of the potential Rust user it's a proof that it `unsafe` keyword works, leads to higher scrutiny of potentially dangerous patterns and that the culture of other Rust users takes reliability, security and safety seriously.


> Anyone is free to write whatever the code in Rust they like

Let's take an extreme example: I write some program for common use and intentionally introduce a security hole or make it participate in bot-nets. And don't tell anyone about it. Am I "free to write it because I like it"? Well, in some sense, maybe, but it would also be something extremely problematic for me to do. Certainly everyone would scream bloody murder when it gets found out.

So, in a less extreme example, there's still some measure of responsibility of mapping out what and how you've vetted, and not making false claims.


I think if you're actively deploying malware that people will run, the case is pretty clear. And when you say "for common use", it sound like you know that it is or intend it to be distributed and run by many people.

What's less clear is security holes (which are not malware as such) or just "putting code out there" ("not in common use", although someone could come and pick it up and start using it). I would defend your right to write exploits and backdoors and bots and put them on github.

Simply making a security hole is IMHO OK unless you have intent to exploit it (or let someone who intends to exploit it know about it).

The difference, for me, is in writing versus deploying. And I'd consider it deploying if you intentionally post malware to a public repo you know people will run (without knowledge of having malware in it).

Contrast with building a trap (and maybe showing it to people) and stashing it in shed, versus building a trap and priming it and putting it in the woods where you know kids like to play. Not a watertight analogy, I guess making traps could be illegal just like making guns is in many countries. But you get the idea. I think you should be allowed to write malware or make combat knives or mantraps for fun but don't put them to their respective use.

Of course, going down this line of reasoning is a rabbit hole. If you build something on your yard (something that isn't illegal per se and has no intention to harm anyone) and it turns out to be dangerous and someone gets hurt, you might have to take responsibility (but it really depends on a lot of factors and would be decided on a case by case basis). I'm not sure I would like such reasoning to be applied to FLOSS projects that come with a warranty disclaimer and which can freely be audited by anyone who intends to use them for real. It's not like they hurt you just because you happened to stumble upon them.


What's all this BS drama? It's the original maintainers project, his way or the highway. Those who don't like his use of unsafe can take a hike, fork it, write their own etc.

If the project owner just wants to use Rust as a fancier C, just for a few niceties, and mostly code in unsafe, that's their decision to make.


""" But the point is, while Reddit is not official, and so not linked to by any official resources, it’s still a very large group of people, and so to suggest it’s “not the Rust community” in some way is both true and very not true. """

Perhaps one could call it "the unsafe Rust community." ;)


The word "community" comes with some troublesome implications. Just call it "the unsafe space (and proud of it)"


I understand maintaining open source is a lot of work and why someone might want to call it a day - but this is probably the least professional way someone could do it. People depend on this software. It is inconsiderate to just move it to private instead of taking the time to hand it off to someone else.

I'm 80% through building an API using actix-web. Time to reassess whether or not I should start over - wonder what my client will think if I bring that one up? I hope there is a community fork with enough momentum to keep the project alive.


You don't get to invoke professionalism, or lack thereof in regards to some individuals work they've made available for free.

Open source gives you access to source code to do with as you please. Storing your own copy is a good idea if it's something critical to your endeavors. The possibility of having to maintain anything of that nature yourself is always a risk.

Expecting, demanding, or begging for anything except what the author willingly, and happily takes upon themselves is exploitation, pure and simple.

If you think about it, trying to coerce an author/maintainer into doing anything they willingly and explicitly have commited to, is no different than employing bullying, group pressure, and other social/psycholgical manipulation techniques to get whatever outcome others deem useful to themselves.

Yes, something as trivial as complaining about the lack of response to a question can easily be seen as being abusive when there is no established relationship or expectation, no quid pro quo, or similar.

Getting free access to someones work is amazing, and nobody should ever have to face what so many maintainers have to face today in the form of unreasonable expectations and outright bullying.


Yes I do.

I used to lead a volunteer organization. I had many people depending on me for what I provided. Eventually, it became too much and I needed to step down.

A) I could have just left, let the organization collapse on itself, burnt every individual, organization and volunteer that depended on me - and just said, "doesn't matter was a volunteer organization."

B) I could have taken the time to ensure that there is a system in place such that the organization stays afloat, supporting the individuals, organizations, volunteers that are dependent upon it while it finds a new leader.

Either of those choices were mine to make - but I wouldn't be surprised at all if someone called me unprofessional if had picked A.


> You don't get to invoke professionalism, or lack thereof in regards to some individuals work they've made available for free.

Plenty of people do exactly that: they point to work that they've made available for free on their GitHub as proof that they have the required skills and attitudes for professional work. The former Actix-web maintainer also used to do this, via their LinkedIn page. You can't have your cake and eat it too.


Linking a hobby project isn't necessarily meant to say anything about attitude at work. At work, the expected attitude might very well be that you have to bend over for and pamper customers and deal with no end of bullshit. Or maybe the expectation is that you never interact with customers directly, everything goes through customer support / sales / executives (after being checked by legal). A hobby project, by contrast, is your kingdom, and you can reject bullshit and/or have fun or just never respond to tickets without a patch because it's your free time and your pet project.

If I link my stuff or show it to a prospective employer, it's meant to show them that I can code. Nothing more. If they want to read too much into it and dismiss me as unprofessional because they found a cat meme, Theo quote, or link to hello.jpg, it's their loss not mine. Fuck 'em. Kinda unprofessional of them.


If you don't understand how opensource works don't use it. If you paid nothing you are not a client and nobody owes you anything...


> People depend on this software

That is their own problem.

> I'm 80% through building an API using actix-web.

Feel free to pay someone to maintain it for you.


>I understand maintaining open source is a lot of work and why someone might want to call it a day - but this is probably the least professional way someone could do it.

Why would he be obliged to do it in a professional way? He's not being paid.


One question that you should be asking yourself with some urgent priority is: Can I even trust an application I've built with actix-web?

Ignoring the drama around it, there were some very serious security concerns with the liberal use of unsafe.


This all boils down to entitlement...

If you want a committee to answer for maintenance and philosophical debate or whatever, then fork and form an organisation for it... if not, leave people alone ffs, a one person authored project that got popular does not deserve this, abandonment is the only outcome.


> “Why Reddit is like this” is a whole other essay; I think it’s built into reddit’s structure itself.

Classic Eternal September.

Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new users mimicking other new users, and the culture shifting towards the platform's identity instead of retaining the sub's identity.

Generally, the type of person to post on Reddit frequently enough, has social cohesion problems that may preclude him from fulfilling his social needs through more healthy avenues, like real life. The same is true for the majority of people that post online frequently. Usually the pyschological profile that follows that point is one built on abrasiveness, distrust and aggression towards authority, an inability to adopt social manners and participate in social contract, low emotional intelligence, etc.

All of the aforementioned behaviors culminate into the toxicity and vitriol you usually see -- and as well why it's so prevalent.


It might not be just reddit though. The author's summary points to a volatile combination of elements in Rust itself:

1) [T]he Rust project saw Rust as more than just the language...

2) unsafe... is a really important part of Rust, but also a very dangerous one, hence the name.

If a project is considered to be not just a project, but something closer to a cause, people are going to defend their understanding of that cause fervently.

And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst.

People who perceive themselves to be defending a cause against danger are going to react very strongly, much more so than people who are criticizing an implementation choice on purely technical grounds.


> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst.

Is it really a value judgment? Coming from a formal PL background, I had just assumed that the "unsafe" keyword was referring to the PL concept of "safety", AKA "soundness", which has a specific technical definition, and not that it was necessarily a value judgment. In that context, "unsafe" just means "the compiler can't guarantee the behavior that it can normally guarantee".


You are correct.

That doesn't mean that people will incorrectly interpret it, though.


Ada’s language is probably clearer and less loaded: checked and unchecked.


Yeah, and interestingly, a lot of unsafe functions use "unchecked" in their names.

The issue was that by the time this was recognized, there was too much Rust code, and there was no clear alternative that people universally liked. This kind of conversation is the definition of bikeshedding. I submitted an RFC and it... didn't go well. (I think I picked "trustme" though.)


I don't think it's bikeshedding. It does seem to be contributing to the dogmatism I'm seeing from the Rust community here, and this community reaction is a huge problem for Rust. So it matters.


Bike shedding is a structural description, not a value judgement. It’s about technical complexity, and changing a keyword is one of the most minimally complex bits of language design.


My point isn't to argue over the definition of bike shedding. If the name of this keyword is contributing to this undesirable community outburst, then its name matters, and discussions about its name are important. That's all I'm saying. If that's what you originally meant, then we are on the same page :).


We are on the same page, yes.


Back then Rust did not have editions. I think it would be worth exploring renaming `unsafe` blocks to "sound", because when one writes `sound { ... }` what one is actually stating is that the code in the block has been proven sound.

The `unsafe` function type modifier can be left as unsafe, or renamed to unsound, since that what that is doing is stating that a particular function is not always sound to call.


Points well taken, but I think "unsafe" turns it into a value judgment, especially (as samatman says adjacent) since it isn't necessarily really unsafe.


It is unsafe. There are just multiple definitions of unsafe being used here. I agree that it's unfortunate that the meaning of the keyword is easy to misinterpret.

Given the background of the people who designed Rust, I don't think it's reasonable to just assume that the keyword "unsafe" has an implicit value judgment.


It absolutely includes value judgement. You just described a form of value judgement too. You're saying that predictable generated code behavior is preferred to unpredictable generated code behavior.


> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment.

`unsafe` is a PL term that refers to _soundness_. In Rust, an `unsafe { ... }` block is required to perform an `unsafe` operation, and it precisely means "The code in this block has been proven _sound_". If the code in the block turns out to be _unsound_, e.g., because the proof is incorrect, or non-existent, then the whole program is unsound, and there is nothing that can be said about the execution of such program (usually known as "the execution exhibits undefined behavior").

For example, the Rust compiler has a lint that requires you to write a soundness proof on every `unsafe { ... }` block, explaining why that is sound, and all changes to the compiler are gated on that.

In your own projects, you can obviously do whatever you want, but for any non-trivial amount of unsafe code, without a proof, you are basically just building castles in the air.


That's an interesting way too look at it. But that's not how it works in practice. Almost no one in industry is going to write proofs for their unsafe code. It didn't happen for C or C++ and it won't happen for Rust.


In Rust you at least know where to look at, whereas in C/C++ all code can be "unsafe". With that said, writing unsafe Rust is much easier to screw up than C/C++, since you have to uphold more invariants in unsafe Rust than in C to avoid UB (like never having two mutable references to the same thing at the same time. The very issue which was raised in the actix repository)


This is how it works in practice for the Rust compiler for the Rust standard library, and for a lot of foundational crates in crates.io. (Pretty much every well reviewed crate in cargo crate review either does this, or does not contain any unsafe code at all).

We also have tools that change for this for very large projects (e.g. cargo-geiger), and tools that help you test your proofs (e.g. cargo-miri). For some unsafe components, there are also proofs in Coq, and the proof systems for Rust unsafe code are making a lot of progress in both defining the rules that unsafe code must uphold in the unsafe-code-guidelines and the Rust spec, as well as in providing example proofs and a standard library of theorems that you can reuse for your own proofs.


I didn't say it no one will do it. I said almost no one. The Rust compiler is about as far from a normal project as can be. I would like to see this changed but really I have never even seen a proof requirement when looking at Rust jobs. Not even once.


> I would like to see this changed but really I have never even seen a proof requirement when looking at Rust jobs. Not even once.

?

Any B.Sc. in CS can do most of the unsafe proofs in a one liner. All crates I maintain require unsafe blocks to be commented with a proof, for most of them the proofs are trivial, and for all of them that weren't, the unsafe code was correct, and the correct one had a trivial proof.


It's fine that YOU do it. But how many unsafe blocks have a proof in the entire Rust ecosystem (read all crates). 5% maybe? I'm not sure what your point is that any B.Sc. in CS can do it.


Rust didn’t introduce this language, they adopted it. Memory safety has been called that as long as I’ve been programming.

Using the antonym of safe was a natural move, though with the benefit of hindsight, `danger` would have been a better keyword.

After all, good unsafe code isn’t unsafe! It is dangerous though, because it forgoes guarantees of memory and resource safety provided by the compiler.


> Generally, the type of person to post on Reddit frequently enough, has social cohesion problems that may preclude him from fulfilling his social needs through more healthy avenues, like real life.

You mean like making sweeping generalisations about a platform with millions of users?


Not to compare or anything. But I’m active at r/Golang and I find that the community is comparatively better there. I was shocked as to how would someone told anyone to never write a code again!

Maybe this because some members on Rust subreddit believes that they are more intellectual than others? It seems like a cultural thing, go people don’t bother to be seemed as smart or so and that’s possibly reduce the aggressive competition that naturally arise in places where intellect, high performance etc are very important metrics?


A forum being large doesn't have to lead to a loss of cultural identity.

My favourite counter-example is /r/AskHistorians. Over a million members (16x larger than 60k) and it has some of the highest quality posting and discussion I've seen anywhere on the internet. I think it serves as a prime example of how a well a forum can scale, if done properly, so long as there are strict rules and moderators.


>distrust and aggression towards authority

Not an exclusive characteristic of a reddit user, there are many different levels and types of authority. Perhaps the aggression towards all authority, or weighted to certain personalities of authority rather than the ones in the background, especially the ones that don't really matter i.e. internet forum moderators

I agree with your general point that reddit fills a social vacuum in people's lives, like most social media does for others in different ways. Validation and expression etc.

Personally I think think that's why society in general has become generally more toxic, everyone is really telling it straight to others but not being honest with themselves.


Psh, do you even know what time the narwhal bacons? /s

I think Reddit is interesting because its design is more resistant to Eternal September than other communities. See the trend of creating r/TrueX when r/X gets Septembered.

Unfortunately, this hits diminishing returns when more and more obscure subreddits need to be created. Tons of oddly specific niche subreddits have popped up and completely gone to shit in a flash. I think we're nearly due for the next migration (maybe a federated alternative?).


Person posting on online forum says people posting on online forums have social problems.

If that statement is true, you (and me, and everyone else here) have those same issues, surely?


> the [psychological] profile ... is one built on abrasiveness, distrust and aggression towards authority,

Hey hey hey, "aggression towards authority" is not a psychological trait, but at most and pattern of action. Also, I disagree with your implicit maligning distrust of authority without generally distrust of others.

> ... and participate in social contract,

The claim of the existence of a "social contract" is part of the self-justification of authoritarian aspects of social structures in capitalist democracies.


A community grows and eventually reaches the point where users cannot recognize who they're interacting with nearly every time, where the submission queue is trailing down too fast for any single reader to process. When that happens, it can no longer function as a cohesive community. It becomes about as personal as a magazine about the very same topic. Furthermore, the incentives to post change due to the higher potential for "karma" (and posts therefore become more like clickbait), and the barrier for the admissibility of submissions becomes lower as a result of the "expert" or "enthusiast" segment of the population becoming a tiny minority.

In my experience, these larger communities typically grow less tolerant of antisocial behavior, most likely due to acceleration of the process known as "dogpiling". Trolls get more exposure, and better reactions, in small-to-medium communities.

It's still conjecture, but I think I prefer my hypothesis.


> Armchair psychology, coupled with pure distilled condescension.

Please edit the name-calling out of your comments on HN, as the site guidelines ask: https://news.ycombinator.com/newsguidelines.html

Your comment would be fine without the first sentence.


The edit window for that post is sadly over, but I'll be more careful in the future.


If you want to edit it out, I've reopened the comment for editing.


The above was from personal experience and observation from having been a part of many online communities -- pre-dating reddit -- in all ways including: here-and-there member, first-hand maintainer and manager, and antisocial member causing a ruckus.

Armchair psychology? No, I've made many friends and acquaintances, both online and in real life. The ones that bubble around posting online heavily, have developed antisocial tendencies that were reinforced through social exclusion. A self-fulfilling prophecy. I know this, because I know those people well and because I was there at one point in my life as well.

Neither is it condescension. Perhaps I may have been in-exact and may have offended some that do post online very regularly, but there must be a distinction between what they consider "regularly" and what I consider "heavily." Heavily, in my observation, is someone that puts aside a significant amount of time, usually involuntarily, to do nothing but interact with online communities for the sole purpose of social interaction. No value judgements were made either, but those characteristics are common among the aforementioned group.

I won't address your hypothesis, because I'm not here to argue.


>Armchair psychology? No, I've made many friends and acquaintances, both online and in real life. The ones that bubble around posting online heavily, have developed antisocial tendencies that were reinforced through social exclusion. A self-fulfilling prophecy. I know this, because I know those people well and because I was there at one point in my life as well.

This would still qualify as anecdotal data, and thus armchair psychology. Now, it works perfectly valid as a hypothesis and can be rigorously tested and determined if data reject or supports (fails to reject) it. But without peer reviewed research, that last step hasn't happened.

It also sounds good. Makes sense. Fits our notion of common sense of how humans works. The problem is that psychology is filled with examples of where these kinds of intuitions are wrong.


You got me there.

My connotation of armchair psychology is more informal and doesn't match the more rigorous, APA definition.

I'll make one note: the psychological profile I wrote of, is based on first-hand experience, as well as pieces of mental notes recovered from internet-addiction and FBI profiling papers.


If I understand correctly, your anecdotal evidence is what makes this not "armchair psychology"?


What's wrong with simply sharing personal observations based on the decades of related personal experience? Anyone who has some training in science has learned to always be looking for patterns.


Theres nothing wrong with it. Calling someone an armchair psychologist is an anti social behavior.


Nothing. I simply don't value this kind of loaded and facile analysis very much.


that is armchair psychology.


A lot of guesswork and generalization, right there.


Well said- sometimes i feel that HN is basically a practice for people on how to reply to toxic emails from coworker. "I should have framed it like this"



That situation is a little different for a number of reasons, but the broad strokes are the same.

Sam tweeted at me recently about this situation: https://twitter.com/sstephenson/status/1167856878673694728


I think this has less to do with Rust and more to do with people using the Web as a tool to be unkind to what they think are unhuman pixels.

Sometimes I think the Web was a mistake, and that none of us are ready for the scale that it brings.


Fork. That's the answer. It's not friendly or nice or kind or whatever, but that's the answer. Rust and its ecosystem of people and their work are not magical; there are and will be difficult people and yes, sometimes the correct answer is to shun them by forking the work and leaving the problem children behind. It is impossible to avoid this when building a complete language paradigm involving so many people.

Nikokay isn't the problem. His indifference to soundness concerns is inevitable; Rust pragmatically doesn't preclude reckless programming and that's a good thing except that some people will, in fact, be reckless. The actual problem is the naive expectation that Nikokay's indifference and recklessness can somehow be fixed by the 'community.' It clearly can't. The 'community' needs to sack up and fork stuff until it's happy with the work.


This is really bad. Actix Web is such an awesome framework.

Reddit has become such a toxic place since they optimized the platform to make money.

Why don't those idiots just fork Actix Web and make a "no unsafe" version of it? Instead of harassing the author, who has devoted so much of his time and talent to building this great piece of software?


I think Github (and other services that host OS software) needs something like "thank you box", that's just alongside Issues. Even if I am not able to contribute to some project I use and like (mostly because I don't have enough technical knowledge yet) very often I would like to - at least - say how much grateful I am for what this person is doing. There is some need for positive energy or gratitude, as we - who are happy - won't usually post an Issue saying that we are happy, everything is working fine. It seems then that there are only issues, and people who are angry or unhappy seem to be the loudest. How else, we who are grateful but silent users - can help maintainers and contributor to know that there is large or even larger amount of people who are happy and even amazed by their work?


GitHub has a donation feature, which is up to the maintainer to enable for their project. Otherwise, it seems to me that a stream of positive comments would get old quickly.


> It’s unfortunate that a well-known project had soundness issues. It’s unfortunate that the maintainer wasn’t receptive to fixing them. At the same time, I’ve been there: being a maintainer is tough. It’s also unfortunate that there’s this style of response, and kind, and volume. It is true that the situation was dangerous. But did it have to be handled this way? You have to understand a lot of nuance here to even know the main points of the story. One version of this story that will certainly be told is “The Rust community says they’re nice but they will harass you if you use unsafe wrong.” Is that what we want? I, for one, do not. If you’re a part of Rust, you gotta ask yourself: are you happy with this outcome? How did your actions (or lack thereof) contribute to it? Could you have done something better?


IMO, the most telling point of this is when the author rejected a security patch because it was not creative enough. He was more of an artist than an engineer.

What was the patch? It was very strait forward, simple, uncreative change, intention was just to remove unsafe not to fix existing code. I believe software development is one of the most creative work we do, and creativity is part of why we love software development, why it is fun. Especially if you combine it with real world projects constraints. “creative constrains” could be source of very interesting solutions. Being on the edge of your abilities is super fun. So uncreative change felt boring https://github.com/actix/actix-web


> He was more of an artist than an engineer.

Assuming this is true: What's the problem with that?


The project was not promoted as that for a long time. That "view" on what the project was only came yesterday, when yet another security hole was identified and a patch was prepared.

The impact of that patch would have likely caused actix to no longer be at the top of the techempower benchmarks.


"I assumed that over time, the community would grow, and we’d encounter problems.

Today is the first day where I say to myself, okay, has that happened?"

I think it depends on how you define community. I used to think Rust was going to be able to go mainstream. Now I'm wondering if it isn't niche. In other words, infrastructure needs code too, but all of the code "at the edge" (ie. applications that interact with users) may not be the perfect place for Rust. And I feel like that's where the majority of code will be written. So, maybe to produce metrics on this I would start with "where is the primary activity", and discover within that niche whether or not Rust has positive trajectory in terms of "market share" of that category of applications.


If your language promises some kind of new feature (e.g. "safety") but offers a back door you could drive a truck through (e.g. 'unsafe'), then ensuring that back door is used appropriately and in good taste comes down to culture policing, which, as we've learned in other areas, is something the internet does not handle well.

As the Rust community grows, how can it ensure that people use 'unsafe' tastefully? Well, in general, it can't. But maybe Cargo could exercise some editorial control, and delist (or flag) packages that don't follow the "community standards". I'm not saying this would be a good idea, it's a tradeoff. But you can't force open source volunteers to write code in a way you like.


I would prefer to see a positive badge for "this project doesn't directly use unsafe" or similar, which maintainers can choose to put in their README in the same way that they currently put build-status, test-status and other badges. The actual badge state is produced by tooling (a CI system) so it stays up to date and you can follow a link to a (tooling generated) report with more info, so it's relatively easy to verify.

Maintainers that don't care don't have to use the badge (even if their project does in fact avoid unsafe), but the choice to include the badge acts as an implicit signal of intent. When I see a crate with green CI status badges (or in this case a green safety badge) that's a signal I can use to help judge whether I want to depend on the crate.

No one needs to be flagged or called out if they're not interested in that aspect of maintainership.

I think the hard part is that actual quality is a spectrum and no-unsafe-at-all isn't necessarily the best goal for many crates. So ideally the badge would show some more granular safety score. But scoring effectively is difficult, and the so is correctly interpreting a heuristic score.


Oh, and apparently there is something vaguely along these lines already:

https://github.com/rust-secure-code/safety-dance/


I haven't seen the phrase "contempt culture" before, and I want to thank Steve for bringing it to my attention in this article.

Thanks Steve. :)


You're welcome; I think it's one of the most important concepts for programming communities to understand. Felt like a revelation when I read it, as someone who was previously very contempt-ful and regrets it.


For me this says more about the drawback of easy and automatic dependency management. When I write C code, adding dependencies is often a huge pain in the ass. You need to figure out how it's packaged, how it's build. Should I build a custom version or just use $distro's pre-packaged version? How do I tell my Makefile/configure/CMakeLists where to find the headers and libraries?

This is generally a bad thing. It leads to NIH, to poor portability, to difficult integration in other dev environments etc... But it does mean that you carefully consider every dependency that you must use. The quality of the packaging is often an indication of the quality of the code too, a well polished build system inspires confidence, a crappy buggy bespoke shell script less so.

Meanwhile take this example: I've re-started working on a PlayStation emulator a few weeks ago. I haven't reached the point where I need to display images or output sound, it's pure algorithmic code with no I/O so far. That's 0 dependencies.

But then I wanted to add some basic logging infrastructure to be able to do 'warn!("this thing shouldn't happen")' or 'debug!("this register has value {:x}", val")'. I could just use println! but, hey, adding dependencies is super easy and I'll end up with more flexible and expressive code, so let's do that instead. So I add these two lines to my Cargo.toml (note the simple in simple_logger):

    [dependencies]
    log = "0.4"
    simple_logger = "1.3.0"
And as easy as that I have a proper logging framework available. Amazing. Except that when I then run `cargo build` I see the following:

    Compiling autocfg v0.1.7
    Compiling libc v0.2.66
    Compiling log v0.4.8
    Compiling lazy_static v1.4.0
    Compiling cfg-if v0.1.10
    Compiling num-traits v0.2.10
    Compiling num-integer v0.1.41
    Compiling atty v0.2.13
    Compiling time v0.1.42
    Compiling colored v1.9.0
    Compiling chrono v0.4.10
    Compiling simple_logger v1.3.0
That's 12 dependencies for a glorified println! implementation. Did I vet this code? Of course not. It would be faster to just reimplement it myself. Do I trust that somebody went to the trouble of doing it for me? Not really. I just cross my fingers and hope for the best. It's wonderfully convenient but I'd be very wary of trusting any security-critical project with a dependency graph like that, and it's quite paradoxical since Rust is all about safety.

Oh and beyond that Reddit is a terrible place that manages to be the worst of 4chan and the worst of Facebook in one convenient package and should be avoided at all costs, but we already knew that.


What I see: unsafe should be used sparingly, and it turns out there is a crowd-sourced safe-guard to ensure it. Don't cross the threshold.

Be warned: unsafe causes both bugs and anxiety - excessive use will lead to at least one biting you.


Help me out here is actix-web some sort of software that is integral to Rust?

If not ... I get the idea he wasn't really welcoming of the changes but at the same time. It's his code man.

I came from the world of networking and etc and the world of programming has a great deal of personal preferences / hypothetical problems / "we don't do that at my workplace" stuff pushed under the guise of technically correct ... sort of technical bullying.

Under that sometimes there's little room for mistakes / other points of view, other working styles, and etc... and it's really horrible.


Integral? No. Used in production, by companies? Yes. Outwardly visible? Absolutely, due to Techempower.

Rust will survive without actix, but losing it is a setback for Rust in the web space.


If it's LGPL can't someone just put up a new fork of it and people transition to that?


It is MIT/Apache2, and yes, in theory they can.


Sure, but someone needs to take that on.


Elm packages are not allowed to use JavaScript, period. I personally thought this very restrictive and unnecessary. But after seeing this, maybe Elm/Evan is doing it right after all.


Let me point out that even if you think that this project is "not rust-y enough" by violating basic premises of the Rust way, it would still be useful as it outperforms all those C based project with at least as many guarantees than the C versions.

To me the important part is that we as programmers start advertising our intent. If the intent was to learn how Rust works, then we should write that in the description. Instead we write things like "very fast and lightweight framework". To many people fast and lightweight is good enough. Many other people would also like dependability and sustainability. So please, just put a little label on your github project.

All my open source projects, for example, are exploratory. None of them was meant to be used in production unless you tested rigorously that it would work, and that is on you then. There is nothing wrong with that, I think, as long as you communicate it up front.

People are just importing open source libraries with flashy sounding descriptions left and right, and then they find out those were unfinished and crash all the time, or the author ignores bug reports, or will not maintain it anymore, or thinks it's ok to switch the APIs around on you, breaking your ability to upgrade without reworking your application.

Again, there is nothing wrong with that. Just be honest about it up front.


I generally believe people should be polite.

But when you open source a project, you are opening yourself up to criticism and critique of your work. You are opening yourself up to that in basically any form the internet wants to take it, and sometimes that really can be shitty.

We have a very promising project making use of a language that has gained popularity largely based on marketing around memory safety, and then that project has unnecessary and flawed use of something that undermines the messaging around rust. This is a risk for Rust - a promising and popular project in a popular space that undermines some of the core rust messaging is a PR problem for the language. The maintainer not being receptive to contributions to resolve this difference is a problem. The maintainer not being receptive to contributions that fix SECURITY ISSUES is a MAJOR problem.

Open source maintainers are, of course, volunteers. I don't think we should hold them responsible for the fact that there are bugs in their code, or even security flaws. People aren't perfect, and no one should be expected to be, especially when contributing something to the open source community. But we SHOULD hold them responsible for not fixing security issues. It's irresponsible to release something to the public that you know puts them at risk.

So is it fair for people to be upset in this situation? I think so. I also think their reaction should be a polite one - but it's totally fair for people to push someone to take responsibility for code they've introduced to the world that has security vulnerabilities in it.


Exactly! Everyone should demand a full cash refund for all that they paid for the maintenance of that piece of software.


This is a common snarky retort when any discussion happens with open source software, but it doesn't add anything to the discussion.

There is a cost to using software that goes beyond money exchanging hands. The maintainer has no legal obligation to do anything, but acting as if someone having an issue with software having security vulnerabilities is someone being entitled is a childish reduction of the interactions in play here, especially when people are taking the time to write code that resolves the issue.


Why do you think it adds no value?

It at least makes it very clear to those who have not paid for the maintenance that their position is silly if they make demands of the maintainer. It is his project and he does as he pleases. Why is that difficult to see?

One could perhaps persuade him to accept a patch but like any endeavour where you need something from another person, either you offer them something in exchange (which they value enough) or ask nicely and see how it goes.

In either case, it might still fail. In that case, one can of course try and do the same with _someone else_ who might be more receptive. This is possible with free/open-source software.

What you consider a "snarky retort" is just the same thing said in a different tone.


I disagree, actually. There are no expectations of anyone that releases their code under most licenses. You get to use it as is, and if you want to change it, you submit a patch. Totally up to them if they want to take it or not.

If the current maintainer isn't doing what you, or "the community" wants, you fork and make the changes you want to see, and maybe eventually work with a group of people.

Maintainers are under absolutely zero obligation to the people who choose to use the code, unless they've specified as such in the license or some other contract. It's the only thing that lets FOSS software be a thing in the first place.


I'm not arguing they are under any legal obligation, but holding people responsible for something doesn't have to be a legal thing.

I feel that any open source software that I have released I have a moral obligation to fix any security issues, or if I am unable to for some reason, clearly stating that they exist. It is irresponsible to leave your software available with a known security issue.


A word to the wise. Don't read the reddit thread around this. A lovely little snippet:

> > it's up to you as a developer to vet your dependencies

> This is effectively impossible on an individual level, and it's something that absolutely needs to be a community-level effort.

Don't hire this person... Dependencies are absolutely, FULL STOP, your responsibility. YOU are the one making the money NOT the maintainer.


I would feel sad for the creator but after reading more about this it feels like they were clearly acting with malicious intentions, such as removing a bug report from months ago because someone mentioned it in an article, or being rude to contributors.

I do not believe that anyone is entitled to free features/bugfixes/etc on foss projects but apparently this is not what happened in this case.


This is the reason why Rust will never go mainstream. People say "You can get the same performance and features as C++ with unsafe!", but as happens in every language such hacks gets ostracized by the community and therefore basically unusable. So instead we just write our code in C++ which is unsafe by default so nobody complains.


Nothing whatsoever was "ostracized" in this case. A fix was provided for code that could cause UB in some cases, the former maintainer rejected the fix as "boring" and denied that a problem existed. This could have happened just as easily in C or C++ code.


How is this a story?

If people don't want to use an unsafe library, don't. If their patches aren't getting merged, clone it.

If reddit is being meany-heads, don't login.

I really don't understand what the point of this post is. It's arguable whether there's a problem, and if you take the author's point that this is a problem, no solution is offered.


The free software and open source implicit contract is that as a user you’re free to fork and redistribute. That’s it. You cannot force others to accept your patches, or to behave in the way you want. Just fork and create a safe-and-community-friendly version of the project if that’s what you want.


Some of us in the Rust community wrote a letter of support for the actix maintainer. In case anyone else thinks what happened sucks and wanted to show support.

https://github.com/actix-support/letter


There's a tendency for masses of people to eagerly follow strongly-opinionated people. I think such qualities are a big warning sign, especially if they're dramatic, engage in all-or-nothing thinking, unconvinced by evidence and/or put their ego / being "right" ahead of everything and everyone else. Furthermore, there's a tendency for people to get emotionally-attached to "their baby/pet" project and reject anything that doesn't fit with their delusions of grandeur. IMHO, assertive, honest, respectful and professional folks who lead projects tend to attract better quality contributions and sustain development long-term than jerk dictators for life who may ragequit at any time if they don't get their way.


This problem wouldn't exist if the people who wanted changes were willing to write a big enough check. If you get your code for free, you shouldn't expect anything of the person giving it to you. They have already given you more than you are entitled to.


You can submit patches upstream all day long, but you can't browbeat the maintainer into applying them if they don't really care about it. It's their project at the end of the day.

Likewise, it's just as annoying when you submit a PR on some random thing because you see a legitimate bug or unhandled case and the maintainer starts demanding you do more free work for them to do 100% they way they would have done it. Just say "thank you", accept it, and make those superficial edits.

The price point here is free. This is essentially a gift economy. Just because some random strangers on the internet have an interest in the same few bits of code, doesn't mean there is an obligation to do free work or twist someone's arm.


The article mostly consider both side and the main point is to flourish open source community, which is highly appreciable.

I think, as an outsider, both side had its wrongs and corrects, the author could consider changing unsafe code and the community could be at least civil.

As a personal opinion, i can say that we have to consider the fact that the authors of open source software are mostly doing it for hobby or fun. And if we ever want to keep open source alive and magnificent, we should be very civil and and at least thankful for the programmer and their time.

The only way out i see that could solve the issue was to fork the project and do the desired changes there. I dont know why they did not do that when it got to that point.


> I dont know why they did not do that when it got to that point.

I think most people kept hoping they weren't at that point, and could actually move forward without forking.


I'm just a js dev with a whole lotta love for the web. I know enough to respect the hell out of Rust. I'd just like to offer my best wishes to the Rust community, and put a call for folks to be more civil on places like reddit, etc.

In closing, here's a nice little gem from the OP author's final blog post on his old blog[0]:

> if there’s one thing I’ve learned from writing software, it’s to blog about error messages.

Cheers.

[0] http://blog.steveklabnik.com/posts/2015-07-05-ember-data--ds...


> if there’s one thing I’ve learned from writing software, it’s to blog about error messages.

I hope I'm not the only one who just realized that "A Sad Day for Rust" is also an example of "[blogging] about error messages" and appreciated that statement even more.


Hopefully someone with a clone of the project can spin off a "reactix" fork.

I don't think the negativity was necessary, that said, if it wasn't a significant impact to performance but did potentially improve safety, many of the patches should probably have been brought in.

Personally, I've been more drawn to the likes of Rocket and Yew. The former for the server because I really like the interfaces and usability. The latter, I haven't done much with, but think it's pretty cool and a relatively small starting point for a WebAssembly based UI experience, compared to say Blazor.


That's my experience too, particularly lately. Reddit/HN both is and isn't the Rust community, but everyone there is a disaster for all the reasons the wider programming world is a disaster.


As a maintainer of a medium-ly popular library that I also use for work I can say that I love getting (quality) bug reports since these are bugs I didn't know I had. OTOH pull requests for the bugs I'm not as excited about. I wrote my library with a strong vision for the api and how everything fits together. Many times the pr submitter isn't aware of the vision nor has taken the time to understand how everything fits together. I'll read and understand the submitted code but many times I'll end up writing the fix myself.


It is indeed a very sad day. Personally I enjoyed being a small part of this community and amazed how welcoming and constructive it was. But yeah as we grow, we are bound to face this.


The guy has absolutely 0 obligation towards anyone. There was 0 money exchanged, there were 0 contracts signed, he's free to take his ball home.

Hope the people who caused this are happy now.


Sorry to add yet another top-level thread, but my take on this is that, while it is correct that unsafe-blocks are a central and contributing factor to this incident, it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks. As long as Rust both has such an easy way to circumvent the type system, and a desire to supplant C and C++ on the basis of code quality and safety, there will be ready fuel and kindling for these sorts of social conflicts.


> it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks

But they do need those. Even C# has unsafe blocks, and Java has sun.misc.unsafe. It's a rather boring feature actually, the interesting part is what you can assert about safe code, and at what cost.


What is your alternate proposal?


The proposal that has the most concrete chance of succeeding is probably to formalize some of Miri's behaviors as auditors [0], explicit syntactic annotations which indicate a type/function's willingness to have its source code inspected and have facts proven about its behavior.

In terms of quality engineering, the "page of assembly" strategy is the one that I think has the most merit. Write out enough machine-level code to boot the machine and provide an environment for some higher-level language. This should take about a page. Rinse and repeat until the higher-level language is high-level enough for comfort. VPRI supposedly had made this technique work for them. This would cleave Rust into two or more languages, though, and I gather that a big selling point of the language is the ability to compromise and allow many different safety perspectives into a single codebase.

I'm not Miyazaki; I can't just tell you that unsafe-blocks were a mistake. But clearly and obviously, to anybody watching who has considered design and implementation of programming languages, they were a mistake. Further, they're the same mistake as Safe Haskell. We keep making this mistake, as a community of designers and theorists, and we need to do better.

[0] http://www.erights.org/elang/kernel/auditors/


I don't know the minute details of the case so sorry but this comes to mind:

The double edged sword of open-source: We can't cooperate with one another if we don't know how to behave and deal with other people. Emotion can never have the final say. Because emotion is raw, uncontrolled, knows no boundaries, doesn't know right from wrong. Especially if it is selfish emotion. Those that act like this are bound to harm themselves and others;


> So, someone takes a peek under the covers, and it turns out actix-web is using a lot of unsafe code. That’s not inherently a problem. The problem is, a lot of that unsafe code is not actually needed. This is where things start to go wrong.

Can anyone link to a discussion in which the actix-web maintainer explains his position at a technical level?

The article leaves me baffled at why the maintainer was so unreceptive to concerns about the use of unsafe.


A lot has been already said about this unfortunate situation. I would like to mention that pinning all this on brigading by reddit is very disingenuous. There was a lot of hate directed towards actix and Nicolay on twitter by some very prominent members of Rust community also who were discussing removing actix from the awesome-rust list so people stop using it. Let's not represent a community by their worst members.


I wonder if there is a better way to manage vitriol for Open source maintainers. Why should a maintainer take brunt of other communities responses for issues like this compared to what they've contributed.

There just has to be a a way to summarize the noise such that it is indicative of pushback. There has to be a way to have a discussion without attacking each other when the disagreement is only on a detail.


This is what happens when you get attached to a language, a library and especially an idea of how things could be different.

You inevitably get disappointed. Good. Now you can evaluate and see if a different outcome is even theoretically possible.

When you hope, you lose :) It doesn't mean you cease hoping, it just means you don't do it so strongly. It's too much. You know it's too much, so just let go :)


> Its author also works at Microsoft, and suggested that Microsoft is using actix-web in production. This was really exciting to people. This was the second project using Rust at Microsoft, and so this seemed really fantastic.

Well if the project isn't FOSS anymore I can't see Microsoft continuing to use it, which makes me question the accuracy of this statement in the first place.


I liked actix and did a little free time unfinished project in it, when it was updated frequently. Ultimately I lacked the energy to read anew the tutorial and update my code. Still, I liked to use it and think it probably became better over the time I did not use it.

I don't know what kind of licence actix-web had. Seems to have been some open source license and not a free software license, according to the "postmortem" readme file, where the author says: "I am done with open source."

What stops anyone from using a fork to develop further? Did the license not permit that?

If somehow that was not permitted or not possible, because no one created the fork before it was moved to "private repos", then I think the author did something quite childish , taking away the possibility for others to continue developing the software, just because he is fed up with enduring the criticism. "You don't like how I run the project? Meh, I'm going to take it all away from you!" (That's how it sounds, when you move a repo to private after and because of criticism.) Ideally any author, who works on an open source project, knows, that they give up some control over the code and would not act this way.

I do not say, that the shit storms were justified or good in terms of their social aspect. However, if all of this managed to make actix-web safer, then at least that aspect was a good result.


I have to wonder -- is this a real problem in the Rust community? The essay makes it sound like it's just the usual Reddit toxicity.


That’s what I was trying to get at with the “is /r/rust part of the community or not” bit. Inside official spaces, none of this happened. If you don’t read Reddit, it follow certain folks on twitter, you wouldn’t have seen any of this.


There's a false expectation that if a package or project is open source then the maintainer should put in free labor to keep it up-to-date. If you don't like something then fork it and make it yours. Nobody is entitled to anything. If I were the package maintainer I'd most likely do the same if I were getting that kind of response from the community.


It's easy to get any bug fix you want: pay for them.

If you think loading your expectations on to an unpaid volunteer and then harassing them over it will work out, hopefully this moment is a good learning experience for you.

(Unfortunately, I can see from reading the comments that not everyone is getting it.)

Perhaps someone should create an OSS contributor agreement where contributors explicitly agree to work long hours, for free, in perpetuity, prioritizing issues based on reddit heat, and see how many developers agree to those conditions. Those are the expectations that appear to have driven this developer to quit their project.

BTW, for those that don't know: acting on bug reports and accepting pull requests is often a lot of work in its own right. Bug reports are often vague, incomplete, contain incorrect assertions and assumption, lack clear steps to reproduce or even a clear description of what happened vs what was expected. It takes time a effort to clarify these things. Even then you may need to, e.g., build an environment to reproduce or correct the issue. Changes from developers that aren't highly experienced with the project typically have gaps, new bugs, misunderstand requirements, don't build, ignore style conventions, lack unit tests, and have various other issue that have to be ironed out before the change can be accepted. It's all a lot of work.


I imagine GitHub could make a reasonable amount of money if they implemented a bounty system, taking a little off the top for each bounty.

Each issue could have a donate button. The bounty would be split to the authors that contributed, with some remainder left for unfinished work (documentation, unit tests, etc).

To settle how the bounty is split for multiple authors, they could go through an anonymous round of "bids" to propose splits, with the bounty locked until they agreed. Maybe the maintainer/reporter able to settle disagreements by choosing a split ratio that lain somewhere between the range of those bid on.


I want to preface my comment with "I agree with you"

However, in this case patches and reproductions were submitted and rejected as "boring". Whether the author really meant to use the word "boring" is neither here nor there, the result was that the fix was ignored, even though that's how open source works!

I've watched from the sidelines with no skin in the game (I use Rocket) and my conclusion from all of this is that the maintainer should have created an actix committee or group of maintainers to help shield from the inevitable bugs and issues that crop up. If the OG author wanted to step back to take a break from all of this, then fine, the rest of the group can continue to churn and work.

The original article that called out the behavior also called out other incredibly popular crates, like reqwests, for their underlying HTTP stack, yet there's not a shitstorm about those libraries. The obvious difference that I can see is the maintainer response to said criticisms.

EDIT: I also want to make clear that I hated the comment about never writing rust again. I'm not condoning that behavior at all


I think you're still heaping unwarrented expectations on the developer.

E.g, "...that's how open source works!"

That's your opinion, but what obligates the developer to adhere to this?

If the question is, was this a professionally run OSS project I would say, certainly not, and I assume almost everyone would agree. But so what? Why should a maintainer be expected to run an OSS project to a certain level of responsiveness or spin up a governance mechanism if they can't do it on their own?

> The obvious difference that I can see is the maintainer response to said criticisms.

I would suggest that reddit mobs are almost entirely capricious, random, and irrational.


If my comment implied that there was some sort of expectation then I think there was a miscommunication. There's no obligation for anyone to do anything, ever, but that's a pretty useless metric to mark against IMO.

Was this a professional project? Absolutely not. But was this a personal project? I would also say categorically "no", since it wasn't scoped under his personal github profile until recently. I'm very saddened to see something that could have been solely community maintained be revoked instead of there existing a potential mitigation plan in place (for example in the form of a foundation or Org) for situations like this, especially since this has happened twice before and it's sadly caused burnout for the main developer. Again, no obligation to do this but why can't I say "man, that's true that he could follow these actions but that's also shitty" at the same time?


the amplification of reasonable criticism into harassment campaigns is a major dynamic in the last few years, and it generally ends up pushing people completely offline instead of like, allowing them to improve.

It's in open source but it's affecting everyone who posts their work online, which is to say, anyone doing anything that's publicly visible, anywhere.


What is the issue here actually?

Fork the project and un-unsafe it.


This situation is the sad and absurd result of two processes going on in the Rust community.

The first is that the Rust community on Reddit is in a feedback loop of groupthink and outrage, making it into a powerful vector for harassment. The maintainer of the actix project had a particularly terrible experience of escalating harassment from the users of this subreddit, and its extremely sad. This has caused a lot of grief for the maintainer of actix and prevented real (but far overblown) code issues from being fixed in a productive way.

But I think Steve undersells the absurdity of the unsafe anxiety. Some Rust commmunity members are conflating two wildly different scenarios together. The first is a library exposing an API which, if used in an unlikely and contrived way, could result in a program using that library containing undefined behavior. Then, since that program has undefined behavior, it could contain a memory bug. If that were the case, someone could potentially exploit that bug to attack a user of that program. You'll notice this is a series of conditional statements - its a funnel of decreasing probability.

So yes, library APIs which can allow UB in safe code - even unlikely and contrived safe code - must be fixed. The goal of Rust is that safe APIs can never cause UB. But people should have a proportionate understanding of the risk profile of these bugs (again: a programmer using this API in an unlikely way could create a program with a bug that could potentially be exploitable). This is a miniscule increase in the risk of another heartbleed, it is not the same thing as heartbleed.

The spark that lit the kindling of the toxic Reddit community was a blog post by Shnatsel, a member of the RustSec team. This blog post didn't get attention here, but I want to take a moment to look at how ridiculously it frames things by examining its analysis of a different project: reqwest (sort of the most standard HTTP client library in Rust).

Here's the link: https://medium.com/@shnatsel/smoke-testing-rust-http-clients...

The fuzz test, which is what the library is about, found no security issues. It found some hangs in 6% of cases and Shnatsel traces them to a known deadlock issue. This is a great result.

But Shnatsel spends most of this talking about a custom hashmap implemented in the http library, which the RustSec group did a security audit of just a few months ago. That security audit found only two issues, both UB that would result from a contrived use of a minor library API (they are linked in the blog post, but not explained). These two issues were fixed, and the fix released, by the maintainers of the http crate in 10 days.

This is an incredible success! The security audit of a foundational library found two minor issues which were promptly fixed, and the fuzz confirms that the entire stack on top of it seems to contain no memory issues. Wonderful result, but how does Shnatsel frame this?

> First things first: it didn’t segfault! I am actually impressed because I had really low expectations going into this.

Come on! The blog post is full of these kinds of snide zingers which are totally unfounded in the face of the actual evidence presented. When you have someone writing in this disingenuous, meanspirited way about open source maintainers and then putting this in front of a groupthinking rage machine community like Reddit, of course you're going to get harassment. This behavior is totally unacceptable, and it's very sad to see it promoted in the Rust community.


That article from Shnatsel is really stunning, just everything about is negative and snarky- to a comical point. His avatar is a cartoon pony doing a facepalm! I find it kind of funny that the author of this has singled out reddit for criticism when seemingly prominent members of the Rust community are perfectly willing to be so openly toxic.


Being negative and snarky about crappy, hacked-together code that might cause security issues all over the place is not a bad thing. Yes, most of the snark there is about 'http' crate with its weird custom implementation of basic data structures.


'Crappy' and 'Hacked-together' are literally just insults, they don't carry real technical criticism and frankly they just continue to undermine the credibility of the author. The fact is that 'crappy' code is the most used http crate by far. Clearly everyone in the rust community must be an idiot to be using it. I'm sure the author went off and wrote a totally safe replacement for it. See, now we all get to be dicks to each other rather than actually working to fix stuff.


The first step in working to fix stuff is being aware of the issues - there's nothing "insulting" about that. Unsafe blocks without any clearly-stated rationale and safety analysis is quite subpar quality. Just because it's common and a "most used crate" does not make it OK, leftpad was widely used too.


_It's not what you say but how you say it_

With all due respect, you are not the universal arbiter of "crappy"-ness and "hacked-together"-ness, nor is anybody else. My guess is that you have concerns about the library, and you are absolutely within your right to say so. Your concerns may even have significant substance to them; or perhaps there is additional perspective that could change your mind.

Unfortunately, presenting your view and judgement as a statement of objective fact not only shuts down potentially valid counter-argumentation, but it's also inflammatory/insultory because it misrepresents your agency in the situation, and diminishes the efforts/personhood of those who contributed to the library.

It's understandable that you might want to use such phrasing as short-hand from time to time, but saying it out loud, especially in a public venue is regrettably demonstrative of a lack of self-awareness. It drowns out your message regardless of its merit, and pushes other people away. It's a reductive way of thinking, and it does everybody (including yourself) a disservice.

In the words of Groucho Marx "I don't want to belong to any club that would have me as a member."

We could all choose be sour and jaded, fighting over scraps in a futile search for self-worth –OR– we could each take it upon ourselves to be the standard-bearers of what was, and hopefully will remain, a warm and inviting place for meritorious debate. I choose the latter.


It is absolutely a bad thing to be negative and snarky. It sews resentment within the community and taints potentially valid points. One can express legitimate concerns and be heard without putting oneself on a pedestal or diminishing the self-worth of others. We as a community must take responsibility for fostering a merit-based discourse, and reject pettiness and snark.


What sews resentment is being repeatedly dismissive of serious problems, as we're seeing with this hackish use of 'unsafe' features - that's an attitude that diminishes the self-worth of others, if I ever saw any. If anything, a bit of irony and snark can be helpful in underlining a sharp, pointed critique, while de-escalating the sorts of petty, antagonizing attitudes that we've seen in this case.


I think I understand what you are getting at. Though there may be disagreement on exactly where the lines should be drawn, I think it’s important to underscore the value of patience on the part of everyone in the conversation. The rust community has a position on these things, but perhaps it isn’t as well-documented or refined as it could be.

No doubt, having to contend with this issue is frustrating for all parties. I think it’s important however to help people feel heard and respected even if we don’t agree with them. One of the burdens as a pillar of the community is the necessity to rise above that frustration (articulating it in an emotionally intelligent manner when necessary) – to focus on educating, and hearing constructive criticism.

That said, candidly it’s not helpful to talk about using snark as a means of being heard. It’s like saying “I’ll put down my weapons after you put down yours”

Let’s not bury the lede here: people are coming to Rust because they see, and are excited by its potential. They are passionate about making the language better. I think we should hear them, search for patience, and disagree without being disagreeable. We will go a LOT further together through collaboration than we can through divisive rhetoric.


Didn't the Rust stdlib just gain a high-performance hash map recently? Is there a real case for using a custom implementation in reqwest? I could see Shnatsel getting a bit frustrated wrt. that choice.


The reason the `http` crate has a "bespoke hashmap implementation" is not because "performance", it's because _HTTP headers call for different behavior than `std::collections::HashMap`_. Some of the differences in behavior include:

- The map needs to be a multimap.

- Insertion order needs to be preserved.

While `std::collections::HashMap` is an excellent HashMap, it is not a good fit for HTTP headers.


High performance relative to what? In the highest performance code, you will always want your own data structures, ones specialized for your particular use case. Generic facilities will never be quite as good. A general purpose language must support this kind of specialization.


This is something JavaScript does better than Rust. I like the JS community because it's way more sympathetic on average. They have lots of code quality issues to solve in some of the hardest ways... But people are working on that, and I think they will succeed eventually, if they haven't already fixed much with npm audit.


There is a Code of Conduct. Question: is there a Code of Maintainership.

A document describing the principles the maintainer tries to uphold?


The "unsafe" keyword should probably just be called "unchecked," otherwise it is a bit of a misnomer.


I think 'unchecked' would be a bit of a misnomer; code inside of unsafe blocks is still checked by the compiler for many things. The borrow checker is even on IIRC.


We always look at number of stars or installs of libraries before deciding to put them in a production project. It'd be cool if there was a "percent unsafe" badge that was commonly used for Rust repos. If folks started paying attention to it it'd be harder for unsafe libraries to become popular.


People being people. I disagree with both the author’s code choices and his treatment. I imagine most feel the same. Rust will be fine. The lessons learned about choosing dependencies wisely and taking responsibility for those choices will be scarce.

Running software is always more of a performance than an institution.


I think the Rust compiler should write as its final log message "Resulting binary contains x bytes of unsafe code" (or something similar). That way, people are constantly reminded that their code depends on unsafe code, and they can try to reduce that with visible results.


Given the "unsafe guts" most of Rust stdlib contains, there's going to be some baseline of unsafe code that every project has. I could thus see this confusing new authors and users - you could have a project with zero unsafe lines that will still report a relatively large unsafe surface.

Besides, perhaps this would reinforce the notion that unsafe is - by its very nature - a bad thing. To quote Klabnik:

> it turns out actix-web is using a lot of unsafe code. That’s not inherently a problem. The problem is, a lot of that unsafe code is not actually needed.

If the code were actually needed, then there's no benefit in printing this metric - it just makes a project that is using the feature perfectly correctly look bad.


You can use cargo-geiger to figure out whether a binary is going to depend on problematic unsafe code.


A community this large can easily deal with a loss of technical talent. It cannot easily deal with toxicity. Therefore, it seems like a good thing actix and its developer are leaving.

Also, a fascinating Trumpian "both sides have good people" -defense play.


I think there might be some cultural aspects at play here too as far as communication style.


This is a sad day for open-source at large, as well. I think it's very important to keep having conversations about proper stewardship of open-source projects, until we eventually reach new models that are more fair/reasonable.


I'm not sure I agree at all with the author about the air about the Rust community. Rust is an amazing language but the community has always been totalitarian trash. I try to keep as far away as possible from them as I can.


I have no knowledge of actix-web. But just starred at the insane high throughput achieved in the world most thorough benchmark test. Just horrible to read about what the author had to go through. But fully understand him.


Simple solution: Ignore Reddit


"It’s unfortunate that a well-known project had soundness issues. It’s unfortunate that the maintainer wasn’t receptive to fixing them."

What should you expect in this case? What is the best possible response?


I don't know what a single thing in this post is referring to, so I'd just like to point out the surreal nature of reading someone very passionate about a bunch of words you've never heard of.


1. I find the assumption that Rust code is safe a bit overly optimistic. If you're writing network-facing code, security is always an issue to some extent, even if mitigated by language guard-rails.

2. The actix framework author supposedly did the following things at once:

   2.1 Wrote code somewhat carelessly
   2.2 Wrote and maintained his code alone
   2.3 Claimed his code was "safe" - in that mythical complete sense I mentioned above
this combination is a recipe for disaster, and he was warned (albeit in a possibly-non-friendly-way). Thus, while the public outroar is probably excessive - security bugs do happen - he is to some extent getting what's coming to him.

Caveat: I'm a C++ person and am not familiar with the Rust ecosystem.


If I was the maintainer and someone offered a patch that didn't alter the properties of my code, but improved it, I'd be more then glad to accept it.

Unnecessary drama because of inflated egos.


I want to add two (maybe very) controversial comments.

1). It should be considered RUDE to contact a solo maintainer in any way relating to the project (email, issue, pull request, etc.). You should ALWAYS fork the project and use the forked project on your own terms.

Most people write their projects, on a whim, on a Saturday, for a bit of fun. They do not want to be shackled to a hobby for the rest of their lives.

2). Opening an issue and opening a pull request are IDENTICAL requests for effort.

Think I'm wrong? How many people were so incensed by this renegade maintainer that they FORKED the repo?? Why didn't people FLOCK to the safer fork? Why did people still care about the original repo??? The answer to those questions underlie the fundamental problem of open source. No one wants to do the work. People want to work on what they're passionate about. But they don't want the responsibility of ANOTHER FULL TIME JOB.

An issue is a request to write "native" code. A pull is a request to maintain "foreign" code. I have never had a large, successful open source project. To date, I've had one repo with ONE issue and ONE pull request. Both required more effort than I ever wanted to give.

I have stopped opening issues completely. If a project is maintained by one person, you will never hear from me. Large projects with paid maintainers will receive issues because I believe it the only appropriate time to do so.

---

Here is a simple flow chart for contributing to a solo maintainer's open source project.

1. A problem has been discovered.

2a. I do not know how to solve the problem. -> Move on. Don't reach out to the maintainer in any way.

2b. I can write a fix for this problem but I don't want to maintain this project in its totality. -> Move on. Don't reach out to the maintainer in any way.

2c. I can write a fix for this problem and I want to maintain this project in its totality. -> Fork it. Don't reach out to the maintainer in any way.


A maintainer that you can't reach out to is no maintainer at all. If that's the behavior they expect from others, they should clearly state that the project is not being maintained, and be open to others taking up that effort instead.


> they should clearly state that the project is not being maintained

A project by a solo, unpaid author should be presumed unmaintained.


I cannot help but to think there are deep parallels between software projects and any good old company. Dealing with a group of people around an "idea" is far from easy.


This whole affair makes the Clojure way of relying on libraries instead of frameworks really appealling to me. Frameworks are not fork-friendly.


The Rust community is very, very toxic. They fight internally, but externally, they take over any thread about anything and make it about Rust.


Was here to post something along this line. The only place in which I'm (hopefully) in contact with the Rust community is here. What do I see all the time?

- "rewrite it in Rust" kind of posts on a lot of threads

- upvoting Rust mildly or not interesting projects just because there are written in Rust

- down voting every comment that even slightly criticize Rust (this comment will be gray when you'll read it) or remind that code safety exists in VM language for decades


I am _very_ productive in GC languages. I use F# and C# all the time, and the code runs fast, everywhere. And I don't have to worry about memory, and don't have to learn a wacky syntax and wait for hours for a "borrow checker" to complete its static analysis.


> and wait for hours for a "borrow checker" to complete its static analysis.

The borrow checker is actually fast, the part where you wait for hours is the code generation. There is nowadays also a "cargo check" command which stops before the code generation, which you can use when you want only to see if it would compile without errors (without waiting for it to actually compile).


Just because maintainer quit doesn't mean the project is dead. It can be forked and fixed.


I’m starting to really wish reddit wasn’t the default community forum for everything.


Dudes, why don't you just fork the repo and run with it. License looks good.

It doesn't matter if code is full of secbugs, author doesn't like patches, or whatever. Code is open source. You can't make it look like your vision. Fork it.

Of course, no one in the mob appears to have had the wherewithal to do that.


Man... Wouldn't it be great if this same attitude often seen in users of open source software was had by regular people toward civil liberties? Like where people just pile hate on the codifiers day in and day out, because they are owed their entitlements by birthright.


That's kinda how politics works. Sorry to have to tell you :(


You didn't understand what I wrote. To put it into simpler terms: Over time, people demand less and less about their civil liberties, whereas with open source projects, people demand more and more.


that's not even remotely true.


I hope this makes it to the top so ngate can write about it...


First the “rust being a moral programming language” and now this - I’ve never seen a community stain a language so poorly as the rust people. Wow! And I was there when Zed Shaw Cale’s rails a ghetto.


Why is this getting so much drama?


This is my from-the-outside-looking-in take on the matter.

It seems to me that there's a clash of expectations/worldviews, both happening in this thread, and in the wider portions of the interwebz involved in the kerfluffle this article is about.

A comment[1] from ddevault states two things:

> 1. YOU are responsible for your dependencies.

> 2. Open source participants are volunteers and owe you nothing.

The above is true. But there's another aspect here, that of cultural norms, implied goals and the expectations derived therefrom.

By my observation of mailing lists, hacker's blogs, my own attempts at contributing to various projects, and other things, there's come to be a set of expectations of the authors, maintainers, contributors, and even to some degree, users, of FOSS projects. These expectations are not set in stone; they can be shaped by the statements and actions of the maintainer(s), implicit or explicit, or the lack thereof. But there is nonetheless a default set of expectations. A set of social norms, if you will.

One of the expectations I've observed, and discovered I myself had absorbed through cultural osmosis, is thus: A maintainer should make clear what a project's goals are, and earnestly consider patches/pull-requests offered in good faith support of a project's explicit or implicit goals. They should communicate clearly technical facts, concerns, and considerations when discussing or debating an offered patch. Said discussion should be focused only around the technical facts as they relate to the goals of the project and the offered patch. And if the patch is rejected, the maintainer should clearly communicate why. Said communication could be a long essay expounding on the technical trade-offs the project has had to make, or a simple link to a FAQ entry covering why such-and-such common patch type will never be accepted. (In that latter case, presumably the earnest consideration of that patch type had happened sometime in the past).

A related norm, one tying back in to ddevault's post, is the contributor's end of that exchange. One offering a patch should accept a rejection with grace. A contributor can and should be willing to discuss and debate and try to persuade a maintainer how the offered patch actually does align with the project's goals after all. But he should do so only with technical facts and logical argument, not fallacies, emotional manipulation, name calling, threats, or other such juvenile BS. To persist and pester after a final decision has been made is a violation of that norm. Thus, it is as equally gauche for a contributor to tell a maintainer to die in a fire after a rejection as it is for a maintainer to state he doesn't accept patches from people who voted for the Labor party in 2017.

None of the above invalidates ddevault's assertions. However, IMO, social norms serve as a sort of oil on the machinery of the human interaction inevitable in collaborative projects. A person rightly gets upset when those social norms are violated. But, there are right and wrong ways to respond.

From what I've seen of this kerfluffle so far, it is a violation of those norms which led to this mess.

Recall what I said about a project's goals, above. Rust's explicit goals of memory safety, thread safety, etc, IMO carry with them an implicit goal of making for secure programs, by making it easier to avoid the kind of mistakes that cause programs to become insecure. I'm not a rustacean, but it seems to me that at least part of the wider Rust community is working on making that implicit goal an explicit one. And so, by building your project with Rust, that goal of a secure implementation transitively becomes one of your project's goals, at least implicitly. If it's not, you had better explicitly state otherwise. And if you do, I don't think you should be particularly surprised when some push back.

And so we come to the violation of social norms. I can't find any before-the-kerfluffle articulation of actix-web being a for-fun project. So, actix-web was seen as having the goal of being sound and secure, by virtue of being implemented in Rust. And here was Nikolay's virst violation: failing to make clear the goals of the project. If after that first instance of 'unresponsive maintaner', as steveklabnik puts it, Nikolay had made clear his main goals were being fast as possible and winning the benchmarks, that soundness and security were non-goals, and he had firmly and politely held his ground on that, I think the kerfluffle could have ended there. If he'd made those goals explicit then, then other users would have been able to take a look at the project, and see that all that Unsafe code was probably not something Nikolay cared about changing, and so know they need not offer patches for it.

But since that wasn't done, we come to the next violation: not earnestly considering those patches offered in good faith -- or at least seeming to. Because of the impedance mismatch between Nikolay's actual goals and those seeming goals of actix-web, he seemed to not take seriously those patches offered.

As I said above, there's a right way and a wrong way to respond to such things. And sadly, the response by some was to violate the contributor's end of the bargain: accepting a patch rejection with grace. By responding with out-of-line remarks like "please stop using Rust", the quality of the discourse degrades, and shit rapidly gets toxic.

I don't think it would have been a violation of norms to call out all the use of Unsafe, and the various ways it was unsound, or even to advocate that others should not use actix-web, so long doing so stayed fact-based and did so somewhere other than the actix-web bug-tracker. As far as I can tell, the smoke test of HTTP clients did that. I haven't dug deep into the Reddit thread, but if there was personal attacks on Nikolay, I'd not be surprised.

What have I learned from this, despite not being part of the Rust community? Well, if nothing else, it highlights the importance of clear communication. In any future projects, I will need to make what my goals (and non-goals) are as clear as possible. I will also need be willing to clarify things when there seems to be an impedance mismatch between my goals for a project, and what a contributor thinks they are or should be. And I'm going to have to develop a thick skin and the ability to de-escalate, because some people are going to respond with perceived rudeness from me with deliberate rudeness of their own.

Perhaps that's a naive take on it. I welcome suggestions on how to improve it.

1. https://news.ycombinator.com/item?id=22075346


I deleted the issue - I regret that. I'm deleting the project.


Oof magoof


I agree with what another person has said on github- the rust community on reddit is incredibly toxic. The last time such a thing happened, there were losers who made personal attacks on Nikolay. Then Nikolay showed up in comments being angry that he had helped that particular loser only a few days back.

Its easy to create blog posts and comments about RIIR, its not easy to actually write code.

If anybody actually wants to fix this issue and prevent it from happening again, I'd start by instantly banning /r/rust users for 3 days anytime they do a circlejerk.


Blaming 86k people for the actions of a few is toxic.


Open source frees us from the tyranny of the maintainer, but only if people stop raging at maintainers and start forking shit, and other people stop raging at maintainers and start voting with their feet to other forks.

Who the fuck cares if the package maintainer does or doesn't do x,y, or z.

Either make the patch, submit it, and launch your fork when it gets rejected, or look for such forks. Anything else is just masterbation.

On another note: it seems like this entire mess was based around a bunch of peoples inability to see that "can" != "does". The fact that it can be vulnerable because it doesn't do something that makes being vulnerable impossible does not in any way mean that it is in fact vulnerable.

This is like the time somebody came to our repo with a bunch of pep8 linter warnings and treated them like high severity issues.

"good practice" != "must do".


I am disgusted by the cultural phenomenon of making sarcastic call-out comments on twitter/etc., with an eye towards building up enough community outrage to force an issue.

There are people who forget that open-source does not entitle you to anything (read the fucking license).

Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without someone trying to stir up a lynch mob. It sickens me the lack of balance between the work done by the maintainers, and the expectations of random users.


> read the fucking license

> It sickens me

> I am disgusted

Almost sounds like you're... outraged? Perhaps trying to build up community outrage?


>no call to action

>not naming any individuals

>talking about a cultural phenomenon, not a specific incident

>no intent to force anyone to change


I agree. I think this is an extension of the general social media mob culture that we have. I see it as one of the major problems of our day, because most people in most situations just bow to the mob, which just makes it worse. I don’t know how we solve that, either.


> Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without someone trying to stir up a lynch mob. It sickens me the lack of balance between the work done by the maintainers, and the expectations of random users.

Sure they are. There's a number of projects out there with a massive caveat on the front page that says "Not for production use". They are then more than free to close issues with comments like "Hey I'm researching a new refcell implementation, thanks for finding this, but I'm more interested in speed than safety at this point."

Actix did not put up a disclaimer, and in a lot of cases, either closed issues/patches without comment, or with a somewhat demeaning comment. It was not just published as a fast and safe production ready web framework, it was promoted as such, so the author should expect patches in that vein.

There were multiple bad actors involved here, but it stems from a maintainer who took issue with anyone finding problems in his code.


Sorry, it doesn’t work that way, come on github isn’t intended for production unless specified otherwise. The default assumption is “This is just some code I don’t own”. Even repos that do make some claim of support or quality should be treated with suspicion. The onus is on the person using the Open source project to do due diligence.


But it's not just "code on github". It has the very professional-looking https://actix.rs/ and so on.


I too am disgusted by this phenomenon. The key thing to remember is that outrage has power only because you let it have power. Twitter snark isn't the real world. Neither is Reddit outrage. If you totally ignore these hives and their angry buzzing, you'll have greater peace of mind and lose nothing.


I don't disagree, but it's also the fact that for some of us the option to learn to ignore people can be a decade long struggle, if possible at all. It's not that I don't think you get that, you probably do. I just needed to tell a bit of my perspective to someone, and that happened to be you, and the rest of HN.

My brain is, well, lets say "broken" in this respect.

I could have open sourced a fair bit of code over the decades, but I haven't, largely because the option of entirely ignoring people isn't really available for me at this time. While I obviously try to work to get to a point where it is an option, I don't know if I ever truly will be able to publish my own projects.

While I now won't get bothered much by people calling me an idiot, or being asses in general, the self righteous expectations people apply to open source maintainers still just breaks my brain.

People freely give out their labour of love and sweat, and other people have the gall to hold them to higher standards than we hold most of society?

It's just too obvious. As soon as the balance of power shifts, a sizeable fraction of the population becomes the tyrants of their "peers". Can't deal with that, unfortunately.


All discussion I saw about the issue was quite civilized.

https://old.reddit.com/r/rust/comments/epzukc/actix_web_repo...

https://old.reddit.com/r/rust/comments/epoloy/ive_smoketeste...

I get that people hate Reddit around here, but pushing this on them as vitriol by the Rust community there is wholly unfair. The impression I've gotten is that the developer of actix used unsafe too much, made no attempt to inform users that his framework was thus not safe to use (to the level expected of a Rust project), and rejected plenty of PR's where these issues would've been fixed, while being belligerent about continuing to write unsafe code.

https://cdn.discordapp.com/attachments/648807492931026953/66...

He'd even started deleting comments and entire issues just for pointing out unsafe code. And it seems like he's had the archives deleted, since the archived pages which used to exist are no longer accessible (I didn't even know that was possible?).

http://web.archive.org/web/20200117043715/https://github.com...

Frankly, after years of seeing people defend C/C++ projects because "well, just get better", I think it's a good thing that security-consciousness is at a point where developers are being rightly criticized for playing fast and loose with security. There are always complaints about how we have no idea what kind of code being used on NPM or other package systems. But make some effort to improve it and now they're the bad guys? Oh, come on. You can't have it both ways.

And as somebody else has already pointed out, plenty of other projects also had PR's regarding safety issues, as linked by the original article which tested all these projects. The actix author is the only one who rejected them, and he's the only one facing complaints.


Found a working copy of the original Github issue: https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...

Aside from maybe the second to last comment, I don't see anything here that deserved deletion.


> Can we reject the idea of a BDFL? Can we include as many people as possible? Can we be welcoming to folks who historically have not had great representation in open source? Can we reject contempt culture? Can we be inclusive of beginners?

I feel like in any language, beginners are more than encourage to write things in said language. Yet when working on language internals, you need to be more careful. Reading the Firefox programming guide on what's allowed/not-allowed in the C/C++ codebase is pretty eye-opening[1]. Have there been issues with core Rust developers not being kind or following their CoC? The author doesn't really include examples or explore this line.

As far as Reddit: I stopped using it the moment one of their CEOs altered someone's comments during the election and was not asked to step down. That CEO is still there. Reddit had their warrant canary removed years before that. All their original values are pretty much gone and they've gone on a community banning spree over the past few years. It's also no longer open source. I'm fine with any community rejecting this as any kind of official communication platform, but no one is stopping enthusiasts or hobbyists from using /r/rust

If actix-web has unsafe code and the authors are not accepting patches, and someone feels passionately about it, they could create a saftix-web fork, include all the patches, and maybe even develop it independently or pull in changes from upstream.

It sounds like things went down terribly, and that's sad. Was it just Reddit people, or core devs? I agree it doesn't help to attribute blame, but the author doesn't dive into where the problem might have started and what could have been done differently. I wish this had some more explicit examples of how the community screwed up, the things they did right, the things that could have been better. But then again, that could lead to call-out culture BS. I feel this article is missing some depth, but it's also something that would have probably washed over without the author going out of the way to write this piece. I dunno. /shrug

[1]: https://firefox-source-docs.mozilla.org/tools/lint/coding-st...


> I stopped using it the moment one of their CEOs altered someone's comments during the election and was not asked to step down. That CEO is still there.

That was not a CEO but a founder, AIUI. Can't really fire them or ask them to step down, they literally own the place.


Open source is fundamentally wrong and in need of a correction. It's an exploitative labor practice.

There's a better way. It's coming.


What's wrong? There was a popular but dangerously broken library, and the maintainer didn't want to fix it, and so it shut down. Everyone is better off now. The code is still free for anyone who thinks they can fix it. It was a bit messy along the way because people get emotional about bad security, and people on the Internet have freedom to make comments you are free to ignore. This is an open source success story.


I wonder if some devs will get fired/some startup bankrupt, for using such a risky dependency?


[flagged]


HN has not entered its Eternal September quite yet.

Perhaps you'll be better received in another forum, but this is unwelcome here.


I don't know man, the emotion unveiled by your comment shows a deep anxiety in the C community that Rust is going to replace you.


Actually most of us would welcome a "better C", it was just obvious from the outset rust wasn't it. Rust with unsafe - as dangerous as C in the hands of a amateur, as comprehensible as poorly written machine code.


You are just not used to Rust's syntax. In my experience, Rust is much more readable than C, but that's probably because I actually wrote Rust code that is used in production while I only have a theoretical understanding of C.

It's only a matter of experience with the language.

And as the blog post mentioned, `unsafe` is actually necessary to interface with other languages, including C. Without that there's no way it would be able to catch on. Sure, it's a footgun, but it's probably the only one and, again, necessary. It's all about developer responsibility. Maybe to improve the situation we could make it so that when you add a crate cargo explicitly warns you about how many `unsafe`s there are.


So much for the C killer huh


> Rust has a necessary feature, unsafe, that allows you to escape Rust’s guarantees. This is a really important part of Rust, but also a very dangerous one, hence the name. But one of the things that’s important about it is that, since unsafe means “I have checked this code, and it upholds all of the guarantees the compiler cannot check,” you can build a safe interface with unsafe guts.

This blew my mind. I had no idea this was happening! I really hope Rust continues to evolve. Still no idea why JetBrains wont adopt it officially like they did Go.


JetBrains does sponsor the development of the Rust plugin, IIRC.


Nothing "sad" here. FUD article. By 2 reasons framework was not good enough for usage anywhere else than benchmarks: 1) careless attitude to security issues; 2) too fragile behaviour of author - when I know author can completely ruin some dependency of my project just because somebody on Reddit was too rude, I will never pick such dependency. Internet is a wild place, Reddit is a wild place, deal with it. Creating issues for so many users of your project just because somebody wrote offensive comment on Reddit - I can't even understand such childish behaviour.


I dont know what people expected from him, he was working 12 hour days already. If they didn't like it then they could just try to help him out instead of tearing down the work he was doing. Did he not accept PR's because he didn't have time to get to them all? Either way, writing an article further isolating him for all his work isn't going to make the situation better.


That's okay, Rust should never be used for web anyway.

I don't like the idea of Rust, C, C++, or Assembly for directly web-facing services. Any non-GC language should be a non-starter. There are literally (uncountably?) infinite ways you can have memory errors in a native program. The consequences of any of these can be devastating because absolutely anyone can access your endpoint. Notice the asymmetry: One small, unnoticeable error can lead to devastation. Like running across of a field of sparse landmines, eventually you will get destroyed.


The set of all computer programs is countable, so I don't think there can be uncountably many ways to have memory errors.


That seems right. Memory errored programs are a subset of all computer programs.

The possible runtime states of a program (expanding every branch/subroutine recursively over all threads) is uncomputable. (Otherwise we would have a solution to the halting problem and be able to correctly free memory at compile time.) I'm not sure if that's the same as being uncountably infinite. It's probably a different concept.


Uncomputable is indeed a totally different concept from uncountably infinite.


Depends on how you define web. IOT should be done in low level languages. but yeah I agree that a REST server is better of in something like GO, C#, or JAVA.


IOT is generally less of a target. I'm more talking about http endpoints to be consumed by browsers anywhere in the world. That makes the whole world your adversary.


> IOT is generally less of a target.

Lol. That's the thing about IOT - the 'S' is for security, right?


I actually think the "code of conduct" culture that Rust embodies exacerbates this kind of drama. Ironically, it creates a more unsafe environment where everyone feels anxious and judged by the CoC Police. Under the CoC, I am entitled to a wonderful experience, and if I don't get it, the culture has failed in its commitment to me.


This kind of drama has happened many, many, many times, in many places where there's no code of conduct.


I have literally never felt "judged by the CoC police" in any project that has one. I have no idea why you would ever feel that way. Pretty much every CoC says "do not be a raging asshole". I am fully capable of not being a raging asshole, and if I slip up and am, I would be happy to be told off for it.


There have been very public instances of it happening, though the truth is people would have been just as assholish with or without one. Toxic people don't need to hide behind a CoC to be toxic, and they aren't especially likely to obey one either.


That's hardly what happened, though.


I noticed a whiff of this early on and just moved on. I deal with enough politics at work. At play, I want to do fun tech and that alone.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: