January 18, 2020
The developer of the Rust web framework
actix is “done with open source”1,
as you might have already seen on Reddit2, HN3, Lobsters4, or somewhere else.
Steve Klabnik5 has said a few words, and Raph Linus6 has some suggestions for how to avoid something like this in the future,
but I don’t feel like either of them (or any other write-up of this I’ve seen) does a proper job of addressing what
I think is the real “issue” at play here, hence this post.
Edit, 2021.06.22: some months later Drew DeVault wrote a very relevant post aobut exactly this; also see other posts on his blog.
Here’s a quick rundown of what happened.
Person makes web framework.
It gets some traction in the “community” and is often in benchmarks, where it does quite well.
However, it uses
unsafe liberally, and is not 100% secure from invoking UB.
This is a common complaint of the framework, and people have tried to get patches that addresses this merged in.
The maintainer doesn’t like the patches.
People get angry, and insults are thrown left and right.
Maintainer takes their ball and goes home.
Let’s do a Q&A-esque thing, in no apparent order.
This pops up every now and then, which is strange since I’d assume that it was common knowledge that others being assholes doesn’t give you the permission to be an asshole yourself.
Yes, but a maintainer has no obligation to accept any patches coming their way. They also have no obligation to explain why.
Actixwas high up on Some Benchmark, so the maintainers have a bigger responsibility
A programmer doesn’t have to defend their code when it’s compared against other code.
If you think, maybe rightfully so, that
Actixs usage of
unsafe made an unfair comparison in a benchmark, then
that’s the fault of the authors of the benchmark. They are comparing apples to oranges, in that case.
Of course, if the benchmark is simply “Which web framework written in Rust is fastest?” then this shouldn’t be contested at all, as
Actix definitely is written in Rust.
Actixwas well known in the ecosystem, so the maintainers have a bigger responsibility
If The Community have chosen
Actix as a valid representation of how Rust can be used, then so be it.
It does not seem to have been a secret that the author was relaxed when it comes to safe-proofing the code;
when it has become such a high profile project, that seem to speak for itself when it comes to whether Rust
programmers really care about “safety over all”.
Actixwas professional-looking, so the maintainers have a bigger responsibility
This does not make much sense to me.
Having a polished landing page or
README.md does not somehow magically imply that the project itself is polished and ready for indefinite use by anyone.
The author have not implicitly made a promise on anything related to their code.
Almost any licence clearly say this.
As is their right. None of us have any right to post any kind of content to another persons bug tracker/wiki/“digital property”. They are in charge. If you don’t like it, don’t use it.
Actixwas not “sound” and therefore bad
I’m not sure I like this craze for soundness. One of the big selling points of Rust for many people is the safety combined with the low level control. However, sometimes these things are simply at odds, and it’s not clear that going with the safety all the time is really the best way.
Taken to the extreme, if some library was, for any practical purpose, useless, unless one did some
unsafe trickery which
also caused some adversarial code to invoke UB, would this library remain useless and safe, or would we just say
“don’t use it that way, then”?
It seems to me that the consensus among Rust programmers is that any safe code should be safe under any usage. I fear this greatly limits the potential of the language and its ecosystem8.
Actixwas not “sound” and it hurts the Rust ecosystem
If the ecosystem of a programming language is so fragile that a single project which values aren’t completely aligned with a large part of The Community is enough to bring it all down, then we should just pack our stuff and go home. There would be no reason to continue doing any of this, if Rust reputation depended on that all users of the language was equally evangelist about it.
This seems to confuse
Actix, which as far as I understand is pretty much one persons library, with a community project.
Actix does not belong to The Community, and the author has no obligation to The Community to give it to them
when The Community feels like it.
That “Contributions are welcome” doesn’t change anything at all; it is still not a community project.
Taking this concept to any other situation reveals how crazy this idea is: if I invite people over to my house for dinner and tell them that contributions are welcome, they are in no right to take over my kitchen if they disagree with the way I cook.
This is simply ridiculous, because it implies that the moment someone publishes FOSS code they are automatically subject to rules governing how they should deal with the technical decisions in their project.
It also seem to imply that being a maintainer sets a higher bar to what is social behaviour than merely being a contributor or user. There should be no differentiation here. Be civil, always.
There are plenty of good reasons to use Rust that does not concern safety at all, as I’m sure any Rust programmer would be able to tell you.
The author of
Actix chose to write Rust. That’s okay, and they does not have to explain why.
This certainly does not give anyone the right to tell them that they should not be writing Rust.
Actixwas labelled production ready when it had soundness bugs!
See the other comment about soundness. I would guess that almost all of the system code running on the device you’re reading this on contain what you in Rust land would call soundness bugs. Yet, it is very much in production.
If you have committed to using third party code without any backup plan, you have already screwed over yourself. For very popular libraries this usually is not a problem, since, in case of maintainer rage-quit there are a lot of other people with the same needs as you - it’s a kind of safety of the herd. Ideally, the only change most users would be affected by something like this is that they have to wait a little longer on the next release, and update the repo url. That’s it.
I don’t care who was an asshole or not, and I’m not here to put labels on people; I just think that most of the comments I’ve read on this event has had a lot of things in the FOSS world backwards.
I don’t think a FOSS author has any responsibility over their users. If you don’t like how they’re prioritizing patches, handling criticism, or tuning to win benchmarks, you don’t have to use it. Nobody is forcing you to use this code, and if someone is, you have (potentially) valid concerns you can raise.
If you want to bring in third-party code into your codebase, then that is your responsibility as a developer. If you don’t trust the authors you should seriously reconsider using their code for anything more than a weekend project9. You don’t get to complain if the other developers take down their code10, leave bugs unfixed, refuses patches, or deletes tickets from their bug tracker. In fact, you don’t get to say anything at all except “Thank you!”.
Don’t be an asshole.
Thanks for reading. Thoughts and comments are welcome in my public inbox.
I still find it strange to have people flock around a tool and call it a community. Each to their own, I guess. ↩︎
I can’t dig it up now, but I’ve read a blog post about how some C++ concurrency primitive tries to detect whether any other threads have been spawned and takes a fast-path without any synchronization if not. The author provided an example of this behaviour being faulty, but under adversarial conditions. In my opinion, this is a perfectly reasonable approach for the library in question to take, since under any normal working condition it would behave as intended. ↩︎
This is in my opinion one of the last big blockers for proper package management; it’s sad that the web-of-trust approach somehow didn’t really work for PGP, since that would be the first approach to consider for package management as well. ↩︎
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License