Computer science, programming, and whatnot.

Actix and FOSS Responsibility

January 18, 2020 back to posts

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.

<Maintainer> was an asshole

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.

But The Community7 didn't just complain, "we" even submitted a patch!

Yes, but a maintainer has no obligation to accept any patches coming their way. They also have no obligation to explain why.

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

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

Actix was professional-looking, so the maintainers have a bigger responsibility

This does not make much sense to me. Having a polished landing page or 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.

But <Maintainer> deleted GitHub issues!

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.

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

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

<Maintainer> should step down and let someone else take over the project

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 behaviour should not be acceptable for any open source maintainer

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.

If they don't care about safety, why are they even using Rust?

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.

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

The <Maintainer> screws over people depending on their code

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.

Why are you defending <Maintainer> when they were an asshole?

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.








  7. I still find it strange to have people flock around a tool and call it a community. Each to their own, I guess.

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

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

  10. You know which Javascript library I'm thinking about

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License