A Sad Day for Rust
words.steveklabnik.com
words.steveklabnik.com
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.
Hopefully gotham or rocket gets around to updating.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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".
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”.
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.)
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.
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.
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.
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.
You'd think that basic human interaction dictates not being rude to eachother, but internet history says otherwise.
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.
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.
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.
So in that case you wouldn’t use any software written in plain C, right?
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.
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.
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.
or when you really audit the code, find a problem, submit a patch and then the author dismisses your patch as "boring"
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
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.
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
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
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.
> 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.
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.
"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.
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.
Thus, the disclaimer in the license cannot double as a disclaimer in the social arena.
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.
Think of MIT’s warranty disclaimer as the “free tier” of service.
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 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.)
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.
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?
Yes. If you want a secure version of Linux, pay a vendor like Red Hat who’s willing to provide those assurances.
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.
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.
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".
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.
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.
If there was a big user community that wanted different things, fork and have a seperate maintainer structure. Why drama?
I want people to point out bugs in my code, so both my code and me as a developer can improve.
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]
I would never touch the product of someone who found bug reports annoying.
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.)
> "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."
Just about any thread on HN regarding any aspect of systemd or Google will have comments which are much more vitriolic.
Otherwise if that event is far far over the line I wonder what out of the blue insults or death threats qualify as.
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?
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.
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.
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.
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...
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.
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.
There's no way for me to know for sure, but it seems as though Klabnik was exaggerating here.
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."
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.
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.)
It's not insurmountable. It just takes a little bit of elbow grease and self-discipline ;)
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.
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.
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.
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 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.
> Open source is not some backyard game anymore. It
> involves companies and their commitment in form of
> infrastructure and participation.
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.
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 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.
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.
> 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?
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.
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 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.
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.
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.
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?
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.
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.
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.
I'd consider it to be social norms. It certainly isn't entitlement.
[0] https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a5...
[1] https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...
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 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.
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.
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.
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.
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.
But you will have a very hard time merging two refactoring branches that both touch internal data structures.
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.
Shouldn't that be Larry McVoy? BitKeeper predated GNU Arch by a couple years.
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.
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.
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.
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"?
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.
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.
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.
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?
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.
Just because there’s a patch that fixes the issue doesn’t mean the maintainer has to merge that patch.
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).
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.
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.
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.
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.
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.
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.
If you want to be able to place expectations on the author, pay them and get a contract.
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.
If he'd said "I'll write my own solution" rather than calling it boring, his response wouldn't have been a problem.
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.
Working in the context of Security does not grant you a blank check to be an asshole.
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).
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.
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.
https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop...
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.
(.Net is probably not unique in this regard, but it's what I'm familiar with.)
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.
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.
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 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.
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.
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.
It's "bear the brunt".
And what exactly are you contributing to this project author to match your demands of them immediately fixing flaws that are found?
Ok.
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.
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.
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.
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.
- 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".
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.
We can think about these larger, emergent structures like programming language and open source communities independently of the individuals that comprise them.
Our entire ecosystem that we have built (for better or for worse) by using these libraries as the foundations for countless projects necessitates that when a community is willing to give their time to improve a library that you maintain, the minimum that is to be expected is that you treat sincere contributions respectfully and not dismiss them out of hand.
It's unfortunate that the maintainer has stepped down entirely instead of changing how they are interacting with the community, but purely from a security standpoint I would rather a slower (but more secure and receptive) library take it's place than have a very popular library maintained by someone who doesn't seem to care about the overall code quality of the library they are a steward of.
If there is one trend that has been consistent in the development world it has been that there are always people willing to keep iterating on libraries to get better and better implementations.
If people come to rely on your project, you are not more responsible.
I've been in the business since before open source was much of anything but a dream, and frankly, I wish a lot of more people would shutter their projects when/if they face these kinds of unreasonable expectations.
The vitriol and entitlement towards maintainers is sickening at times, and unless those affected close the doors, I'm afraid it'll continue to be ignored, and maintainers will continue to burn out.
Burn out is a real problem in the industry, and we really shouldn't help burn people out when it comes to work they do for free!
Unsafe isn’t something you live without, you just avoid unless there’s a decent reason. Setting aside actix-web, the community has this really annoying obsession with not using unsafe anywhere. You’re not replacing decades of computing overnight, though, and it’s not the end of the world if it’s there sometimes.
It often feels like newcomers and zealots preaching the unsafe issue, too. I have to wonder if the Rust docs couldn’t better point out “the goal is less unsafes, but unsafes will exist - this is fine”. I know it kind of explains this already, but perhaps being more blunt?
Actix-web even with a few unsafe is still more sound than most frameworks IMO. I’ll take slightly better with crazy good performance over not better at all with no guarantees.
Also, look, the other problem is Reddit: I’m starting to think larger projects should squat their name there and redirect to better discussion places. I comment on Reddit sometimes and I roll my eyes every time I’ve done it lately.
End rant, I guess.
Even if that did work however, people would create adjacent subreddits that would end up to be defacto sureddit, for example /r/competitiveoverwatch.
A little knowledge is a dangerous thing. This is true for so many topics.
But if the Rust ecosystem has developed in such a way that most popular libraries don't actually give you guaranteed memory safety, then this quid-pro-quo breaks down. Now you're making a lot of effort to use the language and in return you get ... maybe sorta safety, some of the time? That's a rather difficult tradeoff to weigh up. How unsafe is the Rust ecosystem, really? As a Rust outsider I had thought it was used only very rarely and mostly in the standard library, by way of analogy to the Java ecosystem where that's the case. From this situation it sounds like it's widely used, and often for unclear reasons. So does using really Rust deliver the advertised benefits?
The fact this question even has to be asked is going to upset the Rust community because Rust is like most non-JVM languages, it has very poor interop with other codebases which makes it reliant on building a large community to be sustainable. The Rust community has to make Rust as attractive as possible for its own competitive survival. High profile libraries that undermine Rust's only value proposition is therefore a self-destructive trend. Actix Web gets great TechEmpower benchmarks, but at the cost of undermining that whole community's marketing pitch. Not surprisingly things get heated.
As for Reddit, I don't think that's the problem. Reddit is just threaded discussions with a large userbase. There are plenty of languages with active reddits and way less drama than Rust seems to have. Java, Kotlin, C++, Swift etc all have big subreddits and all have had zero community dramas that I remember in recent years. The issue is pretty clearly something related to Rust and its userbase. My guess is it's a combination of small size, lack of interop and the Mozilla leadership setting bad examples. There was a huge Rust drama a few years ago where they went ballistic and censored an entire discussion from Reddit because they appointed as their community manager a feminist ("kill all men" being one of her slogans) who had just finished creating a massive idpol drama in the NodeJS community, and not surprisingly the community didn't like it. That sort of immature move is something you don't see from more professionally managed languages.
This type of reprehensible response will keep happening until society finally learns how the internet fundamentally changed the nature of fame. The best explanation of the problem is the video "This Is Phil Fish"[1] by Innuendo Studios. If you haven't seen it, please watch it. It's not about Phil Fish; he is simply a useful example of how fame works on the internet. Please watch the video!
The core problem is that fame used to be opt-in. Becoming famous required infrastructure. Gaining access to that infrastructure required the permission various gatekeepers, time, and resources. You had to work to become famous, because media access was a scarce resource.
On the internet fame became something that happens to you, because the internet IS media access. We're used to seeing fame as something that was chosen; if you didn't want to be famous, you could walk away from the media infrastructure and go back to your "normal life". The famous band could quit touring. Now that everyone has media access, that "normal life" can become famous directly. When that happens, walking away from fame means walking away from your normal life.
This is the first I've heard of this conflict in the Rust community, but honestly it's not at all surprising. People write lots of web servers and if you're relying on your community to provide critical libraries (http is pretty critical in 2020) things like this are bound to happen. I really wish Rust core could provide a standard library of tools more akin to Go as I really enjoyed working with it when I was learning it.
What I think this is, is a sad day for the Rust community.
But it is probably a good, and necessary step for the Rust ecosystem. The bottom line is the creator of Actix made something really attractive, but not necessarily good¹, which pulled a lot of people in to using it. It did extremely well on benchmarks, which brought Rust positive attention.
But the project was fatally flawed unless another maintainer forked it. The author was not obligated to accept patches from anyone else, but it was and should be unacceptable to the Rust ecosystem for the most popular web framework to have severe vulnerabilities that can be exploited. And for the author and maintainer to disregard patches to those issues as "boring" or other derisive terms should also be considered unacceptable.
Perhaps that would have been the right way to fix this actix-web issue, to produce a better project. This is basicaly what happened with cabal (package manager for Haskell) and stack (a wrapper that made it easy to build Haskell packages). But at the same time I can't in good conscience recommend anyone use cabal, nor could I recommend anyone use actix-web. It may very well be for the best that they just won't be used.
¹ - Good has lots of different connotations. Is there a lot of code? Yes. Is it largely well written? I think so, based on what I've heard. But in the long term having a benevolent dictator for life controlling a major piece of the Rust ecosystem is extremely dependent on them being benevolent, and rejecting critical security fixes and declining to engage the community in any meaningful way is not this. On the other hand, I think projects like async-std and tokio have a much more benevolent (and less dictatorial) leadership.
Maybe there's a solution to that other than avoiding forks, but I'm not sure what it would be. It seems like a pretty fundamental challenge.
In that case, simply moving to another project is the best option.
This is not so. If you said "forking can be perceived as an aggressive action"* I would not disagree with you, but in the context of an FOS ecosystem, forking should not be perceived as aggressive, and it definitely is not inherently so. If someone doesn't want anyone to fork their project, why release it under an open source license? Free/Open source, full control: pick one.
I object to the characterization of forking as aggressive first because it's not, and second because it cuts off another potential avenue of redress or action. We already agree that "shouting on twitter and reddit" is not a good response. If you declare forking off limits or "impolite," what alternatives are left in a case like this?
I acknowledge the complicated ecosystem impacts of forking a popular project (I'm from the JS world where the impacts are extreme), but I don't think "let a project stagnate or yell and shout because the maintainer has other priorities" is a better alternative.
Forking a project in a case like this should be seen as "putting your money where your mouth is"/"stepping up to the plate"/taking on responsibility for change if you think a project is going in the wrong direction. Personally, I fault bitter complainers who don't fork a project for being lazy: do you care enough to actually do the maintainer's job, to take on that responsibility? If no, then what gives you the right to condemn them? If yes, great! Your problem is solved and you can maintain rather than complain.
More forks please.
* just as asking someone "where are you from?" can be perceived as aggressive but that doesn't make it objectively/inherently aggressive.
I wish that it wasn't perceived as such, but the reality is that it is. Ignore that at your own peril.
I think you should just fork it privately, apply your patch, and move on with your life.
Forking isn't provocative. Forking and then claiming your fork is objectively superior is.
Also the core dev(s) for larger projects are usually somewhat responsive, whereas devs who fork to add their one feature usually aren't signing up for that core maintainer experience when they do so.
Shouldn't we disabuse ourselves of that notion? Forking a project to solve an issue is just that. We shouldn't attach any sort of emotional connotation to it.
But at the same time, why should the original author do it? No one is paying for his or hers time.
But… are there ways forking could be made less aggressive (perhaps easy re-joining, community-based PR review and testing)? I remember this was a huge deal in the NodeJS community a few years back—it took a hostile fork to get the conservatives and progressives to agree on a way forward together.
Is it really, though? It is more of an "agree to disagree" situation.
Just like the maintainer doesn't owe you anything, you don't owe the maintainer blind loyalty, either.
I wanted SimpleProtocolPlayer to be in F-Droid. This requires the author's explicit consent. Unfortunately, the author had not been seen active on the project for a while and did not respond to our questions.
I forked the project so I could be the "author" and give my consent (yes, clearly a hack), told them about it, and my willing to merge back at any time. See [1] if interested.
They eventually told me they were fine with the fork, and preferred having a fork for the F-Droid version of the app so we did not have to rely on their responsiveness.
My fork included a fix that they merged.
Some situations warrant a fork, and if communication (about the intents, the means and the expectations) is handled as best as possible, the fork can be seen as friendly by everyone.
You are right though, I would not want to become the maintainer of projects I sent a patch to. And by the way, I did not really want to become the maintainer of the F-Droid version of SimpleProtocolPlayer at first, but this is fine.
[1] https://github.com/kaytat/SimpleProtocolPlayer/issues/21
Forking can be aggressive if you write deprecating things into the forked project's readme, but of course you don't have to do that.
You could also talk to the old maintainer before forking; maybe they are happy to give up some responsibility, or maybe they even endorse a fork.
We are already WAY past that line, just because people don't fork
> and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.
So DON'T run a project. Fork it, fix your problems and be done with it.
This seems to be at the core of the disagreements in this thread, one argument being that you shouldn't be expected to maintain a community project just because you put code on the internet.
Expecting that will lead to less open sourced code, which is bad IMHO.
Lastly, your last argument argument reads a little bit as "Not everybody has the desire or time to run a project, so what they want is somebody else to do it"
I might be reading in to much into it though. This thread has a fair amount of pronounced entitlement.
Another (persistent) problem has been the crates.io namespace.
You can fork actix, but then you'll need to come up with a new name for it, and then educate the wider community of that. It is a big hassle, and slows adoption.
Adding onto the issue is that crates.io does not (yet) support the username/projectname naming scheme as on github and other popular code repositories. So it isn't enough to just people to go to a different username, you must use a new project name.
Given that the actix author already wanted to take a step back after the last incident, and also seems to be generally okay with giving the project away, a fork could also be officially advertised.
Word also travels fast in communities, and if a viable fork does come up, people will quickly start to recommend it.
If you do look at comments by safety-focused developers from earlier actix drama, you'll see that quite a few simply use a different project. The answer might be that actix doesn't provide enough value compared to alternatives to be worth forking for those people. The people aggressively attacking actix might not even be interested in the project for their own use, but merely there for the outrage.
https://github.com/actix/actix-web
I get it, they feel personally harassed and slighted. And it's their project, they can do with it what they like. But it still feels like the decision is motivated more by spite than by a desire to simply wash one's hand of the project. Surely there are not hostile developers who would've been willing to take over the maintainer role.
"(Btw thanks to everyone who provided prs and other help!)"
So the maintainer was grateful for the PRs, but worn down by all the people complaining without contributing.
Imagine how much the maintainer must has been burned, in order to take the decision to shut down their entire love-work – in hope that the toxic situation will stop.
From our point of view, this may not be the best decision. A desperate one, maybe. But to imagine how the person must be feeling to think this is the best way out.
https://www.reddit.com/r/rust/comments/epoloy/ive_smoketeste...
I have no doubt it led to some github issue brigading, but it's not really that big of a deal. Ostracizing /r/rust in a mealy mouthed way probably won't make that community better...
You say:
"Some people go far, far, far over the line."
So some people are assuming this is just the maintainer responding badly to people pointing out problems with his or her code, but you are saying it went far beyond that into personal attacks?
FWIW what you say matters a lot, pretty sure you have a ton of respect from a lot of engineers across multiple language communities (myself definitely included).
I definitely appreciate how difficult it is to be the "custodian" of a) a language community and b) an open source project within that community.
Python has many of the same issues, where core devs and key maintainers go dark or behave badly. What Python does do pretty well, and what I like about it, is placing its core user front and center. For Python, that is the beginning programmer, and Python has a lot of empathy for him or her. What I also like about Python is a general willingness to have difficult conversations and back rebuttals with code snippets.
I read difficult conversations by Bruce Patton a while back, and it wasn’t an easy read for me because I have problems of responding sometimes in a constructive manner, but I learned a lot and I would highly recommend it .
I’m confident the Rust community will survive this and come out stronger than ever :)
To sum it up: "George R.R. Martin is not your bitch."
I would carry this even further: "Open source maintainers are not your bitch."
I see a lot of whining and entitlement from engineers on open source repo issues pages. Open a pull request, fork it and host it yourself, and just relax in general.
Not to say maintainers can't be jerks. But again: That is their choice. They are not your bitch.
There have been times on here where I see discussions around `unsafe` as if it was a curse. I think the discussions, over time, have gotten more nuanced which helps.
I also wonder if expectations were unclear. It now sounds like the focus of Actix was on performance and creativity / cleverness and not on being a mature product. I never heard that before. Maybe even the author didn't even originally articulate it so clearly but discovered it through these discussions.
Going forward, I hope someone archives their clones of actix and that people fork that and get it moving forward as a product. I hope people don't take a religious view of removing `unsafe` during the fork but instead follow best practices (benchmark to confirm the need, abstract it to test it, offer a feature flag for the paranoid to disable as much of it as possible).
Some of the latter will be forked, and the forks certified to higher levels, and those forked again and the forks certified or de-certified again.
This marks a step on the way to maturity, right on schedule. By the evidence, in ten years Rust will be a mature language, much more quickly than some. Most don't get there.
That's actually my main sticking point on this being mostly on the maintainer. From the actix documentation, releases, and promotion, I never got the feeling that it was _not_ meant for production. Even to the point of the comment "Microsoft uses this in production".
And suddenly, "It's creative/fast/research/whatever"? That really feels like trying to sidestep findings because you don't want to lose your spot in the techempower benchmarks. Even more so, when the documentation, etc. is not updated to reflect this new focus, and there's no announcements about it.
Rust is a macrocosm of a phenomenon I've noticed in my own career: My productivity is inversely proportional to how dogmatically "correct" I'm trying to be with my implementation. The Rust community embodies many of the negative aspects of perfectionism that tend to stall real world progress. That perfectionism doesn't necessarily carry over to your code, but I find myself wondering if I'm doing things "the right way" far more in Rust than other languages.
Some growing pains are normal for any community. I really hope the Rust community can settle into a healthy environment. Until then, I'll reserve Rust for only smaller projects where I can afford to bail and rewrite in another language if it starts to spiral in complexity.
Can someone familiar with Rust and it’s communities explain from a high level what all this is about?
What does it say that I wouldn't be surprised one iota if "far, far, far over the line" included death threats? Nobody should be expected to continue to contribute in a community with that kind of vitriol pointed their way.
EDIT: Even if all "far, far, far over the line" means is personal attacks and not death threats, that is still not simply criticism, and it's still far beyond what someone should be expected to endure in the name of "open source".
See this comment at GitHub: https://github.com/actix/actix-web/issues/5#issuecomment-575... — it also links to a mirror.
Then just read the second last paragraph:
> This means, on some level, this situation is over: there will not be a fourth huge actix-web drama. But it’s really left a bad taste in my mouth. It’s unfortunate that a well-known project had soundness issues. It’s unfortunate that the maintainer wasn’t receptive to fixing them. At the same time, I’ve been there: being a maintainer is tough. It’s also unfortunate that there’s this style of response, and kind, and volume. It is true that the situation was dangerous. But did it have to be handled this way? You have to understand a lot of nuance here to even know the main points of the story. One version of this story that will certainly be told is “The Rust community says they’re nice but they will harass you if you use unsafe wrong.” Is that what we want? I, for one, do not. If you’re a part of Rust, you gotta ask yourself: are you happy with this outcome? How did your actions (or lack thereof) contribute to it? Could you have done something better?
I think this is another story about the destructive power of the internet echo chamber, where the asymmetry of one person vs. a mob of people who are in reality probably not all that engaged with the problem but nevertheless have enough engagement to send a nastygram or two creates a distributed denial of decorum attack that no single human being should be expected to deal with "nicely". Our ancient instinctive tribal signals of whether or not you are approved by the tribe, tuned for tribes of 150 people or so, receive a message that 15,000% of the tribe thinks you are a bad person, and our natural human response to that is a lot of stress at best (our ancient instincts tell us that eviction from the tribe is a bad thing, even though in practical terms eviction from this particular tribe won't be much of a problem at all in the modern world).
(I phrase it this way because I think this is, well, not strictly speaking independent of the question of whether or not the maintainer was guilty or innocent of any particular thing, but because the story is the wild disproportionality of the response you can get on the Internet regardless.)
And absolutely correct in my view. I have been on the receiving end. I have friends who have been on the receiving end. It really is overwhelming to receive that 15,000% signal, nudged along by the dynamics of the rest of the tribe.
I really like that you found a way to cover this aspect.
I have two simple mantras which establish my philosophy here:
1. YOU are responsible for your dependencies.
2. Open source participants are volunteers and owe you nothing.
It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change anything in the slightest. Your dependencies are your responsibility. Responding with vitrol, anger, or hate when failing to uphold this responsibility bites you in the ass is just being a jerk.
User entitlement is totally unjustified and will burn out maintainers faster than almost anything else. I don't stand for it. If any other maintainers out there are struggling with this, please send me an email: sir@cmpwn.com. I'm sympathetic to your cause and I can likely lend some pertinent advice.
If it doesn't meet your standards, don't use it.
Alternatively, go fork yourself.
It would be nice to have cargo/rustc support 'allow_unsafe' per module and also for dependencies, so you know you have to review a dependency really well.
>Alternatively, go fork yourself.
I think this could be the new template for Open Source Author to include in their OS work description should they choose to.
Or you get drama like ffmpeg vs libav/avconv.
I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library. And regardless of how strongly you feel about 2), the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care". These statements aren't mutually exclusive
Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in maintenance - these are the correct solutions.
I was there (as a user who closely followed development) during the nodejs > io.js split. While it worked out in the end, it felt like a bitter battle at first. Node survived by chance perhaps.
We have our async-std vs Tokio right now, I'd imagine having another split (at least in opinions and preference) on actix would still keep tension high.
It allowed for the chaffs to fall through making node a stronger project because it was clear that neither of the sides was going to "win" outright.
If the argument is that "maintainer is not doing his/her job of being a maintainer" and this argument is accepted by the users, then should the project be forked by someone who will do his or her job of being a maintainer, the users will flip their source repo pointer and move onto the fork effectively killing the original.
Does the fork care as much about TechEmpkwer benchmarks? What happens if it is slower because it forbids unsafe even where it makes sense?
There was a looming cliff in Async/await, which caused a split to some extent (some old libraries that no longer have maintainers, changes that make updates difficult). A fork with those changes looming would mean divergence when rewriting to support Async/await.
Maybe I'm being too cautious, but I doubt we'd have had a successful fork earlier. Let's see if it happens now ...
Who's they? Most of PR commenters were courteous. The last few were rude, but so was the fafhrd91. https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...
> The last few were rude, but so was the fafhrd91
https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...
Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour.
Good thing that those who submitted the patches and PRs were polite; they're not the ones who caused this maintainer to quit though I'd wager...
There is a prominent "Fork" and "Clone" button in every GitHub repo. If you're so fucking sick of the lack of support from the maintainer, fork it, fix the flaws that you've found, and assume some of the responsibility for the project.
This whole situation is a bunch of people getting angry because of what they view as a lack of accountability. That's preposterous - the nature of GitHub and open source makes it super easy for you to assume some of that accountability yourself. The fact that so many people chose to get upset rather than assuming accountability speaks volumes to me.
Pull requests welcome, jerks. </s>
You publish your code to Github, you're part of a community. You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.
Hell no. It that were the case, I'd never publish anything.
> You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.
It is YOUR responsibility to see that for yourself by watching how the project is actually maintained.
Why do so many people insist on being aloof and unhelpful in communicating to users of their software? What is so hard about offering a modicum of context for what people can expect of you as a maintainer? It's so ideologically rigid and unreasonable.
Maybe. The main issue I see with github is that it's impossible to disable pull requests there. We have that issue in the coreboot project, which uses github as a read-only mirror.
Maybe we should just shut that down to make clear that coreboot is not part of the "GitHub community".
Those are demands. The toy project one is relatively low cost, but "he should have given reasons" brings with its lots of effort to do right - and then you get to do it over and over again, because the masses can fling shit at you faster than you can reason about it.
critcism: the expression of disapproval of someone or something based on perceived faults or mistakes.
"he should have ..." is clearly an expression of disapproval.
Of course he didn't, in the legal sense of the term. And then people didn't have to stop criticizing him, in the legal sense of the term.
And obviously for the ethical / moral point of view, people have vastly different opinions, otherwise there would not be this debate.
Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security.
Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.
No, if you pay for things, you have a contract and things are immediately different.
Find vulnerability. Already, awesome of you to have done. Issue patch request. That's 10x even better, you're a boon to the community. You submit it, it gets rejected, you find out why and it's the maintainer is just not feeling it or some other irrational reason. Fork, put in the readme why you forked, write a blog post without being a dick about it, done.
The article we're talking about is referring to the bloodbath of a Reddit pile-on. That's totally unacceptable behavior from an adult.
You should be able.to fix them yourself
That's the premise of OSS
if you don't want to pay for a cab or a driver, you should be able to drive
- full access to the source code
- full rights to modify it and use it as it was your own
There's no other guarantee.
So if someone writes some code that becomes highly popular, they have no obligation whatsoever to maintain it the way people want.
They don't even have to maintain it at all, if they don't want to!
It's out in the public, it's free, that's the end of the agreement on the creato's side.
If a writer gave away their writings for free, could people pretend that they write what people want them to write, the way they want?
Is it fair to judge the writer because the answer was "WONTFIX"?
But the reality is worse than that.
A lot of companies are literally making billions using OSS, but they are not paying for it, a lot of programmers are making a lot of money by assembling OSS for their clients, but they are not paying for it, hell most of them are not even contributing in _any_ way, what does entitle them to pretend the attention of the OSS maintainer or that the maintainer should act in a way or another, according to the "community" desires?
Even if I'm not paying them anything.
And you know what's a good form of criticism? An issue with an attached PR
if you accept that the open source projects are voluntary as an axiom then you in fact cannot criticize choices made by the volunteer.
here's an analogy: a homeless person asks for money. you don't give him money but buy him food. can the homeless person rightfully criticize you?
A homeless person asks for money. You don't give him money but give him some advice. Can the homeless person rightfully criticize you?
You can absolutely criticize choices made by volunteers. I don't think you need to think too deeply about this to imagine situations where few would object to criticizing a volunteer's behavior. An obvious one would be if an open source maintainer willfully included malware/etc. into their project - which, to many people, ignoring glaring security issues is vaguely equivalent.
I obviously don't think vitriol is warranted ever, but criticism obviously is from time-to-time.
you can criticize all you want as an exercise of your critical thinking faculties but the volunteer is not in anyway obligated to heed the criticism.
"it's my money/time and I'll spend it how I want, which includes burning it"
is the fundamental axiom. Given that that is the foundation what sense would it make to criticize that person for burning the money - it's right there in the premise that they're allowed to!
It's your analogy, you tell me.
> you can criticize all you want as an exercise of your critical thinking faculties but the volunteer is not in anyway obligated to heed the criticism.
Nobody said they were. Nobody's trying to punish the maintainer legally. That doesn't mean criticism won't be offered or warranted.
Here's another analogy: You have a right to be a jerk in real life. Nobody's going to physically or legally stop you, barring extreme circumstances. People will still criticize you for being a jerk, as is THEIR right.
>People will still criticize you for being a jerk, as is THEIR right.
completely specious. code in a github repo is not active participation in society. the fact that it's public does not mean it's been submitted for evaluation in any way. criticizing a thing that wasn't critically submitted is meaningless. it's like calling my practice sketches inferior to commissioned pieces - no shit that's the point!
the maintainer?
> completely specious. code in a github repo is not active participation in society. the fact that it's public does not mean it's been submitted for evaluation in any way. criticizing a think that wasn't critically submitted is meaningless. it's like calling my practice sketches inferior to commissioned pieces - no shit that's the point!
Uh, what? By packaging something as a crate, by listing it on crates.io, you're submitting it to be used. If you don't want it to be used or evaluated, at all, why in the world would you publish something as a crate on a public registry?
This is more like submitting your sketches to a public art gallery and then being upset when the public criticizes it.
that's not what happened. there weren't simply discussions of the viability or soundness or the crate. there were implicit/explicit demands for changes. so your analogy is wrong again - it would be like submitting public sketches and then facing demands that the sketches be improved. does that sound like something that i as the artist should be comfortable with? more importantly does that sound like something a reasonable person would do (make demands for alterations to sketches submitted to a public art gallery)?
Are you sure you have a firm grasp on what actually transpired here?
maybe a better analogy is if i play a pickup game of basketball and i get labeled a bad player for not trying my hardest. it's not that the criticism is misplaced it's that it doesn't make sense at all - i wasn't trying to be a good player! i was trying to have fun.
I don’t understand the desire to make this out to be a sort of dichotomy—both groups have the right to do what they did (the maintainer to reject patches and even allegedly lie about the security properties of his project and the critics to criticize even in bad taste) and both parties could have handled it better. TFA did a fine job for implicitly acknowledging this by simply referring to the situation as sad all around.
this is so weird to me. i have a really difficult time on hn often because i don't understand why people that claim to be intelligent can't distill out the fundamental/primary issues.
it's a free/proffered/donation/voluntary/no strings attached piece of code. that is the first thing that defines its use/understanding/existence/ontology whatever other words. everything else is contingent upon that. you can debate this point - you can say something about the social contract of open source software and your responsibility to the community if you yourself have benefited from other open source projects and etc but no one is debating this. everyone is debating aposteriori things.
if i put a mattress out on the street with a sign "no bed bugs" and you pick it up and it has bed bugs in can you be mad at me? can you take action against me?
i don't know what kind of framework i need to appeal to in order to underscore this issue so that people address it directly instead of things further down the line. i would really appreciate someone showing me how to either do this (put the focus on the thing i'm engaging with) or tell me why i'm wrong for focusing on that.
I feel the same way, but not about /u/weberc2's post.
> it's a free/proffered/donation/voluntary/no strings attached piece of code. that is the first thing that defines its use/understanding/existence/ontology whatever other words. everything else is contingent upon that.
This is another of your own axioms. These aren't universal. In particular, if a maintainer states or otherwise implies that his project is secure and suitable for production and then behaves otherwise, criticism is warranted. Even if he doesn't, criticism is still permissible.
> you can debate this point - you can say something about the social contract of open source software and your responsibility to the community if you yourself have benefited from other open source projects and etc but no one is debating this. everyone is debating aposteriori things.
No one is debating this because it's not necessary. The maintainer's explicit assertions about his project (its security, etc) override implicit "social contract" responsibilities.
> if i put a mattress out on the street with a sign "no bed bugs" and you pick it up and it has bed bugs in can you be mad at me? can you take action against me?
Not sure, but I can certainly criticize you.
> i don't know what kind of framework i need to appeal to in order to underscore this issue so that people address it directly instead of things further down the line. i would really appreciate someone showing me how to either do this (put the focus on the thing i'm engaging with) or tell me why i'm wrong for focusing on that.
In general your arguments are based on your own axioms. If your axioms aren't widely-shared, then you will run into these sorts of disagreements.
how is this my axiom? it's on github. no one has paid for a license (the license is completely permissive).
>In particular, if a maintainer states or otherwise implies that his project is secure and suitable for production and then behaves otherwise, criticism is warranted.
is that part of the TOS of github? is that part of the bylaws of the guild of software engineers? is that in the bible? where is this codified except in this thread around this issue where everyone is mad?
>Not sure, but I can certainly criticize you.
you can do whatever you want. you can stand on your head and recite the star spangled banner. i'm posing the question whether it's reasonable. is it reasonable to criticize me for putting that mattress there in that state?
>In general your arguments are based on your own axioms
again they're not mine in the least - i did not coin the phrase "don't look a gift horse in the mouth". that is much older than me and fairly universally understood/accepted.
The trouble is distinguishing the cases.
But our society does not just openly accept giving criticism. There are rules. Unwritten and extremely vague ones, no doubt, but still social rules. This is especially so when criticizing something a person is providing for free. In this incident, did the criticism cross the boundary and violate those rules? It seems so. Many people likely gave respectful criticism that followed the rules but they appear to have been drowned out by those who did not.
The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.
You can criticize open source maintenance by creating a fork in which you outline your vision (e.g. "much less use of 'unsafe' in the web package") - and deal with the burden of being a maintainer.
Everything else is just trying to force people to do stuff for you, and that's rude.
> The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.
Of course it implies that the maintainer should change. All criticism implies an expectation of change, at least when the opportunity to change is still available.
> Everything else is just trying to force people to do stuff for you, and that's rude.
Criticism isn't "force" or "attempted force". This is just criticism. If you think criticism is rude, that's fine. Hypocritical, but fine.
You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.
No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.
Hiding that behind "I'm just criticizing" (you didn't, but it's a popular refrain in such "debates") is more than only rude, it's also cowardice.
> You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.
The author of the package didn't force their code onto the users.
The authors of the criticism forced their criticism on him by throwing it his way in the form of bug reports etc. even when it was clear that there's no interest in it.
Unless the critics are engaging in threats, intimidation, and/or violence, we're talking about criticism and not force.
> Criticism isn't "force" or "attempted force". If you think criticism is rude, that's fine. Hypocritical, but fine.
No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.
> The author of the package didn't force their code onto the users.
No one is arguing this. Weird straw man.
> The authors of the criticism forced their criticism on him by throwing it his way in the form of bug reports etc. even when it was clear that there's no interest in it.
Wow. I really didn't anticipate the "bug reports == force" equivalence.
Re. "The author of the package didn't force their code onto the users," it's not really a straw man. People are arguing that the author has moral responsibility for their use of his code. That ignores the fact that they actively chose to use his code. The only way the author would be morally responsible for their use of his code is if he had forced them to use it somehow. So yes, people are basically arguing this.
But software done for free by volunteers carries no obligation of a legal or even a moral kind, whatsoever. This is completely different from selling software or doing work for hire or donations. There a moral and often even legal obligation exists.
Adding to this, you might still transitively depend on the upstream through your other deps in ways you can’t change without either forking all your deps... or getting them to switch.
And what does “getting the ecosystem to switch” look like? It looks a lot like complaining about the upstream, such that others in the community understand what the problem is that your fork is solving.
If you depend so much on that code, if the security of your software depends on someone else's free work, why don't you hire that person to fix the bugs?
If the community cares about security then should this happen:
> Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure.
The community would move onto your secure fork and the author of said fork would become a maintainer. As Dave Rand, the CTO of AboveNet used to say to newcomers who used to say 'X should be done!' -- "Thank you for volunteering - you are now in charge of X."
"Atrix-web should not use unsafe"
"Thank you for volunteering - you are now in charge of making atrix-web not using unsafe"
"Thank you for delegating responsibility of making atrix-web not use unsafe, to me. I accept responsibility for this piece, but you are still the leader of $PROJECT." <workworkwork> "Here is a PR that makes atrix-web less unsafe."
"I don't accept your PR."
Dave Rand's advice doesn't apply here, as several people picked up responsibility for making atrix-web less unsafe, put forth the work to do so, but were rejected. It's one thing for me as a user to feel entitled to everyone else doing what I think they should, while not putting in any effort, but IMO it's less clear cut when I'm putting my money when my mouth is, and submitting PRs.
Fork it, make it "atrix-web-safe", post about it on whatever rust announcement list/forum/group is and have people move to the "atrix-web-safe". That's leadership. The rest is moan-fest.
If you fork on GitHub, they take care of letting people know.
I've forked a few abandondedish projects, and other people seem to find the patches. The best example I can think of is stud, which the people behind Varnish adopted and renamed to hitch; they surveyed the landscape and took good patches from most of the forks.
I might not look for forks from a more active project, but it's definitely something I look for when I run into problems with software without a lot of recent updates.
Or you can pay the cost of bringing in changes from the upstream project. This happens a lot for commercial software. I remember having to maintain a “fork” of BEA’s WebLogic server for a year or two until they incorporated changes my employer needs.
It’s not so bad.
What actix developer did was, to pardon my French, inexcusable. Deeming security patch boring? Making your own `Cell`, implementing it badly and misusing it, because it's faster on some stupid benchmark site?
If we designed cars like that, they would have no breaks, no gears and no cabin.
Honestly, I think it's better Rust abandons `actix` asap. Before it gets any real traction.
I do not know how the Rust community manages performance comparison, but the .NET bubble was broken by that page and resulted in awesome results for the platform.
PS: just pointing out what the page achieved somewhere else. The discussion about the maintainer and what happened there is a different topic.
But from what I heard, to get where it is, actix developer took some really bizzare shortcuts. E.g. hardcoding parts of response. On top of general unsafe usage.
I think the benchmarks are flawed, since they don't account for such "optimizations".
In .NET case they changed the language in response to the needs of the Techempower benchmark (and the Unity3d engine) to allow safe and performing ops. .NET also has the unsafe keyword for low level ops and is surely also used. The advantage of .NET is that it was a team with a central manager who pushed all areas, http framework, base class library and language into the same direction. A community like Rust does not have that privilege.
The patch was "boring", not substantial to claim copyright.
https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...
"It’s extra nasty this time. Some people go far, far, far over the line."
When someone polite says this, I picture some of the nastier attacks on the internet - doxxing, death threats, and swatting.
The correct response would be to organize the community to create a fork that is more focused on correctness and security than on performance.
Whether it would be appropriate in this I case I don't know but I disagree that it is never the correct response.
I highly doubt that it would do anything to prevent that continued behavior. I cannot imagine a situation in which there is not a better and more appropriate solution to mitigating poor behavior that telling people "don't participate in this field". At best you will alienate them in such a manner that alternative approaches are less feasible and at worst you convert bad behavior from being passively to actively malicious. I'd be curious if you have a concrete example for when you think this approach has been beneficial in any context.
Note, I consider revoking credentials (e.g. disbarring an attorney or revoking a medical/engineering license) to be something entirely different as there is an active endorsement that needs to be terminated. Relevancy in this case would be to removing a package from a package/dependency listing service/manager.
Can I express that to people who think a volunteer project owes them anything & couldn't be arsed to implement the project's functionality themselves in the first place? Somehow I don't think that would be a constructive use f time.
I don’t want to come as negative toward Rust or developers using it, but there is a whole lot of using Rust’s ‘security’ focus/features to say the Actix developer needed to do things a certain way. He wrote he, he could do whatever the hell he wanted.
It’s just “npm install” and YOLO for a lot of developers!
It's almost like watching lottery winners having their lives ruined.
It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like this? I know, I know. I'm taking my crazy pills again. Sorry.
At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license just to reinforce my "you take what you can get" policy.
- There exist open source licenses (with copyleft) that disallow making it closed source.
- There exist other reasons to publish the source code: for example allowing the user to study it.
Technically you could just post the .pyc bytecode as long as you didn't care about it working on anything but CPython and compatible implementations.
That doesn't mean I'm willing to accept your patch. As soon as I accept collaboration, I need to worry about copyright on the contributions, whether they follow my coding style, and whether I'm willing to accept additional complexity for features I don't care about.
Consider CC0 instead.
As a veteran open source contributor, I totally understand that dealing with open source communities has a huge cost to go with the huge benefit. Even just vetting patches can be a pain when you care about security and architecture and don't want to spend time endlessly explaining your choices.
CC0 allows you to provide maximum benefit should you opt out of "social coding". People can go ahead and fork your stuff, or just use bits and pieces, without needing to deal with licensing or crediting headaches. (Significant consumers still have to track provenance, though.)
Certainly I would expect amyjess and anyone else reading to exercise due skepticism and perform their own research and I respect them enough to expect that they will "consider" my suggestion rather than "blindly" follow it.
PS: Why assume everyone is "ill-informed"? We're all learning together forever: you, me, amyjess, other readers...
Sounds like a whole lotta give to me...
It seems like you're trying to make it seem like there is always a legitimate exchange, and so they owe you something. Some projects want help, others don't. In the latter case, it's just a gift from the author, and they don't owe you anything.
Any open source maintainer will tell you that many PRs, even well-intentioned ones, end up being a net negative. Often they don't further the maintainers aims, they need detailed review, take sometimes a lot of effort to manage the communication tactfully, etc.
Yes, many PRs are a win and it can be really gratifying seeing your project become bigger and better than you could have made on its own.
But also, many PRs are just a chore and a hassle.
The level of entitlement in the discussion astonishes me. Someone has done a lot of work and offered it for free along with a license that lets people modify it and redistribute it and that is not enough. Instead of being grateful for it, people are demanding that the giver also make the changes that these people need and take on the burden of maintaining them.
To all those people: Why should he? Do it yourself or pay someone to do it. It need not be any more complicated than that.
People should decide if it's a big deal for them and if it is, fork the project to fix the issue or move to another library. I have had to do this many times myself, I kind of thought that's just how things worked with smaller projects. More than once I've found someone of a like mind has _already_ forked and made the change.
I see it frequently in the FOSS community where someone will suggest some software they made to solve a problem, get told why their software isn't actually that good for the problem, become defensive about it, and then try to play the "entitled user" card.
If someone is terribly dressed according to my taste but brags about how amazing the garb is, I'm not going to tell them how they are wrong unless absolutely necessary because of exceptional circumstances.
Neither does most people who respect others right to their own body, and creativity.
I don't ring up the artists after visiting a gallery to tell them how their art is done, not unless I'm an ass.
Source code is not much different, it is an expression of technical competency, art, taste, and fashion.
If someone asks for feedback, sure, your points are not wrong.
In practicing social dancing, asking if someone wants feedback before giving it generally works out really well. Most people want feedback if you give them the power to choose for themselves, but quite a few really do get hurt if it is unsolicited. There will be some people that get slightly annoyed that you ask, as they prefer more direct approach, but neither they or anyone else get hurt.
Something similar probably works for open source projects too. Engage seriously for a bit, and only then ask if your input on your particular issues would be interesting to the other party.
If they're actively asking me to use their software, isn't that soliciting feedback? If I say 'no, it won't work for me', I've apparently committed some egregious microaggression right? If I just say 'no thanks', what do expect the very next thing they say is going to be?
>> Just because you made a software doesn't mean I have to use it or like it, and if you are actively trying to recruit me to use it then I am indeed entitled to complain about it.
That is what I wrote. That is entirely the context of what I said.
Perhaps, but if he claimed that it _was_ vetted, then he took on some responsibility for it (which he probably should not have).
Also, the blog post article claims, that you are never supposed to use "unsafe" code without having vetted it. Honestly, I doubt that very much, but if it's true than that's some responsibility taken too.
The problem was that PRs which would have fixed security issues where not accpeted.
Do I expected perfect code from maintainers or a answer the next day? No, never
Do I think maintainers/creators should merge prs in a timely manner, or ask for help if it get's too much? Yes, otherwise you have multiple forks and the project is not usable anymore.
I mean, anyone can fork it and become a maintainer, and create new guidelines and inclusive rules that ensure the project is steered in the "right" direction. Isn't it the case?
I understand the "we just want a better actix-web", but there are two conflicting concepts, "better", and "actix-web". The way I see it, "better" is whatever the maintainers think it is, and "actix-web" is a project belonging to its maintainers. No community should ever be entitled to try to steal that. They are welcome to build upon it and fork it. This doesn't mean they have to separate ways forever: some forks live happy parallel lives, as so many Linux patchsets have demonstrated over the years. Projects are free to be born, forked, cross-pollinated, merged together, even die, all at the will of their maintainers.
I know that is how it is "supposed to work". However, I've very rarely seen it actually work that way.
The problem is the "first-mover advantage" and it is a hard one to overcome. If you make a "maintained actix-web" fork, most people will still find their way to the dead project. Even worse, many resources and tutorials will point to the old library. A search for "actix" will almost certainly give confusing and frustrating results to the novice.
check, check and check again...
When I signed up for a GitHub account, I don't recall anything about having to agree to an SLA.
I've seen many small projects that I use or monitor where someone will raise an issue or make a PR, and the owner will respond along the lines of "Great, looking into it, but I'm kind of busy right now, will get to it when I have time," and then people going off on them if "when I have time" isn't right now. Usually this is followed by an offer from the owner to give the reporter access or pass the ownership to them, which is invariably followed by crickets.
There has been a lot of talk in this thread about the obligations of project owners. This seems to boil down to fundamental philosophical differences. My view is that if you want people to do shit work and jump when you say frog, you have to pay them for it, rather than bully them.
It actually was not. The article is quite clear that the problem was created by the way the Rust community, particularly the one at Reddit, acted and reacted so poorly with regards to the way a project was maintained.
Let this be as clear as possible: the problem is not nor it ever was any PR. The problem is the appalling way the Rust community attacked the maintainers of a project.
It's moments like this that I reflect on the past and the public and virtual forums I have participated in... and how my own attitude shifts in favor of cooperation when I must couple my face with my words. And I wonder if others feel the same.
The only limit might be publishing something that is actively intended to do harm. But I can't imagine a plausible example of that...
And if you're intentionally doing any of the things you listed above, then you're not a maintainer. That simply is not what maintaining means.
No it isn't, unless those users are paying.
If you disagree with the notion of someone publishing their work under a free software or open source license being useful for the world, then please post an AskHN about it and you will have _plenty_ of material to convince you of this perspective. However, I think most reasonably clever people can already come to the conclusion themselves.
What you are responding to is a rhetorical response I gave as an argument against the dismissive idea that an open source maintainer should have no responsibility unless they are getting paid. I don't agree. I find that it's a maintainer's responsibility not to extend, but to maintain. That's all I'm arguing.
If someone wants to throw OSS at the wall to see if it sticks with no obligation to maintain, then that's fine. But as soon as someone puts on the maintainer hat, I think it's reasonable to say they are accepting responsibility for that role.
"If that's the case, then why open source it at all?"
This is the part which made me feel you disagreed with it.
However, may I ask if it is your belief something released under an open source license comes with an intent to maintain it (for others)? Or that releasing something under an open source license is a declaration of being a maintainer of said software?
(not trying to be snarky and am just trying to see why we appear to be in disagreement)
> This is the part which made me feel you disagreed with it.
I am aware, and as I already explained, this is a rhetorical device which you mistook for my own personal belief. Obviously I don't believe OSS is bad. It's friggen great.
And that's a fair question. I am absolutely not saying that open source means you must maintain it. I am simply saying if you call yourself a maintainer then you are responsible for maintaining. If you don't want to maintain OSS, then don't. Just don't pretend you're a maintainer and that you have no responsibility to maintain. At best, pass it on to someone willing to maintain it. At worst, pretend you're working on it. As I said in my original comment, others should fork as needed.
And to add, I don't believe the original subject of the article, the now former maintainer of actix-web, did the wrong thing. I am in agreement with their decision to drop out. No one should be held to an unrealistic standard by entitled users and expected to put up with that BS. The part of my original comment that everyone has a problem with is seriously the least consequential phrase. Blows my mind that everyone is hyper focused on taking it out of context as well.
Otherwise we get dozens of half broken forks all over the place. That's no fun for anyone.
This wasn't a drive by beg. This was a patch solving real demonstrable problems and at minimum there should have been a transition plan due to basic decency.
Doesn't work that way, I'm afraid. The maintainer already gave the community something, and doesn't owe them anything more.
Giving someone the mere ability to make a PR is already a gift far beyond what the original author owes.
If you as a user don't like it, ask for a refund.
Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based.
Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.)
Much of what makes online (and offline) arguments so unproductive is confusion over where exactly people are disagreeing in the first place. There's no point in discussing whether someone did the right or wrong thing if you don't even agree on the principles by which that rightness or wrongness will be judged.
If I disagree with one of your principles, we need the discussion to be at that level, or more likely, we simply must agree to disagree. If I think there's another principle you aren't considering, we can debate its relevance. If you're missing key information, I can provide it. If you're misinterpreting something, I can offer my alternate interpretation and justification for why I think it's better. In any case, if I disagree, it's clear how to proceed because your line of reasoning is clear. We can engage in a productive discussion without talking past each other.
As it stands, I agree with you 100%, but more importantly, you have raised the bar for discussion on this contentious issue. Thank you again.
Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But there's not some category of honest people among whom you can avoid human nature.
But as I understood you, point taken. The distillation of principles, information, and interpretation into an opinion does not actually occur as idealized in my breakdown. I wouldn't disagree with that.
;-)
Perhaps logic is just our way of explaining our otherwise unexplainable decision making systems.
Put in the time and focus, and one day it will just click.
models which humans will not actually be capable of understanding.
If we agree on the facts and we agree on their implications, but we still disagree, it's likely because we weight things differently. Emotions are simply a large component for how we weight things.
This has significance, it's not just a restatement of "the problem" using different terminology. It's significant because the brain, like every other part of the body, evolved parsimoniously, and it does not have spare capacity lying around, so anything that "distracts" the emotional parts of the brain will diminish rational capacity. "Hangry" is not just a pun/quip about being hungry, it's empirically measurable, it affects outcomes.
Debating rational topics with your rational friends, whether at work, at school, or after hours over a beer, it's fun (emotion), can be frustrating (emotion) but does it ever not get heated (more emotion)?
The brain is an emotional organ. All the other organs are rational, they do what they do in entirely predictable and logical ways.
think of rationality of the brain like a signed vs unsigned char in most implementations of C, basically a byte: you could think of a byte as 0-255 or as -127 to +126. The brain is an emotional organ. Rationality is the best possible outcome, but it's not the default state; the brain doesn't function from 0 to 255 rationality, it functions from -127 to +128.
I say it this way because you talk about rationality "breaking down" as if it's some sort of default. I don't think of it that way. Rationality is something we hope to build up to and are lucky to achieve, but our default state is animal passion.
I'm not trying to convince you to change what you think, just using some restatements to open your thinking to the way psychiatry views the brain.
I'm sorry, can you please explain how you come to this conclusion based on what I wrote:
"however the part of it that has "rational debates" is not an intrinsic behavior. that part is based on cognitive skill which will perform to a greater or lesser extent based on current brain state."
I'm not really arguing with you, as your first point seemed to be some kind of "but what about...!" that didn't really negate what I was trying to say. However if you think I was saying something completely different, that would make more sense for whatever it is you're attempting to "argue".
I don't think that's a problem with the emotion itself, so much as which specific events trigger that emotion and how you chose to process them and react.
Having fear does not make you lash out at users. We all have fear, often about similar things. It's having fear associating with a person calling you out, and then failing to process that fear in a healthy way that caused you problems.
Very rational people still have lots and lots of emotions. They are not robots. They can just handle their emotions in a mature, mindful way.
In those times that I have not been able to respond politely or rationally, my lack of mindfulness as well as my own emotional reactiveness to certain stimuli (e.g. triggers) was at the core of it.
that is, if a request is not triggering strong emotion in me, I don't need to employ patience and mindfulness in order to have a reasonable and rational response. If a lot of requests are in fact triggering, this is what I would term "emotionalism", and I have to work much harder to have rational responses. Hence emotionalism is linked to irrationality especially for someone with fewer emotional maintenance skills.
emotion is not a "problem" any more than the urge to go to the bathroom is, however, both require proper training to be dealt with.
Even mature people often can't reason their way out of a conflict on their own. When people feel personally threatened, sometimes no amount of simple reasoning will bring them back to rational thinking. Most of the time, the solution is to be a genuine friend--for the long haul.
However, I was trying to process whether incentives are essentially part of your principles? i.e. if an incentive to do something against your principles is so strong that it wins out, doesn't that mean you've effectively abandoned (or changed) your principles along the way?
P.S. Thanks for making Sourcehut.
Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project.
The users of open-source projects, upon which the projects themselves depend, are also not obligated to anything, and can for example (very reasonably) become angry and complain if people prioritize pet features instead of community needs, or unilaterally take projects in unsupported directions.
There is compensation for the work, and there are still social norms. Nobody cares one bit about who is entitled or not entitled to what.
> They are compensated with
> prestige,
That seems associated with the popularity of a project which is largely outside the control of an author. So: how could one publish code (just in case it's useful to somebody else, which seems to be a nice thing to do) and opt-out of the popularity contest?
> enjoyment,
People can have the same enjoyment without publishing the code, so there's nothing open source about that.
> decision-making power,
In their own project? Of course. Again, they could just keep it private, with exactly the same decision-making power - nothing open source about that.
> future employment rewards,
If a developer ships crap code, that issue seems to sort itself out automatically (who would hire a proud author of unsafe code?)
> and sometimes even money,
Those paying money certainly can and do make demands. I haven't heard claims about breach of contract in this case, so that's probably not a factor here?
Huh?
By the way, isn't this a great opportunity? The code is open. Fork it. Seize the day. Become a better maintainer, and build a community around your fork. Ensure the community needs and wants are aligned with yours. Steer that ship. Gain prestige. And money, maybe.
If someone is a bad maintainer, there will be no community, no prestige, and no money.
No. You have a right to be annoyed, and then fork the project if you want.
You do not have a right to become angry unless you're paying for it.
> enjoyment
Riiight
If you do X for enjoyment and it actively hinders some other group because they needed Y and using personal priorities to rank addressing X instead of Y is an egregious violation of community norms, people will take action to bring down the enjoyability of doing X and raise the enjoyability of doing Y, like complaining about X and thanking you for Y.
And I think that is the problem I have with this blog post, It reads to me as trying to spin it as something else with anxiety or Reddit, when what I see the problem is something very different based on principles and values.
When I evaluate a technology for its appropriateness I first look at who's using it: Literally "Who are these people and what are they working on with this stuff?" The answer to this question determines more than 80% of the decision on whether the thing is going to be my choice.
Rust seems to be being used most by people who are interested in blockchain and crypto. They tend to be of a near monolithic ideological caste, too, which has its own problems. Do I want to get into a situation where I might have my hat in my hand with these folks? Not really.
(also the rust compiler is so slow I cannot believe it)
Where did you get that from? From what I've seen every single blockchain/crypto post on Rust's subreddit is downvoted into the negatives.
That said, blockchain companies using Rust take security very seriously. It also funds cryptographic research which has a huge need of memory safety, performance and the possibility to implement constant-time primitives.
I don't see why the community of a language that focuses on safety and speed is not excited by having the language being adopted by communities which absolutely cannot compromise on safety and speed (communities referring to both cryptography and blockchain communities as they are distinct).
Disclaimer: I work in blockchain, I implement cryptographic primitives. While I don't use Rust, I do read a lot of Rust code from other blockchain projects or from cryptographers from elliptic curve cryptography to hashing functions.
My reasons can be summed up as: "public blockchain" aka cryptocurrency is toxic — it's horrendously inefficient in the name of achieving censorship resistance, so people are literally burning fucktons of energy to make perfect "crime currency" work. It has fueled the rise of ransomware (and extortion in general) and all kinds of scams. Meanwhile "private blockchain" is just like good old merkle tree/hash chain stuff, infused with hilarious/awful marketing fueled by cryptocurrency hype.
Good talk about this: https://www.youtube.com/watch?v=xCHab0dNnj4
- I agree that cryptocurrency turf fights are toxic
- censorship resistance does not equate privacy. The main blockchains today are actually fully transparent. The perfect crim currency is cash which is almost untraceable.
- The energy burn is to achieve distributed consensus. I don't think there is any distributed consensus algorithms that is not a tremendous energy burn today be it physical voting (transports, broadcasts, special machines, security, ...) or CEOs and diplomats flying around the world.
- The energy burn is still concerning but Proof-of-Work is not the only way to solve the Byzantine General problem via economic incentives. You only need a "rare resource" that cannot be easily replicated to avoid sybil attacks (i.e. not an email address). That can be cryptocurrency (Proof-of-stake) or storage (Proof-of-spacetime)
- I don't think you realize the scale of drug trafficking and other unsavory endeavors that use cash.
- Mostly agreed on private blockchain but there are some industry-wide private blockchains that are starting to emerge (including UNICEF and FAO) with very interesting applications (identity of children refugees and managing food).
None of the "other use cases" have been interesting in any way.
> The main blockchains today are actually fully transparent
So what? If the exchange between the cryptocurrency and real cash is not compromised, the only traceable thing is that some address which you don't know anything about got paid from another address which you don't know anything about.
Again, real world ransomware mostly uses Bitcoin.
> I don't think there is any distributed consensus algorithms that is not a tremendous energy burn today
Anything that is not trustless, even physical voting, should be vastly more efficient.
> Proof-of-stake […] Proof-of-spacetime
Yeah, when did Ethereum promise a switch to proof-of-steak? Where is that again? Has anyone actually proven the security of any of these alternatives?
What makes you think that? I don't believe that is true, it's like saying C++ programmers are mostly interested in high frequency trading.
edit: typo
You can easily find counter-examples if you look for them.
1. Just because a thing exists, does not give you the absolute moral right to criticize it, especially in a way that is toxic for the person or persons that created it.
Criticism affects both the people criticized and the community/universe at large, and not always in positive, productive ways.
2. Just because a thing is free, does not grant the thing or its creator absolute immunity from criticism.
Things that exist have an impact on communities or the universe in general, and people are going to be affected. And not always in positive, productive ways.
1 and 2 can both be true, and I think they are both true.
There is a judgment call involved as to when criticism is unfounded, unproductive, a distraction, and/or outright toxic, just as there is a judgement call involved as to when a thing’s existence in its current form is a net negative.
You are not wrong about user entitlement being a problem, as noted by #1, and you are not wrong in a commercial sense about maintainers not owing any one person anything.
But as per #2, I do not believe that is an absolute blanket injunction to never have an opinion about their choices or about the net positive or negative effect of the existence of the thing they maintain in its current form.
Critiquing someone's actions and choices is a founding principle of open source software, politics, and in general most human culture. "I think it was wrong to delete the GitHub issue because my belief structure XYZ" is acceptable.
Critiquing someone personally based on their technical choices is not acceptable. Reddit allows it, and thus Reddit is unusable as a social platform for positive outcomes. "I think you are a bad person because you deleted a GitHub issue" is NOT OKAY.
That distinction appears to be what led the creator to quit today, because the GitHub issue they deleted (perhaps incorrectly) contained personal attacks that linked their technical choices to their quality of human self (definitely incorrectly). I personally would have chosen to XYZ and I think they'll do so in the future if that comes up in a GitHub issue again — but focusing on that is incorrect here.
The focus needs to be on those who wield personal attacks on others over technical choices, and on rewriting communities to prohibit and evict these participants in all cases where such can be done. Shun them, ban them, and prohibit them.
Here is an entire essay touching on the subject:
https://github.com/raganwald-deprecated/homoiconic/blob/mast...
And the HN discussion at the time:
This is an understatement.
I work in regulated environments where a software error has consequences. Dependencies must be vetted. If we end up relying on a dependency with known vulnerabilities the auditors are going to want to know what we did to mitigate the risk of this out-come. You need to have an answer for that question.
I recommend packaging your upstream dependencies. That way you can patch vulnerabilities you find and ship those fixes today before those patches make it up stream. That's a risk mitigation strategy and often good enough to fend off auditors.
Many (all?) open source licenses provide the software without any warranty or guarantee of merchantability or fitness for use. None. At all.
They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back.
Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code.
Sadly, that led to some comments by people frustrated with the project, since they had likely invested considerable time at least using, if not more. But this was a situation that is entirely avoidable if Nikolay would have stopped promoting Actix as for production use.
Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Readme.
When the code is being used internally at Microsoft, it makes even more sense they wouldn’t take PRs.
If you don't like the way a project is being run, fork it and own it yourself.
I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.
However instead of raising a "don't work, please fix" bug s/he took the time to do all that.
Anyone that went to such length deserve basic courtesy, whether the code is accepted or refused.
Refusing a patch because it is "boring" is not respecting the time people dedicated to your project.
I would understand refusing because the patch makes an unwanted compromise on performance and the maintainer considers performance regressions as bug.
I have replied to logged issues with the question: "I don't work on this, unless you have set aside a budget that pays my hourly rate".
If the maintainer had said, "Hey, I don't have the time to review/test/verify this PR so I'm closing it for now," the backlash probably wouldn't have been quite so severe.
Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better".
Is that wrong?
Perhaps it needs to be said more clearly on project pages and codes of conduct and participation.
(Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales. Luckily, if you don't get the response you wanted, you can fork and hire someone else or do it yourself, and keep your fixes in the queue for others to review eventually, if they want, at whatever timescale suits them.)
Unfortunately, there seem to be quite a lot of people who would, rather than discussing ideas respectfully, instead prefer to bully and shame the maintainer.
Such as, for example, calling out perceived issues in the code publically (sometimes incorrectly), and making out how unskilled the maintainer must be, in order to put pressure on the maintainer to sacrifice their personal life and do what the bully wants.
I absolutely didn't mean to imply that. I also think that a pre-PR discussion can be useful because if the maintainer doesn't have time to say they want a PR that's a decent hint they won't have time to handle the PR.
I thought your comment was helpful and supportive.
I just wanted to clarify, for readers, that expecting anything at any stage from a maintainer can be expecting too much sometimes. It is time and work for them after all, and usually it's in their limited personal time, for free.
Sometimes, they have already exhausted all the time they could put into the project; even a brief "thanks" email is too much when you have too many for whatever available time and energy you have. People don't always realise that, when they say "the maintainer should just [...]". A lot of people wanting [...] adds up.
No problem at all.
> I thought your comment was helpful and supportive.
Thank you. I'm glad you saw it that way.
> A lot of people wanting [...] adds up.
It sounds as though you've had some tough experiences with this. I'm sorry to hear that.
He has a kid and works 8hs a day like all of us... some merge requests are two years old, he doesn't have time for all the feedback / suggestions he receives and just keeps coding in his very limited time because is what he is passionate about... people keep using it.
So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one.
With those PRs written, _anyone_ on the internet can apply them and use them in their software. I agree with GP, you aren't owed anything, and that extends to any form of social behaviors online. And let's not forget that even the most 'perfect' maintainer still deals with shit on a regular basis from the masses of people demanding features as if they got paid to write the free software people are using.
This expectation of being served high-quality open-source software for free, and then outrage when it isn't, is absolutely ridiculous and will make people not want to maintain software.
I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illegal or anything. They can choose to be irresponsible, yes. But personally, I think that maintaining the repo is the maintainer's responsibility. And I think the responsible way to do that involves "following best-practices, responding to feedback/PRs, or responding in any coherent way to anything asked of them."
I'm NOT saying a maintainer should have to add features to satiate the masses. I'm merely saying that a "maintainer" has some small duty to "maintain" a product, and also acknowledging that they have a legal right to abdicate that responsibility.
I'm not sure anyone should be immune from social criticism. They can always make someone else the maintainer and avoid any future work/limelight/criticism.
I won't touch the childish vs. adult debate as it pertains to abdicating one's responsibilities.
I am also NOT saying that people should "expect to be be served high-quality open-source software for free, and then outrage when it isn't." But it seems like it's a maintainer's responsibility to allow (and maybe even facilitate) competent, motivated individuals to contribute to their open-source project.
I also don't know exactly what the reddit brigading involved, this is the first time I've heard of this story. Harassment obviously is not okay and, not coincidentally, is illegal.
You also say "legal right" but it's incredibly vague what this is supposed to mean. Nobody cares about this stuff unless the project reaches a certain level of popularity. So once you get over 1000 github stars, should github force you to sign a contract saying you'll respond to emails in a timely manner or they take away your stars? I don't think I need to explain why that doesn't make any sense.
Instead, I am just saying that if I upload a "cool tool" to github, and I notice that it has become super popular, and I don't have time/interest/inclination to maintain it --- I would personally feel a RESPONSIBILITY, and probably social obligation (not a legal obligation) to either put a note saying "this is not actively maintained, please find an up-to-date fork. user/cooltool seems to have community support but I can't personally endorse it." or simply make some other people additional/replacement maintainers for the project which I'm not interested in maintaining anymore.
You alone decided that maintainers have all these obligations (which I would consider reasonable things to do for the record), but the maintainer of this library doesn't agree, and the license doesn't require it, so you're just setting yourself up for disappointment here.
'responsibility'
'requirement' 'obligation' 'should' 'can'
I believe responsibilities are personal/societal. They're part of a value system. However, I think I could collate a breadth of sources from landmark open source discussions which show that there are existing major themes for what a maintainer has a responsibility to do (that the open source community has a somewhat predefined value system existing wrt to topic).
I accept that it's not a consensus.
I just don't think we should conflate obligations, requirements, and responsibilities. That leads to vehement disagreements.
I agree with all of this, but I also feel that you need to be mentally prepared for any maintainer to fail to meet these moral responsibilities unless you want to be disappointed and should act accordingly (not saying you don't already do this in practice).
> I accept that it's not a consensus. I just don't think we should conflate obligations, requirements, and responsibilities. That leads to vehement disagreements.
I agree 100%.
That doesn't include any money incentives and that is likely the problem here.
Maybe `actix-web`'s author should apply for GitHub sponsorship. Maybe small sums of money every month will motivate him to take PRs more seriously.
If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.
The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.
The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages may have to include such patches themselves, effectively always being forks, never using vanilla upstream code. But this is only if you care about security a bit. If you just install from language package managers into prod, you obviously do not care about security even a little bit.
But yes, a lot of it is a legal CYA, which is important.
The problem, as I see it, is that a whole generation of programmers have grown oblivious to this implicit relationship, and when that relationship is actually exercised in some way, they default to what they understand, which is paid services and products, which results in both sides feeling like they got a raw deal.
Socially though - I don't see an issue with holding major projects socially responsible for egregious failure to fix security flaws. Public criticism is part of the open source model, it's the "many eyes" defense in action. Social pressure would be appropriate if Ubuntu just said "ahh, so, a worm is stealing every user's keystrokes. There's a fix for it but we won't merge it because we'd rather spend our time working on PulseAudio and systemd. If users want to use a forked version that will stop the keylogger, they are free to do so, but we make no guarantees our future changes won't break those forks."
Such as maintainers being overloaded fixing visible issues.
You want a security oriented distribution, you picked the wrong one.
No, there isn't.
> ...actively rejecting security patches is another level of irresponsibility.
No, it's not, because the project owner has literally no responsibility to you or anyone else in the context of this project.
If you care, you need to fork and patch the project. If you're feeling generous, you can share that fork and maybe others will use it.
No, you don't. The author doesn't owe you a single thing unless you have a warranty saying otherwise. Most licenses explicitly say something like:
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
Yet most are maintained responsibly, if they are used for serious stuff and/or advertise in a way that suggest that kind of usage can be considered.
The word "need" there is wrong. You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. If you want those obligations, get a contract and pay some money.
What's happened here, and you seem to have fallen into this trap too, is that people believe software abstractions also automatically abstract responsibility. It's certainly not a new mistake.
What this incident seems to show (and I'm not a Rust community person, I've just been reading a lot of the threads/archives about this) is not that the framework maintainer was terrible, but instead, that what he was offering was not what people assumed it to be - some people assumed the project would behave in certain ways, and have invested their time (and presumably money) in building on top of that project, only to discover that the project does not behave how they want and now they feel burned.
I believe that being an unpaid open source maintainer (which I am, and have been, in various small ways, for a couple of decades) means having a best-effort responsibility to your community, but never at the expense of yourself. That is, however, just my belief, and nobody is obligated in any way to share it.
The ancestor post about owning dependencies, while a little more aggressive than I might have written it, is basically right. You don't abstract responsibility for code just because it came neatly packaged - if you don't have a support contract for it, you are responsible for it. That's just basic logic really.
Having said all that, I do think that deleting the repos was a poor reaction - I believe (again, just me) that a maintainer should step aside gracefully when they are no longer the best person to lead a project. If there are people to hand it off to, do that. If not, archive it and indicate that it is unmaintained.
I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different backgrounds. But I think it's reasonable to hold as an ideal that there is a moral responsibility to at least make sure people using your stuff understand what they are getting into. And that such a moral responsibility would require more than disclaiming liability.
almost certainly in the framework of being employed or contracted to do engineering work. go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time.
Idk why this keeps getting tied back to paid/unpaid. I can think of many a situation where someone gets paid, and also doesn't care at all to help.
i was responding to a comment about engineering ethics. engineering is a profession. engineering ethics is taught to student engineers in the context of a job, where you're getting paid. taking the (literal classroom) lessons out of context distorts them.
if you go back to your engineering ethics professors and say "gee, but what if i do this work for fun and just stick it up on a web page on the internet", they're going to look at you like you're insane, and then not know what to say.
> If I build something in real life
the last thing this thread needs is more analogies.
As an engineer, your first duty is to protect the public, then your client, then your employer. You have that duty to the public regardless of whether you're being paid by a client or not, because it comes from practicing engineering, not from remuneration.
This is a good opportunity for you to read up on the license you explicitly agreed to in order to use said software in order for you to discover that that's precisely what you agree to when you use said software.
You don't owe the maintainer anything, nor does the maintainer owe you anything at all. The project maintainers donated their work to be used freely as is, and that's the full extent of what you are entitled to.
This is less building the playground and more providing architectural plans to build the playground with common building materials. If some part is unsound, people might also be upset, but they weren't forced to build using your plans and could have reviewed the plans themselves. Where the blame lies is much more ambiguous than how you present it, IMO.
It is when they setup an open source project that has that appearance and is framed as being such a project.
It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant to be then it should have been framed as such (such as by being in a personal repo for starters). This project promoted itself for production usage, requested feedback & patches on its project page, and had a github setup that gave an appearance of being, for lack of a better word, professional. That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project.
None of that at all forgives the name calling & mud slinging they were subject to, of course. Two wrongs don't make a right. But the maintainer was still also "in the wrong" here. They needed to hand off the project much sooner than they did when they realized they were not at all prepared or ready to handle what they promoted the project as being.
However professional and well-presentend the project is, at the end of the day maintainers are doing this primarily because they like it. If they don't like doing something related to the project then no one can blame them for that.
Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.
You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user.
Therefore, any other supposed obligations only exist in the mind of the person who has created them, and do not exist in reality.
> Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.
Sorry, this doesn't make sense, because you're comparing an explicit statement of liability in the license to the social norm of not being a massive jerk.
There's a word for people who only fulfill their legal obligations: Assholes.
There's also a word for people who expect others to meet their expectations without contributing anything on their end: Assholes.
If you explicitly state up front what you're willing to do to support a project, and I come along demand you go above and beyond your stated limitations, who is being unreasonable here?
However, I read your earlier comment as meaning roughly "anyone who releases any software under an MIT/X11 license has zero obligations to anything regarding that software period" which is something I do disagree with.
If the creator does act as a "good steward", that's great, but you shouldn't plan on that being the case or be surprised when it isn't.
There's also a word for people who stake their professional reputation on the work of random assholes on the internet.
Of course it doesn't make sense, that was my point! In the same way it doesn't make any sense to do what you're doing, which is comparing the explicit statement of liability in the license to the social norm of how open source projects are framed & run.
You missed the point that everything we're talking about is just social norms. The license is irrelevant here, for all sides. There is no legal issue being disputed.
On what basis does a developer assume this responsibility? You are saying that by uploading a library that works well, and whose presentation (docs, etc) are high quality ("professional") that the owner now has the responsibility to publicly state whether this is a personal project or not, and they must state their SLA and process with respect to accepting patches? No such thing.
> That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project.
If the maintainer says "I shall provide X amount of service" but then does not, that's on the maintainer.
But if a user likes a library and starts depending on it without checking if the library is "properly maintained", that's on the user. How can it be otherwise?
No, I'm not. I'm saying if you setup an open source project framed as a project that is production ready & open to patches with a guise of being run by an organization and intentions of having a community, then it is reasonable to expect that you actually do that. You don't accidentally make a github organization, after all. There are community norms around what you can expect when working with such projects. Particularly when then both the github page and the webpage speak of being welcome to contributions ( https://github.com/actix/examples#contribute ) and building a community.
This was not just a high-quality library tossed out into the wild that got adoption. This is a library complete with these pages https://actix.rs/community/ & https://actix.rs/code/
The author did a hell of a lot more than just "uploading a library" here. As such, the developer assumes these responsibilities because it's what they said.
You are always responsible for what you broadcast.
Though while people are ready to open issues and complain, sometimes even supply patches and make big noise if they do not pass code review, there were nobody who could join to share responsibility in making decisions about the project.
That thread is full of people trying to sign up and help. Either they all lied or nobody was accepted.
At one point it would have been code that anyone was free to use, before it becomes distorted as some bizarre social endeavour, and then people who've never used the software find themselves part of this 'community' and start to weigh in to add social pressure.
Use the software or don't; if the patches are rejected, fork it and go that way. If the maintainer won't merge the patches, because he has his own vision, you are perfectly welcome to branch out and follow your own. Or just use something else.
Having a maintainer adhere to a set of standards that only start to apply once 'the community' get involved and take control, is super unfair to the maintainer.
I don’t write Rust, I write TS. If I produced a package that was had a clean and correct TS interface, but internally was filled with dirty dirty `any`s, I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.
Why would you possibly not? Increased correctness, no change in runtime behavior, and a resistance to code rot and mistakes on your next concrete change.
Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.
That's the problem: how does the maintainer guarantee this? And when flooded with multiple such PRs, the task rapidly becomes overwhelming. If you have a robust suite of unit tests and a CI system you have better guarantees but still about as much work to ensure the new functionality is properly tested. That's not to say the maintainer's attitude in this case was excusable, but it's his project and this style of maintenance is definitely not for the feint of heart.
It's a bit disingenuous that you can accuse someone of being absurd for not doing something, and then mentioning in the same breath that you "might not want to" as well.
I'm merely saying that for the sake of pointing out that maintaining a project is a PITA and we should all really accept that.
Oh my. This was not about code aesthetics or some purely philosophical problem. It was about experimentally found undefined behavior that opened potential security vulnerabilities in the wild. The ”well it works fine so it must be correct” mentality is exactly what led us to this situation where the vast majority of critical net infrastructure code is full of vulnerabilities, the very problem that Rust attempts to alleviate in the first place. The problem with the existence of malevolent actors is that it matters little if your program works correctly in all common cases. Someone out there is going to be actively looking for the uncommon case and their goals may not align with yours.
Out of curiosity, isn't a focus on that kind of things precisely the goal of Rust? I understand your point, but this was software built for Rust, which has this kind of thing (safety, the right types, etc) as a primary goal.
From https://www.rust-lang.org/:
> "A language empowering everyone to build reliable and efficient software."
and
> "Why Rust? Reliability: Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — and enable you to eliminate many classes of bugs at compile-time."
So I can understand why someone bypassing this kind of things and then (for whatever, possibly understandable reasons) rejecting PRs to patch them because they are "boring" can be perceived as seriously mismatched with Rust's community. If someone finds this kind of thing "boring", is Rust really for them?
Note: I'm not saying he has any obligation to do anything. I'm just saying his attitude may seem mismatched with the community and goals of his chosen language, which is no small problem.
Maybe he likes rust because of other things. He had a very successful project with rust, it seems weird to think that rust was not the tool for him.
"Who cares about correctness or safety?" one could ask. Well, Rust's designers for one. It's why they created the language.
Are you kidding? Rust is a tool, not an ideology. You don't have to share in the beliefs of the tools designers to use a tool...
You can also write all your Haskell programs with all functions with type IO. You can use a hammer to paint portraits.
Just expect eyebrows to be raised.
The two rules work in concert.
If he says it's production ready, I have to assume he thinks it is. If you don't think so, you don't use it.
Open source projects dependent on a single person goes away all the time. If you aren't prepared to maintain it yourself for your use, don't use it.
Honesty is something we should expect, as well as some amount of mutual respect.
It's abundantly clear that anyone expecting him to dance to their tune was clearly lacking in respect. If you do a patch that isn't accepted you haven't lost anything, and have no grounds to complain, unless possibly if you had a prior agreement between you about you making that particular patch.
Many maintainers are absolutely inhumanly awesome, but that doesn't give us the right to expect anything at all from those who is "only" giving us tons of more or less awesome code!
If Actix is that important to so many people, eventually there will be a person and/or organization that will step up, fork the projects, apply the patches, set the principles and code of conduct (or not), keep as much "unsafe" code as they deem necessary and try to rally the community around it.
The open source creators and maintainers gave you something and asked for nothing. They are people with their weaknesses, faults, insecurities, and other passions and commitments, like we all are. Get the best of what they are willing to give, give them the best you are willing to give and they are willing to accept, and move on.
I think your choice of the verb "invest" implies a highly flawed mindset about the incentive structure of open source.
A lot of open source consumers have a mindset that by using someone's open source project you're giving them something or doing them some kind of favor. "Hey, I'm investing in your project!" You aren't.
From a maintainer's perspective, simply using a project is likely either a zero or net negative. You are not investing your time, you are using their code. You may be asking questions which consume their time. You may be filing bugs which are on code paths they personally don't hit and fixing those uses up their time. For open source projects that pay for hosting things like their repo and issue tracker, you're consuming network resources.
We have a finite time on Earth, and supporting users is time the maintainer cannot spend with their friends and family, relaxing on a beach, taking a stroll, etc.
A consumer of an open source project may cancel out that drain by offering other things in return: popularity, kind words, the feeling that the maintainer has created something that benefits other humans. Filing issues can help a maintainer fix bugs and feel good about the improved quality of their code. Pull requests can add functionality they want.
But none of that is a given and often does not happen.
In my open source projects, I have certainly receive kind words, but also many angry words in bug reports. I've had demands to spend huge amounts of time making sweeping changes, pull requests that needed be basically be rewritten, the feeling that I'm letting people down by not replying to issues quickly enough, etc.
I believe the right mental model is that if you use someone's open source project, you are in their debt by default. They have used their labor to create an artifact that provides clear material value to you. They did work. You got personal value. They clearly owe you absolutely nothing and you reasonably owe them something approaching the material value you get from their code.
This doesn't mean you need to pay them, but it should inform how you interact with them. Filing issues and sending pull requests may pay off that debt, but even then it is not a given that every issue and PR is a net help to them. Maintaining an open source project can be gratifying, but it can also be hugely draining. It would be less so if consumers were more sensitive to that fact.
This is the potential problem with “just fork it”. If the library is used by a great many products, and you know of a security vulnerability, merely providing an alternative that fixes it could be argued is not sufficient, while fixing it in the root library will patch the vulnerability in every product that has it in the next update.
It seems we still haven’t figured out (and perhaps never will) the exact responsibilities between all the parties at play.
As a pure hypothetical, imagine a critical bug was discovered in Rails that would potentially allow someone to attack any Rails website and extract personal information. Further, imagine someone quickly submitted a PR with a patch for this, such that Rails could then do a quick release and make sure it gets to every Rails consumer as fast as possible.
What if the Rails maintainers then ignored the patch, and said it was boring. Legally they are under no obligation to do anything really. And you could argue that it's on every one of the thousands of sites that chose to use Rails if they get hacked and expose user information. And further, you could argue that if people don't like this situation, they are "free to fork Rails" with the patched version. All this is fair, but I think others might say that the Rails maintainers at this point did fail in a responsibility. There are arguments for both sides, but I do not think it is as simple as "the maintainers owe people absolutely nothing" as at some point being the nexus of updates actually gives them an almost stopping or blocking power, not just the more passive refusal to fix the problem themselves.
This scenario is clearly different in magnitude from what happened with this project. That being said, my only point is that it is fair to expect a certain amount of activity in a project that bills itself as production-ready (and asks you to use it). I personally would be very weary before committing to telling someone something is production ready casually, regardless of whether the "fault" ultimately rests on them. That being said, this of course does not entitle anyone to treating others poorly, my only point is that the responsibilities and expectations are not well understood in this domain.
The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project: how much are they open to change the project's core values, how responsive on average will they be in terms of opened issues and PRs, roughly how often would they engage in technical architectural debates -- stuff along those lines.
I feel many people get toxic if they had unrealistic expectations -- and that's of course not okay.
But IMO the OSS maintainers can be a little more preliminarily proactive in managing expectations from earlier stages.
Why do you think they owe you this? You didn't pay them, and they didn't accept a contract.
When you make something that people use and like and want to improve, you should at least have the common decency to tell them beforehand: "this is my show, not gonna accept PRs".
I don't think it's such an exhausting job to write two lines at the top of the README.
I’m grateful just to see the code and choose to use it, or not. If I think some random volunteer should do something, I’ll attach that suggestion with some money or a contract or at least a beer.
What I love about open source is that it’s a big place that has lots different people. It’s beautiful because someone can write code and never talk to anyone and their code is still good and useful.
Maybe a better, more truthful statement is “OSS maintainers will have better engagement with the community if they proactively manage expectations.” And if the maintainer cares about that, it will apply. But I think there are quite a few projects that don’t really care much about community.
Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something.
Yes, I agree, volunteers don't owe anything but there are some unwritten rules that when broken should be frowned upon and I'd probably go as far as saying should be held against them.
As a reader of this, you could be thinking, wow this sounds extreme but here is the easiest example I can give.
- Someone writes library
- Library comes insanely popular
- Author refuses to allow the community to take over original project
- Author wants to maintain status, ownership, etc
- Entire community now suffers because the author doesn't owe anyone anything
"Just fork the repo", is the most common response but let's be real, nearly nobody uses the forks and every other repo that uses this popular library is using the non-forked repo.
1. Someone writes a library
2. Library becomes insanely popular
3. Users receive value out of library
4. One day, users stop receiving value from library
Is the author not responsible for the value generated by this library? At what point does the author become required to continue providing value?
"Just fork it" is an excellent response to (4), anything else is what entitlement looks like.
But ignoring good practice: a unpaid maintainer owns nothing to anyone.
In most countries they actually have written laws which require you to help in such a situation though.
"I wasn't aware someone got hit. I thought it was an animal."
What the law says & what people do :P
Imagine if the linux maintainers took this attitude.
This attitude severely undermines the credibility of opensource.
If users of opensource libraries can't have confidence that those libraries are written correctly, we might as well all go back to commercial software.
It is a simple cost/benefit analysis. Your risk of presuming that Linux today is sufficiently good for what you need to do is lower than it was 10 years ago, which is why Linux today is more popular than 10 years ago and a lot more popular than it was 20 years ago.
It's not a silver bullet, it will show you areas where memory safety issues could arise, but doesn't necessarily prove the presence of memory safety issues. Memory safety issues aren't the only type of security bug so them being impossible also doesn't mean it's entirely safe. You can think of issues like injection attacks or faulty ACL logic happening without memory unsafety.
There's also cargo-crev, which is an attempt at making a web of trust for reviews of third party packages: https://github.com/crev-dev/cargo-crev - for a longer form article on what crev's goals are and how it works, I found this explained it for me: https://wiki.alopex.li/ActuallyUsingCrev
That's correct. Here's Rich Hickey's take on it: https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
I started to suspect that this was satire with all the talk of inclusive and the use or 'unsafe'. I kept reading and reading in anticipation of gradual escalation that reveals it's satire. In the end there was none. I had to come here to read comments and to see if this was real or just very subtle satire. Apparently this is real.
I just can't wrap my head around the "inclusive community building". What happened to "Those who write the code decide everything" and "You are free to fork if you don't like where this is heading". Any free community is as much about exclusion as inclusion.
This is a nice idea, but in an era of one-button package managers it just doesn't work like that. You're trying to fight against New Jersey style. Which in the entire history of software has never been a winning approach.
The reality is that for 95%+ of active software developers, done is better than perfect. Yes there may be a small subset of developers working on super-critical defense systems or nuclear reactors. Who have the time, resources, know-how and organizational support to meticulously and carefully audit all of their dependencies.
But the vast majority of developers are not in these types of environment. The mantra of the entire tech industry is "move fast and break things". Try being a Silicon Valley startup engineer and trying to justify to your manager that you could standup functionality with one call to "npm install", but that's not sanitary and you need to audit the entire dependency tree. Now assume that the next round of VC funding for your cash-strapped startup is on the line. How well do you think that concern will go over?
The reality is that if something can be instantly installed in 30 seconds, then it will be. We can give as many "caveat emptors" as possible, but convenience trumps safety every single time.
The way to solve this is to enforce consistency on an ecosystem level. The best example of this is the Debian project. There's very firm guidelines about QA and safety before a package is allowed into stable. The Debian people are probably right about another thing too: language-level package managers should be considered harmful.
Many of these problems could be avoided if we strictly used apt-get instead of pip, crate, and npm. For one distro maintainers tend to have a lot more experience and competence at evaluating stability and safety. Two, since a system only has one distro package manager, but potentially many runtime environments, it prevents a race to the bottom. Harried developers will just gravitate towards the least strict runtime with the most low-quality packages.
This lesson is probably very tough for the Rust community to swallow. Crate is considered one of, if not the most, compelling features of Rust. If we acknowledge that it was a mistake, it really undercuts the argument for adopting Rust.
Our package managers have in-house mirrors, only validated dependencies by legal are allowed on those mirrors.
Installing in 30 seconds is not allowed by design.
The underlying contradiction seems to be a theme in software development. People who haphazardly slap together inefficient and buggy software assume the safety-critical software I've worked on must be engineered to an impossibly high standard in formally-proven Ada. We don't use Ada or formal proofs, for the same reasons nobody else does. I can say we are a lot more careful than 99+% of other projects, but we still live in the same software ecosystem everyone else does. I can't audit every platform and library we use with a fine tooth comb. A few million dollars will buy you a lot of reviews and testing (internal/external/penetration testing), but it will never be the platonic ideal of well-written software.
And Debian is a funny example for you to bring up. It's hard to take the temperature of a crowd online, but the HN attitude towards Debian's slow-and-careful releases in any other type of thread is that they're old fogies that don't understand the needs of modern software. I don't think even Debian lives up to this thread's level of code scrutiny that everyone should be doing all the time.
Of course they do. It’s not legal for you to distribute software that puts others in harm’s way. You’re not allowed to give poisoned food to homeless people as long as it’s free.
Lol. That’s about as legal as saying you can’t be arrested because you’re a sovereign citizen.
I can't agree. Not for all participants.
Let's take Linus. He's in charge of the Linux project, which thousands (millions?) of people contribute to every day. If Linus suddenly stopped merging any and all patches—but refused to officially step down—what do you think would happen? Oh, the project would more than survive—someone would fork it and that would become the de-facto new mainline kernel—but there'd probably be a couple weeks of chaos. Does Linus bear zero responsibility because he's a volunteer?
---
Every Saturday, I volunteer as an assistant teacher (they call us "facilitators") at a Girls Who Code club, a free weekly class to teach computer science to young girls. I don't get paid for it, but that's okay—the kids are adorable and teaching them is fun. The primary teacher is also a volunteer.
If we both decided to just not show up one week, and parents brought their children to the library and found an empty room, would that be okay?
Personally, I do think I owe something to those students, and to the primary teacher. I've made a commitment to show up every week and do what I can to help a group of children. My commitment is what matters, not whether it generates income.
Now, there's actually second GWC class for slightly older students which starts right after the first one. Sometimes I help teach that one, and sometimes I go home. I told the primary teacher I'll stay "when I can", which actually means "when I feel like it".
There's certainly a place for doing work without a commitment to continue, but your intentions need to be clear. Most large projects are not going to function without a commitment from someone somewhere in the chain.
One weekend in October, the primary teacher had plans to go traveling in Europe. She asked if I could cover both classes that week. I said I would, and I did.
Linux Foundation would appoint somebody else on his place and have him sign similar contract. It would be likely a person that is already employed in similar capacity - one of current paid maintainers. No fork would be needed. Linus Torwalds is not a volunteer at this point.
Linus Torwalds will leave linux one day. He wont stay there forever - most likely to retire, but possibly to do something else.
Also, Linux is particularly bad example, because most contributors are paid for their effort by someone.
Any big enough project will formalize relationships at one point or another - latest when they need to raise money or organize conference. These projects are too big to be run over the weekend, they do have to pay regular staff.
And to focus on a different part of the analogy for a moment—if somebody looks more closely at what I'm teaching students, and sees that I'm actually showing them how to use flamethrowers, yeah, they have a right to be upset. Again, it doesn't matter that I'm a volunteer, they've placed a significant degree of trust in me.
People should still audit their dependencies, just like people should observe my teaching. But it's also fair for them to have expectations.
For Rust, my personal mantra was always that _usage is contribution_. Why? Because we have a high interest in adoption. It's literally one of our top-priority goals.
But not everyone taking part in these discussions is a user or someone I have some kind of relationship with. And a relationship goes both ways.
To take your example: if a kid showed up and was _constantly_ loud, didn't respect you or showed no interest in learning? What if _most_ of the kids were like this?
Would you still like to go every Saturday?
I do teach in similar settings (RailsGirls, RustBrige) and a crucial part of the experience for me is that many attendees have a progress that they are thankful for. The deal and the relationship works, even if it is just short.
My big frustration is that the debate is often "Maintainer vs. Users", but I don't believe that boundary is as hard as people make it to be. Still, user entitlement exists and is _very_ rampant and this is what people are up against, even if they put it less nuanced. (maintainer entitlement also exists, but that's a story for another day)
I think what we are running into here is a matter where different groups have different expectations of what is owed and why it is owed, but due to the difficulty of talking about what is owed to others makes it hard for us to verbalize or sometimes even concretely conceptualize what we are talking about. There are also different extents one can owe something (legal being the most extreme, as you will be forced to by the courts with possible violence if you don't).
If a one of the parents tried to get a court to order you to teach the class on penalty of contempt of course, would you find that reasonable? This sounds quite extreme, but there are plenty of cases of owing someone something that the court does enforce in a similar manner. My guess is that you would find such an reaction unreasonable to an outrageous degree, but would find far less extreme enforcement measures (such as being disappointed) as being reasonable. I would even go a bit off topic and say that this level of being owed is proportional to the payment you receive. As a volunteer you likely get no money, but are still 'paid' in social recognition.
So you can owe something on the level of being disappointed, but not on the level of court order. So what level does a project maintainer owe others and why. And what do those others owe them in return?
I think that we could use some norms around this. Perhaps there could be an EXPECTATIONS.md in each project where we lay out exactly what to expect from the author, if anything. Maybe even specify a monetary incentive to take things further. And then the rest of us know exactly what to ask for if things aren't up to expectations. But no matter what, make sure to show appreciation to everybody who does what they do as a volunteer.
If Linus is truly a volunteer, then he owes me and the rest of us nothing beyond what he's done already. I haven't sent him any money and have no relationship or agreement with him; he owes me nothing. The chaos will resolve itself and the world will go on.
In this case there's nothing to prevent someone else from forming the code and moving forward with it, until they also tire of the abuse this poor fellow experienced.
But what exactly are the responsibilities of a maintainer? How far should you go to fix bugs? How thorough should you be about your code's limitations?
If you're doing a project just for fun, should you discourage others from using it in production?
So what is "missing" is a common way to discuss about that kind of issues, as a community, while staying civil and not in a way that is worse than the initial issue. In some cases the end-result could be the kind of the same (if most users flee), but the goal is obviously to improve the ecosystem and if managed more appropriately, it is possible that some maintainers are wanting to improve their software to the state of the art.
And a lot of the internet has this wrong, including you.
Let me start by saying that Open Source is not a zero-sum game. I can make a library like your library and it doesn't have to be an adversarial relationship. I have users, you have a few less users.
But there are costs to having more. There is still only so much space in the ecosystem for so many actors. The more logging libraries we have the harder they are to find, the more drama there is over picking one...
The best analogy I have is a party. If I throw a party this weekend, and your birthday is next month, then I'm not hurting you. If I throw it the weekend of your birthday, knowing it's your birthday, I'm kinda being a dick. That's not cool, and you have every right to be upset.
Okay, but what does any of this have to do with Open Source projects, hinkley? I'm within my rights to throw a party. But my guests are within their rights to be upset if I throw a shitty party. They showed up. They could have been doing something else. But I insisted on taking up space and now I'm being ungracious about it. It's my party and I can treat people how I want is technically the truth, just like "I can do Open Source and ignore the concerns of my users" is technically the truth.
What I'm saying is that the people who show up don't have to like it. They're entitled to complain to people about it, especially if I don't apologize and say I'll do better next time, or get help.
It's my party, I can cry if I want to, but people are gonna talk.
[edit to add]
I think the problem is that we have a bunch of people who throw themselves into software at a young age because of or at the expense of social awkwardness, and we insist on treating things and other people as if they are machines instead of people who are also just trying to do the best they can. I'm fully aware that this observation cuts against my argument as well as supporting it, but we can't go on coddling people and organizations for ignoring the very real social aspects of our work. For being poor hosts.
And it's really hard, believe me I know. But people want to see that you're at least trying, or they will paint you the villain.
If this were true in the strictest sense, then they would be free to put malicious code and trick you into using their stack just to then steal credit card numbers from your database. Of course this is not true, and they would appear to at the every least owe us "good faith" or perhaps some basic guarantee that they are not purposefully trying to criminally attack you. This may seem like a useless edge case to bring up, except for the fact that the law does have some amount of consideration for negligence.
Arbitrary people you don't know owe you nothing too, and yet if you walk onto their premises and get hurt, the law has found in certain circumstances that they are indeed at fault. Expectations and responsibilities evolve with time, and as new scenarios come up. It is not clear to me that putting up a project that invites people to use it in production could not be argued to some extent to be negligent if it willfully blocks and delays fixes that could affect real world customers.
At the end of the day, if people were using my code in production, and a discovered exploit was used to steal people's data and I could have prevented this by merging in code that wasn't 100% to my aesthetic liking, then I think I would feel bad. Fault isn't binary, maybe its the fault of a random company using my framework for not being up to the minute on all vulnerabilities and manually patching the code themselves, maybe its their fault for using my framework in the first place given the youth of the project too. But I don't think I would go to sleep that night feeling great is all I'm saying.
I'm not super familiar with this particular case, but the OP blog post was phrased as kind of wanting to open up a dialog or discussion on the nature of these issues. I am bringing up some thoughts about this stuff I've had for a while and I think at least help to understand some of the moving parts involved. For the record, I don't really know where I stand "absolutely", or if its possible to have a clear principle that doesn't take into account some number of additional variables (how the project was portrayed, how many users it has, etc.).
> 1. YOU are responsible for your dependencies.
This contributes to the prejudice against `unsafe`. If I wanted to be a full-time auditor, I wouldn't be steering clear of C and C++.
Since I'm a responsible coder, I avoid depending on `unsafe` outside of `std` or the simplest of FFI wrappers with extreme prejudice, to the point where I consider NIHing an alternative or just sticking to a managed language with a more mature ecosystem, depending on the project.
Language design that forces users to lie to the language leads to this. The classic is C's "a pointer is also an array" mindset. When you write
int read(int fd, char* buf, size_t buflen)
Rust had so much promise, too.
I suppose I’d agree if you’re making a general argument that most of the software we use is broken to some degree, but it has an entirely different meaning to directly tell someone “Your library is broken”.
The next argument is literally the length of the array.
In all seriousness there is quite a difference in structures that allow themselves to have guarantees built into the language/tooling (like including the size of the array in the languages basic "array" building block) vs. the more manual book-keeping the C code above requires.
there are things that you either
can't express, or are very hard
to express, in safe Rust.
- decidable (indeed fast) type-inference/type-checking
- simple typing system
- you don't pay for features you don't use
It is easy to get rid of unsafe blocks if you throw complexity at Rust, e.g. use dependent types and / or theorem provers, but all the obvious ways of doing this immediately violate the constraints above. Doing it within Rust's constraints is an open research problem.
potentially fixable.
I would be happy to help with implementing & writing up such work. I have quite a bit of experience with sub-structural types a la Rust. I have spend some time thinking about this problem space, but didn't manage to crack it. I have an incoming PhD student whom I could ask to help with this.
The question I'm asking is, what do you really need to do that you can't do in safe code. On the memory safety front, for pure Rust (no calls to C), probably not all that much. Maybe only this:
- Syntax for talking about partially initialized arrays. For a collection, you have a variable that indicates how much of the array has been initialized, and you need a statement in the language that ties that variable to a partially initialized array. Then you can do simple inductive proofs to show that as you initialize another element and add 1 to the counter, the entire array is initialized. Non-consecutive initialization would require more complex proofs. Is there a real use case for that? One with major performance implications, where initializing the data to some null value would be too slow?
Un-initialized blocks of types such as raw bytes aren't a problem, because those types are "fully mapped" - all bit combinations are valid. Only types that are not fully mapped an initialization guarantee.
- Backlinks. Backlinks in doubly-linked lists and trees obey some simple invariants. You need syntax to say "this is a backlink". That implies an invariant that if A points to B, B must point back to A. Everything which updates A or B must preserve that invariant. The pointer from B back to A then no longer needs to have ownership of A. (It's a problem that Rust doesn't have "objects", because such invariants are usually required to be true when control is outside the object, but can be broken momentarily while control is inside it. The inside/outside distinction is important for this, and Rust is a bit soft on that. Spec# took inside/outside seriously, but viewed it dynamically, rather than being tied to static scope. Haven't looked at that in years.
What else do you really need? Remember that some knotty ownership problems can be resolved by allocating the objects in an array which owns them, and using array indices for relationships between the objects. It's not like you have to use pointers.
Concurrency is a related issue, but I've said enough for one night.
simple inductive proofs to show
that as you initialize
another element and add 1 to
the counter
Perhaps the communities that don’t “do community building” don’t need to because they already have a healthy community?
Perhaps the projects that do community building are starting from an unhealthy place and fighting an uphill battle?
Or perhaps some percentage of the “community builders” are the ones who like to rage/shame anyone who, even unintentionally, causes any offense? Which naturally escalates the conflict.
Which way does causation run?
The Common Lisp community was pretty much the opposite of the Node/Rust crowd. Everyone was different. Lots of people were using different implementations of CL. Most people even had their own custom editors. And of course everyone had their own DSL of macros they carried around with them, so basically everyone had their own language. The supposed toxicity of the CL community was from the constant arguments because they all had strong opinions different from each other.
If this were the CL community, there would be 20 different versions of actix-web or something like it. There would be no need to create drama and make whiny demands of other people, because everyone in CL actually knows how to program.
The tor project was like, the most dramatic project on Internet for a while till they started to focus on community a bit more.
So I don't think premise holds.
If I in the past would have felt I needed to send a patch to the lkml, I wouldn't have felt intimidated because if my code would've gotten shredded to pieces, I was in very good company. The lkml also didn't really brigade, or bully, even if people sometimes was quite emotional. However, for some people I'm sure it would be hell.
There are however several projects with extensive guidelines that I would feel intimidated to interact with, as the power struggles and infighting is likely to be well and alive although I can't see it, there's also a brigade of attackers available to anyone who manage to convince them I was in the wrong.
Community guidelines unless expertly written and religiously enforced are unproportionally useful for those with either a manipulative streak, or those with good social and language skills, as they often grant them more power. In this respect mirroring society. However, apart from keeping the most blatant misconduct out of the open, it also becomes a weapon to be used against anyone less adept at navigating the social hierarchy. Thus, the extent to wherever a particular community ends up, in reality becomes almost inscrutable to the casual observer.
For me it's the same in real life, in contexts where the societal norms are somewhat displaced I have few issues. The selfish, aggressive, and other bad actors stand out like they would wear neon colors. In society in general, in the workplace, I have all kinds of issues because amid all the unspoken rules there will always be one that can be sufficiently well misapplied to defuse valid criticism.
We don't get pathological liars voted into various offices because people are good at arguing rationally, but they also tend get to stay there because they are protected by the rules, unless the rules are expertly and independently applied.
1. Open source creators own the package and they owe you nothing. Most (all?) of the major package repositories follow this model.
2. There are very few ways to officially fix a major dependency if the creator(s) take a powder beyond cajoling or forking and attempting to maintain it yourself.
3. Many people are using VERY complex and important packages that, frankly, they may not actually be able to maintain themselves. I fall into this category for some packages that I use and I'm sure most people do, especially on small projects.
So, you are left with hoping the OS creator stays on top of things or cajoling.
Once cajoling fails, and you are in a bind, a bind that may threaten your job and career; things get ugly. It's not right, but it's human nature and it's predictable.
I'm identifying the problem, I really don't have a solution.
As an indication of that, I've been implementing an ownership/borrowing system for D. I expect to see some of the same issues you brought up. But for the people that want to use it correctly, it will produce the benefits. And that's what I care about.
Don't worry about the haters. If I paid attention to them I never would have accomplished anything. People are always going to misuse a tool.
And some good news, the first stage of D's Ownership/Borrowing system was pulled today!
Eventually it's mutated into, "I'm making something really cool in the local park. I'll be there on weekends!"
I had to bake in the perception of not "owning" my creation because yeah, at some point it needs to grow well beyond what I had the time/energy/capability for. I'm also very human, and very insecure about my competencies, and as the youngest of three brothers, am defensive by nature.
Now practically speaking, how do you accomplish that in the open source community? I wish I knew.
Equally, if you see someone complaining on social media about something that doesn't effect you, then mind your own business. But let's be clear - most people can't be trusted to do that.
Social media has taught everyone that they get to have an opinion about everything, and not just to have an opinion but to go and find the people involved and tell them. That is a completely broken culture- and its actively encouraged by places like reddit and twitter.
The other part that works well for me is disassociating your self from your project. Set strict hours for when you will work on the project, and don't work on it outside of them. Note that checking issue emails counts as work; remove your "work" email from your phone. I'm lucky enough to be a paid developer for the project, so I can clearly define my working hours as when I'm in the office, and ignore issues when I'm not at the office. But even for personal projects, there's no need to respond to issues within hours, or even days, if doing so is burning you out.
And the obvious answer that applies to anyone who creates anything online: Don't Read The Comments. In this case, that means Reddit. Reddit is a cesspool of uninformed users giving maximum visibility to whatever is most appealing to other uninformed users; not a good place to get useful feedback. Find spaces that are supportive and provide useful feedback, cultivate them, and spend your time there.
I have no idea why some projects gets toxic attackers while others are almost entirely spared. One thing which the project prioritizes is taking the time to explain to people why their ideas which look good on paper may actually be missguided.
Personally, I don't think you really can. I think the best thing to do from a developer/maintainer perspective is to identify toxic communities and do you're best to ignore them entirely. That's probably the best long-term approach from a mental health standpoint.
Especially when it comes to social media sites like Reddit, once a community turns hostile there really isn't anything you can do to turn it around.
Life is too short to deal with shitty people.
Individuals can't force societal behavior; it's a social/group issue.
2. Perhaps actix focused more on TechEmpower benchmarks (if you follow fafhrd91 on GH, you'd see the number of times he forks TE's repo, presumably submitting PRs). I think having a library that's #1 for many benchmarks attracts users, not all of which will be hobbyists working on toy projects. The concerns (some valid, most not) about unsafe were bound to be there.
3. The dismissal of `unsafe` alternatives was often a challenge (from the comments that I saw, especially before his first instance of walking away), which wasn't handled well by "us" the religious cult. I don't know why he came back after the first instance last year, but what many of us saw was the toxicity of Reddit when it came to actix. I think fafhrd91 asked for people to co-maintain last time, which did see an increase in contributors.
4. Part of us building a community will be many of us acknowledging that "Performance" is not the sole goal of every Rust project. There are sometimes people who will suggest a huge deviation in a project because of some micro-optimisation or because they want a feature which might not make sense for everyone else. So I hear what you're saying about the hardships of maintainership because things can go pretty wild if one tries to please everybody. Unsafe is also still 'young' in that more tooling around it will still be worked on over the years/decades. How will we know if we're being restrictive on a feature if we forbid it?
5. Reddit is toxic. People on Reddit are toxic. People are toxic. We are toxic.
A good principle for us to follow when we type things on the internet is to ask "would I say everything this way to a person if I was standing next to him/her/them"?
Good luck Nikolay, I wish you the best, we have learnt a lot from you on what's possible in our little community.
- Language theory enthusiasts, a famously pedantic group
- Systems programmers, a famously exclusionary group
- Unwashed masses of web developers who have never done either of the above before
Frankly I'm amazed it's been as civil as it has been
This viewpoint is, of course, unrelated to the community discussion here. I mean other languages have unsafe (or c's void *), but they don't appear to fight about it. I don't mean to say anything bad about Rust. But it seems to attract people who want the absolute best performance at any cost. IMHO. May be I am wrong. That may be something Rust people can try to change??
If you are unhappy with the direction an Open-Source project is going, you can do two things:
1. Tell, in a civilized manner!
2. Fork, if you are willing to spend the resources to maintain such a project yourself
If you are unable to formulate your critique in a neutral way, then keep it to yourself (aka STFU). If a maintainer decides he doesn't want to follow your suggestions, you should be nice and stop. After all, you still have option two.
And if you are unwilling to spend the resources to maintain a fork, how dare you to tell someone who invests his time and shares his results, what he has to do.
Congratulations, Rust!
I mean this with no trace of irony. With maturity comes being used in ways you didn't intend, and might not want, even with unwelcome publicity. Rust will sail through more of these, and more, and they will cease to shock. People who care will start to pay attention to modules' underpinnings, and start to keep track, and certify. It takes a lot of conscientious people caring to uphold that, but maturity brings them.
Rust is designed to a high standard, and it takes extra work and extra armor to maintain it, just as it is worth the extra effort to learn it. It aims to be worth that, so we cannot begrudge that without betraying its purpose.
But .... I think it is showing that the premise of memory safety in Rust is working. Stuff that would go unnoticed in C and C++, is being identified and called out in Rust. Does it lead to drama, personal conflicts, etc.? Maybe. But from the perspective of the potential Rust user it's a proof that it `unsafe` keyword works, leads to higher scrutiny of potentially dangerous patterns and that the culture of other Rust users takes reliability, security and safety seriously.
Let's take an extreme example: I write some program for common use and intentionally introduce a security hole or make it participate in bot-nets. And don't tell anyone about it. Am I "free to write it because I like it"? Well, in some sense, maybe, but it would also be something extremely problematic for me to do. Certainly everyone would scream bloody murder when it gets found out.
So, in a less extreme example, there's still some measure of responsibility of mapping out what and how you've vetted, and not making false claims.
What's less clear is security holes (which are not malware as such) or just "putting code out there" ("not in common use", although someone could come and pick it up and start using it). I would defend your right to write exploits and backdoors and bots and put them on github.
Simply making a security hole is IMHO OK unless you have intent to exploit it (or let someone who intends to exploit it know about it).
The difference, for me, is in writing versus deploying. And I'd consider it deploying if you intentionally post malware to a public repo you know people will run (without knowledge of having malware in it).
Contrast with building a trap (and maybe showing it to people) and stashing it in shed, versus building a trap and priming it and putting it in the woods where you know kids like to play. Not a watertight analogy, I guess making traps could be illegal just like making guns is in many countries. But you get the idea. I think you should be allowed to write malware or make combat knives or mantraps for fun but don't put them to their respective use.
Of course, going down this line of reasoning is a rabbit hole. If you build something on your yard (something that isn't illegal per se and has no intention to harm anyone) and it turns out to be dangerous and someone gets hurt, you might have to take responsibility (but it really depends on a lot of factors and would be decided on a case by case basis). I'm not sure I would like such reasoning to be applied to FLOSS projects that come with a warranty disclaimer and which can freely be audited by anyone who intends to use them for real. It's not like they hurt you just because you happened to stumble upon them.
If the project owner just wants to use Rust as a fancier C, just for a few niceties, and mostly code in unsafe, that's their decision to make.
Perhaps one could call it "the unsafe Rust community." ;)
I'm 80% through building an API using actix-web. Time to reassess whether or not I should start over - wonder what my client will think if I bring that one up? I hope there is a community fork with enough momentum to keep the project alive.
Ignoring the drama around it, there were some very serious security concerns with the liberal use of unsafe.
Open source gives you access to source code to do with as you please. Storing your own copy is a good idea if it's something critical to your endeavors. The possibility of having to maintain anything of that nature yourself is always a risk.
Expecting, demanding, or begging for anything except what the author willingly, and happily takes upon themselves is exploitation, pure and simple.
If you think about it, trying to coerce an author/maintainer into doing anything they willingly and explicitly have commited to, is no different than employing bullying, group pressure, and other social/psycholgical manipulation techniques to get whatever outcome others deem useful to themselves.
Yes, something as trivial as complaining about the lack of response to a question can easily be seen as being abusive when there is no established relationship or expectation, no quid pro quo, or similar.
Getting free access to someones work is amazing, and nobody should ever have to face what so many maintainers have to face today in the form of unreasonable expectations and outright bullying.
Plenty of people do exactly that: they point to work that they've made available for free on their GitHub as proof that they have the required skills and attitudes for professional work. The former Actix-web maintainer also used to do this, via their LinkedIn page. You can't have your cake and eat it too.
If I link my stuff or show it to a prospective employer, it's meant to show them that I can code. Nothing more. If they want to read too much into it and dismiss me as unprofessional because they found a cat meme, Theo quote, or link to hello.jpg, it's their loss not mine. Fuck 'em. Kinda unprofessional of them.
I used to lead a volunteer organization. I had many people depending on me for what I provided. Eventually, it became too much and I needed to step down.
A) I could have just left, let the organization collapse on itself, burnt every individual, organization and volunteer that depended on me - and just said, "doesn't matter was a volunteer organization."
B) I could have taken the time to ensure that there is a system in place such that the organization stays afloat, supporting the individuals, organizations, volunteers that are dependent upon it while it finds a new leader.
Either of those choices were mine to make - but I wouldn't be surprised at all if someone called me unprofessional if had picked A.
Why would he be obliged to do it in a professional way? He's not being paid.
That is their own problem.
> I'm 80% through building an API using actix-web.
Feel free to pay someone to maintain it for you.
If you want a committee to answer for maintenance and philosophical debate or whatever, then fork and form an organisation for it... if not, leave people alone ffs, a one person authored project that got popular does not deserve this, abandonment is the only outcome.
Classic Eternal September.
Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new users mimicking other new users, and the culture shifting towards the platform's identity instead of retaining the sub's identity.
Generally, the type of person to post on Reddit frequently enough, has social cohesion problems that may preclude him from fulfilling his social needs through more healthy avenues, like real life. The same is true for the majority of people that post online frequently. Usually the pyschological profile that follows that point is one built on abrasiveness, distrust and aggression towards authority, an inability to adopt social manners and participate in social contract, low emotional intelligence, etc.
All of the aforementioned behaviors culminate into the toxicity and vitriol you usually see -- and as well why it's so prevalent.
In my experience, these larger communities typically grow less tolerant of antisocial behavior, most likely due to acceleration of the process known as "dogpiling". Trolls get more exposure, and better reactions, in small-to-medium communities.
It's still conjecture, but I think I prefer my hypothesis.
Armchair psychology? No, I've made many friends and acquaintances, both online and in real life. The ones that bubble around posting online heavily, have developed antisocial tendencies that were reinforced through social exclusion. A self-fulfilling prophecy. I know this, because I know those people well and because I was there at one point in my life as well.
Neither is it condescension. Perhaps I may have been in-exact and may have offended some that do post online very regularly, but there must be a distinction between what they consider "regularly" and what I consider "heavily." Heavily, in my observation, is someone that puts aside a significant amount of time, usually involuntarily, to do nothing but interact with online communities for the sole purpose of social interaction. No value judgements were made either, but those characteristics are common among the aforementioned group.
I won't address your hypothesis, because I'm not here to argue.
This would still qualify as anecdotal data, and thus armchair psychology. Now, it works perfectly valid as a hypothesis and can be rigorously tested and determined if data reject or supports (fails to reject) it. But without peer reviewed research, that last step hasn't happened.
It also sounds good. Makes sense. Fits our notion of common sense of how humans works. The problem is that psychology is filled with examples of where these kinds of intuitions are wrong.
My connotation of armchair psychology is more informal and doesn't match the more rigorous, APA definition.
I'll make one note: the psychological profile I wrote of, is based on first-hand experience, as well as pieces of mental notes recovered from internet-addiction and FBI profiling papers.
Please edit out name-calling from your comments on HN, as the site guidelines ask: https://news.ycombinator.com/newsguidelines.html
Your comment would be fine without the first sentence.
1) [T]he Rust project saw Rust as more than just the language...
2) unsafe... is a really important part of Rust, but also a very dangerous one, hence the name.
If a project is considered to be not just a project, but something closer to a cause, people are going to defend their understanding of that cause fervently.
And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst.
People who perceive themselves to be defending a cause against danger are going to react very strongly, much more so than people who are criticizing an implementation choice on purely technical grounds.
Using the antonym of safe was a natural move, though with the benefit of hindsight, `danger` would have been a better keyword.
After all, good unsafe code isn’t unsafe! It is dangerous though, because it forgoes guarantees of memory and resource safety provided by the compiler.
Is it really a value judgment? Coming from a formal PL background, I had just assumed that the "unsafe" keyword was referring to the PL concept of "safety", AKA "soundness", which has a specific technical definition, and not that it was necessarily a value judgment. In that context, "unsafe" just means "the compiler can't guarantee the behavior that it can normally guarantee".
That doesn't mean that people will incorrectly interpret it, though.
The issue was that by the time this was recognized, there was too much Rust code, and there was no clear alternative that people universally liked. This kind of conversation is the definition of bikeshedding. I submitted an RFC and it... didn't go well. (I think I picked "trustme" though.)
The `unsafe` function type modifier can be left as unsafe, or renamed to unsound, since that what that is doing is stating that a particular function is not always sound to call.
Given the background of the people who designed Rust, I don't think it's reasonable to just assume that the keyword "unsafe" has an implicit value judgment.
`unsafe` is a PL term that refers to _soundness_. In Rust, an `unsafe { ... }` block is required to perform an `unsafe` operation, and it precisely means "The code in this block has been proven _sound_". If the code in the block turns out to be _unsound_, e.g., because the proof is incorrect, or non-existent, then the whole program is unsound, and there is nothing that can be said about the execution of such program (usually known as "the execution exhibits undefined behavior").
For example, the Rust compiler has a lint that requires you to write a soundness proof on every `unsafe { ... }` block, explaining why that is sound, and all changes to the compiler are gated on that.
In your own projects, you can obviously do whatever you want, but for any non-trivial amount of unsafe code, without a proof, you are basically just building castles in the air.
We also have tools that change for this for very large projects (e.g. cargo-geiger), and tools that help you test your proofs (e.g. cargo-miri). For some unsafe components, there are also proofs in Coq, and the proof systems for Rust unsafe code are making a lot of progress in both defining the rules that unsafe code must uphold in the unsafe-code-guidelines and the Rust spec, as well as in providing example proofs and a standard library of theorems that you can reuse for your own proofs.
?
Any B.Sc. in CS can do most of the unsafe proofs in a one liner. All crates I maintain require unsafe blocks to be commented with a proof, for most of them the proofs are trivial, and for all of them that weren't, the unsafe code was correct, and the correct one had a trivial proof.
You mean like making sweeping generalisations about a platform with millions of users?
Hey hey hey, "aggression towards authority" is not a psychological trait, but at most and pattern of action. Also, I disagree with your implicit maligning distrust of authority without generally distrust of others.
> ... and participate in social contract,
The claim of the existence of a "social contract" is part of the self-justification of authoritarian aspects of social structures in capitalist democracies.
If that statement is true, you (and me, and everyone else here) have those same issues, surely?
Maybe this because some members on Rust subreddit believes that they are more intellectual than others? It seems like a cultural thing, go people don’t bother to be seemed as smart or so and that’s possibly reduce the aggressive competition that naturally arise in places where intellect, high performance etc are very important metrics?
Not an exclusive characteristic of a reddit user, there are many different levels and types of authority. Perhaps the aggression towards all authority, or weighted to certain personalities of authority rather than the ones in the background, especially the ones that don't really matter i.e. internet forum moderators
I agree with your general point that reddit fills a social vacuum in people's lives, like most social media does for others in different ways. Validation and expression etc.
Personally I think think that's why society in general has become generally more toxic, everyone is really telling it straight to others but not being honest with themselves.
My favourite counter-example is /r/AskHistorians. Over a million members (16x larger than 60k) and it has some of the highest quality posting and discussion I've seen anywhere on the internet. I think it serves as a prime example of how a well a forum can scale, if done properly, so long as there are strict rules and moderators.
I think Reddit is interesting because its design is more resistant to Eternal September than other communities. See the trend of creating r/TrueX when r/X gets Septembered.
Unfortunately, this hits diminishing returns when more and more obscure subreddits need to be created. Tons of oddly specific niche subreddits have popped up and completely gone to shit in a flash. I think we're nearly due for the next migration (maybe a federated alternative?).
Sam tweeted at me recently about this situation: https://twitter.com/sstephenson/status/1167856878673694728
Sometimes I think the Web was a mistake, and that none of us are ready for the scale that it brings.
Nikokay isn't the problem. His indifference to soundness concerns is inevitable; Rust pragmatically doesn't preclude reckless programming and that's a good thing except that some people will, in fact, be reckless. The actual problem is the naive expectation that Nikokay's indifference and recklessness can somehow be fixed by the 'community.' It clearly can't. The 'community' needs to sack up and fork stuff until it's happy with the work.
Reddit has become such a toxic place since they optimized the platform to make money.
Why don't those idiots just fork Actix Web and make a "no unsafe" version of it? Instead of harassing the author, who has devoted so much of his time and talent to building this great piece of software?
What was the patch? It was very strait forward, simple, uncreative change, intention was just to remove unsafe not to fix existing code. I believe software development is one of the most creative work we do, and creativity is part of why we love software development, why it is fun. Especially if you combine it with real world projects constraints. “creative constrains” could be source of very interesting solutions. Being on the edge of your abilities is super fun. So uncreative change felt boring https://github.com/actix/actix-web
Assuming this is true: What's the problem with that?
The impact of that patch would have likely caused actix to no longer be at the top of the techempower benchmarks.
Today is the first day where I say to myself, okay, has that happened?"
I think it depends on how you define community. I used to think Rust was going to be able to go mainstream. Now I'm wondering if it isn't niche. In other words, infrastructure needs code too, but all of the code "at the edge" (ie. applications that interact with users) may not be the perfect place for Rust. And I feel like that's where the majority of code will be written. So, maybe to produce metrics on this I would start with "where is the primary activity", and discover within that niche whether or not Rust has positive trajectory in terms of "market share" of that category of applications.
As the Rust community grows, how can it ensure that people use 'unsafe' tastefully? Well, in general, it can't. But maybe Cargo could exercise some editorial control, and delist (or flag) packages that don't follow the "community standards". I'm not saying this would be a good idea, it's a tradeoff. But you can't force open source volunteers to write code in a way you like.
Maintainers that don't care don't have to use the badge (even if their project does in fact avoid unsafe), but the choice to include the badge acts as an implicit signal of intent. When I see a crate with green CI status badges (or in this case a green safety badge) that's a signal I can use to help judge whether I want to depend on the crate.
No one needs to be flagged or called out if they're not interested in that aspect of maintainership.
I think the hard part is that actual quality is a spectrum and no-unsafe-at-all isn't necessarily the best goal for many crates. So ideally the badge would show some more granular safety score. But scoring effectively is difficult, and the so is correctly interpreting a heuristic score.
Thanks Steve. :)
This is generally a bad thing. It leads to NIH, to poor portability, to difficult integration in other dev environments etc... But it does mean that you carefully consider every dependency that you must use. The quality of the packaging is often an indication of the quality of the code too, a well polished build system inspires confidence, a crappy buggy bespoke shell script less so.
Meanwhile take this example: I've re-started working on a PlayStation emulator a few weeks ago. I haven't reached the point where I need to display images or output sound, it's pure algorithmic code with no I/O so far. That's 0 dependencies.
But then I wanted to add some basic logging infrastructure to be able to do 'warn!("this thing shouldn't happen")' or 'debug!("this register has value {:x}", val")'. I could just use println! but, hey, adding dependencies is super easy and I'll end up with more flexible and expressive code, so let's do that instead. So I add these two lines to my Cargo.toml (note the simple in simple_logger):
[dependencies]
log = "0.4"
simple_logger = "1.3.0"
Compiling autocfg v0.1.7
Compiling libc v0.2.66
Compiling log v0.4.8
Compiling lazy_static v1.4.0
Compiling cfg-if v0.1.10
Compiling num-traits v0.2.10
Compiling num-integer v0.1.41
Compiling atty v0.2.13
Compiling time v0.1.42
Compiling colored v1.9.0
Compiling chrono v0.4.10
Compiling simple_logger v1.3.0
Oh and beyond that Reddit is a terrible place that manages to be the worst of 4chan and the worst of Facebook in one convenient package and should be avoided at all costs, but we already knew that.
Be warned: unsafe causes both bugs and anxiety - excessive use will lead to at least one biting you.
If not ... I get the idea he wasn't really welcoming of the changes but at the same time. It's his code man.
I came from the world of networking and etc and the world of programming has a great deal of personal preferences / hypothetical problems / "we don't do that at my workplace" stuff pushed under the guise of technically correct ... sort of technical bullying.
Under that sometimes there's little room for mistakes / other points of view, other working styles, and etc... and it's really horrible.
Rust will survive without actix, but losing it is a setback for Rust in the web space.
To me the important part is that we as programmers start advertising our intent. If the intent was to learn how Rust works, then we should write that in the description. Instead we write things like "very fast and lightweight framework". To many people fast and lightweight is good enough. Many other people would also like dependability and sustainability. So please, just put a little label on your github project.
All my open source projects, for example, are exploratory. None of them was meant to be used in production unless you tested rigorously that it would work, and that is on you then. There is nothing wrong with that, I think, as long as you communicate it up front.
People are just importing open source libraries with flashy sounding descriptions left and right, and then they find out those were unfinished and crash all the time, or the author ignores bug reports, or will not maintain it anymore, or thinks it's ok to switch the APIs around on you, breaking your ability to upgrade without reworking your application.
Again, there is nothing wrong with that. Just be honest about it up front.
But when you open source a project, you are opening yourself up to criticism and critique of your work. You are opening yourself up to that in basically any form the internet wants to take it, and sometimes that really can be shitty.
We have a very promising project making use of a language that has gained popularity largely based on marketing around memory safety, and then that project has unnecessary and flawed use of something that undermines the messaging around rust. This is a risk for Rust - a promising and popular project in a popular space that undermines some of the core rust messaging is a PR problem for the language. The maintainer not being receptive to contributions to resolve this difference is a problem. The maintainer not being receptive to contributions that fix SECURITY ISSUES is a MAJOR problem.
Open source maintainers are, of course, volunteers. I don't think we should hold them responsible for the fact that there are bugs in their code, or even security flaws. People aren't perfect, and no one should be expected to be, especially when contributing something to the open source community. But we SHOULD hold them responsible for not fixing security issues. It's irresponsible to release something to the public that you know puts them at risk.
So is it fair for people to be upset in this situation? I think so. I also think their reaction should be a polite one - but it's totally fair for people to push someone to take responsibility for code they've introduced to the world that has security vulnerabilities in it.
There is a cost to using software that goes beyond money exchanging hands. The maintainer has no legal obligation to do anything, but acting as if someone having an issue with software having security vulnerabilities is someone being entitled is a childish reduction of the interactions in play here, especially when people are taking the time to write code that resolves the issue.
It at least makes it very clear to those who have not paid for the maintenance that their position is silly if they make demands of the maintainer. It is his project and he does as he pleases. Why is that difficult to see?
One could perhaps persuade him to accept a patch but like any endeavour where you need something from another person, either you offer them something in exchange (which they value enough) or ask nicely and see how it goes.
In either case, it might still fail. In that case, one can of course try and do the same with _someone else_ who might be more receptive. This is possible with free/open-source software.
What you consider a "snarky retort" is just the same thing said in a different tone.
If the current maintainer isn't doing what you, or "the community" wants, you fork and make the changes you want to see, and maybe eventually work with a group of people.
Maintainers are under absolutely zero obligation to the people who choose to use the code, unless they've specified as such in the license or some other contract. It's the only thing that lets FOSS software be a thing in the first place.
I feel that any open source software that I have released I have a moral obligation to fix any security issues, or if I am unable to for some reason, clearly stating that they exist. It is irresponsible to leave your software available with a known security issue.
> > it's up to you as a developer to vet your dependencies
> This is effectively impossible on an individual level, and it's something that absolutely needs to be a community-level effort.
Don't hire this person... Dependencies are absolutely, FULL STOP, your responsibility. YOU are the one making the money NOT the maintainer.
I do not believe that anyone is entitled to free features/bugfixes/etc on foss projects but apparently this is not what happened in this case.
If people don't want to use an unsafe library, don't. If their patches aren't getting merged, clone it.
If reddit is being meany-heads, don't login.
I really don't understand what the point of this post is. It's arguable whether there's a problem, and if you take the author's point that this is a problem, no solution is offered.
Likewise, it's just as annoying when you submit a PR on some random thing because you see a legitimate bug or unhandled case and the maintainer starts demanding you do more free work for them to do 100% they way they would have done it. Just say "thank you", accept it, and make those superficial edits.
The price point here is free. This is essentially a gift economy. Just because some random strangers on the internet have an interest in the same few bits of code, doesn't mean there is an obligation to do free work or twist someone's arm.
I think, as an outsider, both side had its wrongs and corrects, the author could consider changing unsafe code and the community could be at least civil.
As a personal opinion, i can say that we have to consider the fact that the authors of open source software are mostly doing it for hobby or fun. And if we ever want to keep open source alive and magnificent, we should be very civil and and at least thankful for the programmer and their time.
The only way out i see that could solve the issue was to fork the project and do the desired changes there. I dont know why they did not do that when it got to that point.
I think most people kept hoping they weren't at that point, and could actually move forward without forking.
In closing, here's a nice little gem from the OP author's final blog post on his old blog[0]:
> if there’s one thing I’ve learned from writing software, it’s to blog about error messages.
Cheers.
[0] http://blog.steveklabnik.com/posts/2015-07-05-ember-data--ds...
I hope I'm not the only one who just realized that "A Sad Day for Rust" is also an example of "[blogging] about error messages" and appreciated that statement even more.
I don't think the negativity was necessary, that said, if it wasn't a significant impact to performance but did potentially improve safety, many of the patches should probably have been brought in.
Personally, I've been more drawn to the likes of Rocket and Yew. The former for the server because I really like the interfaces and usability. The latter, I haven't done much with, but think it's pretty cool and a relatively small starting point for a WebAssembly based UI experience, compared to say Blazor.
Hope the people who caused this are happy now.
In terms of quality engineering, the "page of assembly" strategy is the one that I think has the most merit. Write out enough machine-level code to boot the machine and provide an environment for some higher-level language. This should take about a page. Rinse and repeat until the higher-level language is high-level enough for comfort. VPRI supposedly had made this technique work for them. This would cleave Rust into two or more languages, though, and I gather that a big selling point of the language is the ability to compromise and allow many different safety perspectives into a single codebase.
I'm not Miyazaki; I can't just tell you that unsafe-blocks were a mistake. But clearly and obviously, to anybody watching who has considered design and implementation of programming languages, they were a mistake. Further, they're the same mistake as Safe Haskell. We keep making this mistake, as a community of designers and theorists, and we need to do better.
But they do need those. Even C# has unsafe blocks, and Java has sun.misc.unsafe. It's a rather boring feature actually, the interesting part is what you can assert about safe code, and at what cost.
The double edged sword of open-source: We can't cooperate with one another if we don't know how to behave and deal with other people. Emotion can never have the final say. Because emotion is raw, uncontrolled, knows no boundaries, doesn't know right from wrong. Especially if it is selfish emotion. Those that act like this are bound to harm themselves and others;
Can anyone link to a discussion in which the actix-web maintainer explains his position at a technical level?
The article leaves me baffled at why the maintainer was so unreceptive to concerns about the use of unsafe.
There just has to be a a way to summarize the noise such that it is indicative of pushback. There has to be a way to have a discussion without attacking each other when the disagreement is only on a detail.
You inevitably get disappointed. Good. Now you can evaluate and see if a different outcome is even theoretically possible.
When you hope, you lose :) It doesn't mean you cease hoping, it just means you don't do it so strongly. It's too much. You know it's too much, so just let go :)
Well if the project isn't FOSS anymore I can't see Microsoft continuing to use it, which makes me question the accuracy of this statement in the first place.
I don't know what kind of licence actix-web had. Seems to have been some open source license and not a free software license, according to the "postmortem" readme file, where the author says: "I am done with open source."
What stops anyone from using a fork to develop further? Did the license not permit that?
If somehow that was not permitted or not possible, because no one created the fork before it was moved to "private repos", then I think the author did something quite childish , taking away the possibility for others to continue developing the software, just because he is fed up with enduring the criticism. "You don't like how I run the project? Meh, I'm going to take it all away from you!" (That's how it sounds, when you move a repo to private after and because of criticism.) Ideally any author, who works on an open source project, knows, that they give up some control over the code and would not act this way.
I do not say, that the shit storms were justified or good in terms of their social aspect. However, if all of this managed to make actix-web safer, then at least that aspect was a good result.
If you think loading your expectations on to an unpaid volunteer and then harassing them over it will work out, hopefully this moment is a good learning experience for you.
(Unfortunately, I can see from reading the comments that not everyone is getting it.)
Perhaps someone should create an OSS contributor agreement where contributors explicitly agree to work long hours, for free, in perpetuity, prioritizing issues based on reddit heat, and see how many developers agree to those conditions. Those are the expectations that appear to have driven this developer to quit their project.
BTW, for those that don't know: acting on bug reports and accepting pull requests is often a lot of work in its own right. Bug reports are often vague, incomplete, contain incorrect assertions and assumption, lack clear steps to reproduce or even a clear description of what happened vs what was expected. It takes time a effort to clarify these things. Even then you may need to, e.g., build an environment to reproduce or correct the issue. Changes from developers that aren't highly experienced with the project typically have gaps, new bugs, misunderstand requirements, don't build, ignore style conventions, lack unit tests, and have various other issue that have to be ironed out before the change can be accepted. It's all a lot of work.
Each issue could have a donate button. The bounty would be split to the authors that contributed, with some remainder left for unfinished work (documentation, unit tests, etc).
To settle how the bounty is split for multiple authors, they could go through an anonymous round of "bids" to propose splits, with the bounty locked until they agreed. Maybe the maintainer/reporter able to settle disagreements by choosing a split ratio that lain somewhere between the range of those bid on.
However, in this case patches and reproductions were submitted and rejected as "boring". Whether the author really meant to use the word "boring" is neither here nor there, the result was that the fix was ignored, even though that's how open source works!
I've watched from the sidelines with no skin in the game (I use Rocket) and my conclusion from all of this is that the maintainer should have created an actix committee or group of maintainers to help shield from the inevitable bugs and issues that crop up. If the OG author wanted to step back to take a break from all of this, then fine, the rest of the group can continue to churn and work.
The original article that called out the behavior also called out other incredibly popular crates, like reqwests, for their underlying HTTP stack, yet there's not a shitstorm about those libraries. The obvious difference that I can see is the maintainer response to said criticisms.
EDIT: I also want to make clear that I hated the comment about never writing rust again. I'm not condoning that behavior at all
E.g, "...that's how open source works!"
That's your opinion, but what obligates the developer to adhere to this?
If the question is, was this a professionally run OSS project I would say, certainly not, and I assume almost everyone would agree. But so what? Why should a maintainer be expected to run an OSS project to a certain level of responsiveness or spin up a governance mechanism if they can't do it on their own?
> The obvious difference that I can see is the maintainer response to said criticisms.
I would suggest that reddit mobs are almost entirely capricious, random, and irrational.
Was this a professional project? Absolutely not. But was this a personal project? I would also say categorically "no", since it wasn't scoped under his personal github profile until recently. I'm very saddened to see something that could have been solely community maintained be revoked instead of there existing a potential mitigation plan in place (for example in the form of a foundation or Org) for situations like this, especially since this has happened twice before and it's sadly caused burnout for the main developer. Again, no obligation to do this but why can't I say "man, that's true that he could follow these actions but that's also shitty" at the same time?
It's in open source but it's affecting everyone who posts their work online, which is to say, anyone doing anything that's publicly visible, anywhere.
Fork the project and un-unsafe it.
The first is that the Rust community on Reddit is in a feedback loop of groupthink and outrage, making it into a powerful vector for harassment. The maintainer of the actix project had a particularly terrible experience of escalating harassment from the users of this subreddit, and its extremely sad. This has caused a lot of grief for the maintainer of actix and prevented real (but far overblown) code issues from being fixed in a productive way.
But I think Steve undersells the absurdity of the unsafe anxiety. Some Rust commmunity members are conflating two wildly different scenarios together. The first is a library exposing an API which, if used in an unlikely and contrived way, could result in a program using that library containing undefined behavior. Then, since that program has undefined behavior, it could contain a memory bug. If that were the case, someone could potentially exploit that bug to attack a user of that program. You'll notice this is a series of conditional statements - its a funnel of decreasing probability.
So yes, library APIs which can allow UB in safe code - even unlikely and contrived safe code - must be fixed. The goal of Rust is that safe APIs can never cause UB. But people should have a proportionate understanding of the risk profile of these bugs (again: a programmer using this API in an unlikely way could create a program with a bug that could potentially be exploitable). This is a miniscule increase in the risk of another heartbleed, it is not the same thing as heartbleed.
The spark that lit the kindling of the toxic Reddit community was a blog post by Shnatsel, a member of the RustSec team. This blog post didn't get attention here, but I want to take a moment to look at how ridiculously it frames things by examining its analysis of a different project: reqwest (sort of the most standard HTTP client library in Rust).
Here's the link: https://medium.com/@shnatsel/smoke-testing-rust-http-clients...
The fuzz test, which is what the library is about, found no security issues. It found some hangs in 6% of cases and Shnatsel traces them to a known deadlock issue. This is a great result.
But Shnatsel spends most of this talking about a custom hashmap implemented in the http library, which the RustSec group did a security audit of just a few months ago. That security audit found only two issues, both UB that would result from a contrived use of a minor library API (they are linked in the blog post, but not explained). These two issues were fixed, and the fix released, by the maintainers of the http crate in 10 days.
This is an incredible success! The security audit of a foundational library found two minor issues which were promptly fixed, and the fuzz confirms that the entire stack on top of it seems to contain no memory issues. Wonderful result, but how does Shnatsel frame this?
> First things first: it didn’t segfault! I am actually impressed because I had really low expectations going into this.
Come on! The blog post is full of these kinds of snide zingers which are totally unfounded in the face of the actual evidence presented. When you have someone writing in this disingenuous, meanspirited way about open source maintainers and then putting this in front of a groupthinking rage machine community like Reddit, of course you're going to get harassment. This behavior is totally unacceptable, and it's very sad to see it promoted in the Rust community.
- The map needs to be a multimap.
- Insertion order needs to be preserved.
While `std::collections::HashMap` is an excellent HashMap, it is not a good fit for HTTP headers.
No doubt, having to contend with this issue is frustrating for all parties. I think it’s important however to help people feel heard and respected even if we don’t agree with them. One of the burdens as a pillar of the community is the necessity to rise above that frustration (articulating it in an emotionally intelligent manner when necessary) – to focus on educating, and hearing constructive criticism.
That said, candidly it’s not helpful to talk about using snark as a means of being heard. It’s like saying “I’ll put down my weapons after you put down yours”
Let’s not bury the lede here: people are coming to Rust because they see, and are excited by its potential. They are passionate about making the language better. I think we should hear them, search for patience, and disagree without being disagreeable. We will go a LOT further together through collaboration than we can through divisive rhetoric.
With all due respect, you are not the universal arbiter of "crappy"-ness and "hacked-together"-ness, nor is anybody else. My guess is that you have concerns about the library, and you are absolutely within your right to say so. Your concerns may even have significant substance to them; or perhaps there is additional perspective that could change your mind.
Unfortunately, presenting your view and judgement as a statement of objective fact not only shuts down potentially valid counter-argumentation, but it's also inflammatory/insultory because it misrepresents your agency in the situation, and diminishes the efforts/personhood of those who contributed to the library.
It's understandable that you might want to use such phrasing as short-hand from time to time, but saying it out loud, especially in a public venue is regrettably demonstrative of a lack of self-awareness. It drowns out your message regardless of its merit, and pushes other people away. It's a reductive way of thinking, and it does everybody (including yourself) a disservice.
In the words of Groucho Marx "I don't want to belong to any club that would have me as a member."
We could all choose be sour and jaded, fighting over scraps in a futile search for self-worth –OR– we could each take it upon ourselves to be the standard-bearers of what was, and hopefully will remain, a warm and inviting place for meritorious debate. I choose the latter.
A document describing the principles the maintainer tries to uphold?
Running software is always more of a performance than an institution.
Besides, perhaps this would reinforce the notion that unsafe is - by its very nature - a bad thing. To quote Klabnik:
> it turns out actix-web is using a lot of unsafe code. That’s not inherently a problem. The problem is, a lot of that unsafe code is not actually needed.
If the code were actually needed, then there's no benefit in printing this metric - it just makes a project that is using the feature perfectly correctly look bad.
Also, a fascinating Trumpian "both sides have good people" -defense play.
What should you expect in this case? What is the best possible response?
2. The actix framework author supposedly did the following things at once:
2.1 Wrote code somewhat carelessly
2.2 Wrote and maintained his code alone
2.3 Claimed his code was "safe" - in that mythical complete sense I mentioned above
Caveat: I'm a C++ person and am not familiar with the Rust ecosystem.
Unnecessary drama because of inflated egos.
1). It should be considered RUDE to contact a solo maintainer in any way relating to the project (email, issue, pull request, etc.). You should ALWAYS fork the project and use the forked project on your own terms.
Most people write their projects, on a whim, on a Saturday, for a bit of fun. They do not want to be shackled to a hobby for the rest of their lives.
2). Opening an issue and opening a pull request are IDENTICAL requests for effort.
Think I'm wrong? How many people were so incensed by this renegade maintainer that they FORKED the repo?? Why didn't people FLOCK to the safer fork? Why did people still care about the original repo??? The answer to those questions underlie the fundamental problem of open source. No one wants to do the work. People want to work on what they're passionate about. But they don't want the responsibility of ANOTHER FULL TIME JOB.
An issue is a request to write "native" code. A pull is a request to maintain "foreign" code. I have never had a large, successful open source project. To date, I've had one repo with ONE issue and ONE pull request. Both required more effort than I ever wanted to give.
I have stopped opening issues completely. If a project is maintained by one person, you will never hear from me. Large projects with paid maintainers will receive issues because I believe it the only appropriate time to do so.
---
Here is a simple flow chart for contributing to a solo maintainer's open source project.
1. A problem has been discovered.
2a. I do not know how to solve the problem. -> Move on. Don't reach out to the maintainer in any way.
2b. I can write a fix for this problem but I don't want to maintain this project in its totality. -> Move on. Don't reach out to the maintainer in any way.
2c. I can write a fix for this problem and I want to maintain this project in its totality. -> Fork it. Don't reach out to the maintainer in any way.
A project by a solo, unpaid author should be presumed unmaintained.
- "rewrite it in Rust" kind of posts on a lot of threads
- upvoting Rust mildly or not interesting projects just because there are written in Rust
- down voting every comment that even slightly criticize Rust (this comment will be gray when you'll read it) or remind that code safety exists in VM language for decades
The borrow checker is actually fast, the part where you wait for hours is the code generation. There is nowadays also a "cargo check" command which stops before the code generation, which you can use when you want only to see if it would compile without errors (without waiting for it to actually compile).
It doesn't matter if code is full of secbugs, author doesn't like patches, or whatever. Code is open source. You can't make it look like your vision. Fork it.
Of course, no one in the mob appears to have had the wherewithal to do that.
It seems to me that there's a clash of expectations/worldviews, both happening in this thread, and in the wider portions of the interwebz involved in the kerfluffle this article is about.
A comment[1] from ddevault states two things:
> 1. YOU are responsible for your dependencies.
> 2. Open source participants are volunteers and owe you nothing.
The above is true. But there's another aspect here, that of cultural norms, implied goals and the expectations derived therefrom.
By my observation of mailing lists, hacker's blogs, my own attempts at contributing to various projects, and other things, there's come to be a set of expectations of the authors, maintainers, contributors, and even to some degree, users, of FOSS projects. These expectations are not set in stone; they can be shaped by the statements and actions of the maintainer(s), implicit or explicit, or the lack thereof. But there is nonetheless a default set of expectations. A set of social norms, if you will.
One of the expectations I've observed, and discovered I myself had absorbed through cultural osmosis, is thus: A maintainer should make clear what a project's goals are, and earnestly consider patches/pull-requests offered in good faith support of a project's explicit or implicit goals. They should communicate clearly technical facts, concerns, and considerations when discussing or debating an offered patch. Said discussion should be focused only around the technical facts as they relate to the goals of the project and the offered patch. And if the patch is rejected, the maintainer should clearly communicate why. Said communication could be a long essay expounding on the technical trade-offs the project has had to make, or a simple link to a FAQ entry covering why such-and-such common patch type will never be accepted. (In that latter case, presumably the earnest consideration of that patch type had happened sometime in the past).
A related norm, one tying back in to ddevault's post, is the contributor's end of that exchange. One offering a patch should accept a rejection with grace. A contributor can and should be willing to discuss and debate and try to persuade a maintainer how the offered patch actually does align with the project's goals after all. But he should do so only with technical facts and logical argument, not fallacies, emotional manipulation, name calling, threats, or other such juvenile BS. To persist and pester after a final decision has been made is a violation of that norm. Thus, it is as equally gauche for a contributor to tell a maintainer to die in a fire after a rejection as it is for a maintainer to state he doesn't accept patches from people who voted for the Labor party in 2017.
None of the above invalidates ddevault's assertions. However, IMO, social norms serve as a sort of oil on the machinery of the human interaction inevitable in collaborative projects. A person rightly gets upset when those social norms are violated. But, there are right and wrong ways to respond.
From what I've seen of this kerfluffle so far, it is a violation of those norms which led to this mess.
Recall what I said about a project's goals, above. Rust's explicit goals of memory safety, thread safety, etc, IMO carry with them an implicit goal of making for secure programs, by making it easier to avoid the kind of mistakes that cause programs to become insecure. I'm not a rustacean, but it seems to me that at least part of the wider Rust community is working on making that implicit goal an explicit one. And so, by building your project with Rust, that goal of a secure implementation transitively becomes one of your project's goals, at least implicitly. If it's not, you had better explicitly state otherwise. And if you do, I don't think you should be particularly surprised when some push back.
And so we come to the violation of social norms. I can't find any before-the-kerfluffle articulation of actix-web being a for-fun project. So, actix-web was seen as having the goal of being sound and secure, by virtue of being implemented in Rust. And here was Nikolay's virst violation: failing to make clear the goals of the project. If after that first instance of 'unresponsive maintaner', as steveklabnik puts it, Nikolay had made clear his main goals were being fast as possible and winning the benchmarks, that soundness and security were non-goals, and he had firmly and politely held his ground on that, I think the kerfluffle could have ended there. If he'd made those goals explicit then, then other users would have been able to take a look at the project, and see that all that Unsafe code was probably not something Nikolay cared about changing, and so know they need not offer patches for it.
But since that wasn't done, we come to the next violation: not earnestly considering those patches offered in good faith -- or at least seeming to. Because of the impedance mismatch between Nikolay's actual goals and those seeming goals of actix-web, he seemed to not take seriously those patches offered.
As I said above, there's a right way and a wrong way to respond to such things. And sadly, the response by some was to violate the contributor's end of the bargain: accepting a patch rejection with grace. By responding with out-of-line remarks like "please stop using Rust", the quality of the discourse degrades, and shit rapidly gets toxic.
I don't think it would have been a violation of norms to call out all the use of Unsafe, and the various ways it was unsound, or even to advocate that others should not use actix-web, so long doing so stayed fact-based and did so somewhere other than the actix-web bug-tracker. As far as I can tell, the smoke test of HTTP clients did that. I haven't dug deep into the Reddit thread, but if there was personal attacks on Nikolay, I'd not be surprised.
What have I learned from this, despite not being part of the Rust community? Well, if nothing else, it highlights the importance of clear communication. In any future projects, I will need to make what my goals (and non-goals) are as clear as possible. I will also need be willing to clarify things when there seems to be an impedance mismatch between my goals for a project, and what a contributor thinks they are or should be. And I'm going to have to develop a thick skin and the ability to de-escalate, because some people are going to respond with perceived rudeness from me with deliberate rudeness of their own.
Perhaps that's a naive take on it. I welcome suggestions on how to improve it.
Its easy to create blog posts and comments about RIIR, its not easy to actually write code.
If anybody actually wants to fix this issue and prevent it from happening again, I'd start by instantly banning /r/rust users for 3 days anytime they do a circlejerk.
Who the fuck cares if the package maintainer does or doesn't do x,y, or z.
Either make the patch, submit it, and launch your fork when it gets rejected, or look for such forks. Anything else is just masterbation.
On another note: it seems like this entire mess was based around a bunch of peoples inability to see that "can" != "does". The fact that it can be vulnerable because it doesn't do something that makes being vulnerable impossible does not in any way mean that it is in fact vulnerable.
This is like the time somebody came to our repo with a bunch of pep8 linter warnings and treated them like high severity issues.
"good practice" != "must do".
There are people who forget that open-source does not entitle you to anything (read the fucking license).
Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without someone trying to stir up a lynch mob. It sickens me the lack of balance between the work done by the maintainers, and the expectations of random users.
My brain is, well, lets say "broken" in this respect.
I could have open sourced a fair bit of code over the decades, but I haven't, largely because the option of entirely ignoring people isn't really available for me at this time. While I obviously try to work to get to a point where it is an option, I don't know if I ever truly will be able to publish my own projects.
While I now won't get bothered much by people calling me an idiot, or being asses in general, the self righteous expectations people apply to open source maintainers still just breaks my brain.
People freely give out their labour of love and sweat, and other people have the gall to hold them to higher standards than we hold most of society?
It's just too obvious. As soon as the balance of power shifts, a sizeable fraction of the population becomes the tyrants of their "peers". Can't deal with that, unfortunately.
Sure they are. There's a number of projects out there with a massive caveat on the front page that says "Not for production use". They are then more than free to close issues with comments like "Hey I'm researching a new refcell implementation, thanks for finding this, but I'm more interested in speed than safety at this point."
Actix did not put up a disclaimer, and in a lot of cases, either closed issues/patches without comment, or with a somewhat demeaning comment. It was not just published as a fast and safe production ready web framework, it was promoted as such, so the author should expect patches in that vein.
There were multiple bad actors involved here, but it stems from a maintainer who took issue with anyone finding problems in his code.
> It sickens me
> I am disgusted
Almost sounds like you're... outraged? Perhaps trying to build up community outrage?
>not naming any individuals
>talking about a cultural phenomenon, not a specific incident
>no intent to force anyone to change
https://old.reddit.com/r/rust/comments/epzukc/actix_web_repo...
https://old.reddit.com/r/rust/comments/epoloy/ive_smoketeste...
I get that people hate Reddit around here, but pushing this on them as vitriol by the Rust community there is wholly unfair. The impression I've gotten is that the developer of actix used unsafe too much, made no attempt to inform users that his framework was thus not safe to use (to the level expected of a Rust project), and rejected plenty of PR's where these issues would've been fixed, while being belligerent about continuing to write unsafe code.
https://cdn.discordapp.com/attachments/648807492931026953/66...
He'd even started deleting comments and entire issues just for pointing out unsafe code. And it seems like he's had the archives deleted, since the archived pages which used to exist are no longer accessible (I didn't even know that was possible?).
http://web.archive.org/web/20200117043715/https://github.com...
Frankly, after years of seeing people defend C/C++ projects because "well, just get better", I think it's a good thing that security-consciousness is at a point where developers are being rightly criticized for playing fast and loose with security. There are always complaints about how we have no idea what kind of code being used on NPM or other package systems. But make some effort to improve it and now they're the bad guys? Oh, come on. You can't have it both ways.
And as somebody else has already pointed out, plenty of other projects also had PR's regarding safety issues, as linked by the original article which tested all these projects. The actix author is the only one who rejected them, and he's the only one facing complaints.
Aside from maybe the second to last comment, I don't see anything here that deserved deletion.
I feel like in any language, beginners are more than encourage to write things in said language. Yet when working on language internals, you need to be more careful. Reading the Firefox programming guide on what's allowed/not-allowed in the C/C++ codebase is pretty eye-opening[1]. Have there been issues with core Rust developers not being kind or following their CoC? The author doesn't really include examples or explore this line.
As far as Reddit: I stopped using it the moment one of their CEOs altered someone's comments during the election and was not asked to step down. That CEO is still there. Reddit had their warrant canary removed years before that. All their original values are pretty much gone and they've gone on a community banning spree over the past few years. It's also no longer open source. I'm fine with any community rejecting this as any kind of official communication platform, but no one is stopping enthusiasts or hobbyists from using /r/rust
If actix-web has unsafe code and the authors are not accepting patches, and someone feels passionately about it, they could create a saftix-web fork, include all the patches, and maybe even develop it independently or pull in changes from upstream.
It sounds like things went down terribly, and that's sad. Was it just Reddit people, or core devs? I agree it doesn't help to attribute blame, but the author doesn't dive into where the problem might have started and what could have been done differently. I wish this had some more explicit examples of how the community screwed up, the things they did right, the things that could have been better. But then again, that could lead to call-out culture BS. I feel this article is missing some depth, but it's also something that would have probably washed over without the author going out of the way to write this piece. I dunno. /shrug
[1]: https://firefox-source-docs.mozilla.org/tools/lint/coding-st...
That was not a CEO but a founder, AIUI. Can't really fire them or ask them to step down, they literally own the place.
There's a better way. It's coming.
This blew my mind. I had no idea this was happening! I really hope Rust continues to evolve. Still no idea why JetBrains wont adopt it officially like they did Go.
I don't like the idea of Rust, C, C++, or Assembly for directly web-facing services. Any non-GC language should be a non-starter. There are literally (uncountably?) infinite ways you can have memory errors in a native program. The consequences of any of these can be devastating because absolutely anyone can access your endpoint. Notice the asymmetry: One small, unnoticeable error can lead to devastation. Like running across of a field of sparse landmines, eventually you will get destroyed.
Lol. That's the thing about IOT - the 'S' is for security, right?
The possible runtime states of a program (expanding every branch/subroutine recursively over all threads) is uncomputable. (Otherwise we would have a solution to the halting problem and be able to correctly free memory at compile time.) I'm not sure if that's the same as being uncountably infinite. It's probably a different concept.