Hacker News new | past | comments | ask | show | jobs | submit login
A Sad Day for Rust (steveklabnik.com)
1243 points by pjmlp 33 days ago | hide | past | web | 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.


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.


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.


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


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


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


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


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


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


Applications are open for YC Summer 2020

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

Search: