This last issue, which included a patch, has pushed them over the edge after it descended into disagreement.
Net/net they were repeatedly asked to change coding style, didn't want to, and have decided it's better to just avoid the arguments by not publishing code.
What is hard about this?
Don't like it, don't use it doesn't really apply to security vulnerabilities in such major packages.
Flaming and personal attacks are not the solution to this stuff, but this drama feels somewhat self-inflicted.
Please investigate yourself, don't ask others to do the work you consider important for you for free.
They're under no obligation to upstream your patch, but it's open source so you're not powerless either! Why so much drama over a rejected PR?
Now, in a case like this where the maintainer won't accept patches, yes, fork and move on would have been better.
Let's not start victim-blaming please.
Yes, the maintainer could have made his reasons for making the project more clear, and the maintainer could have been more clear on the intended use of the project (not for production, personal project to see how fast Rust can be, etc). There are a lot of things the maintainer could have done.
However, that doesn't mean there wasn't a problem. There was a ton of negativity around "unsafe" when the author first released the code, and it has kind of become a meme at this point. If a project consistently uses code in an unsafe way, is it really worth spending your time vetting it for your production use case? There are plenty of web severs out there, pick one that aligns with your goals.
For future maintainers of projects, please do yourself a favor and clearly state the intentions of your project. Is it for production use or just a personal project to see how far you can take an idea? Make it clear and get into the habit of reminding people of the project's goals. I am very grateful for projects that do that since it helps me save a ton of time for both the maintainers and myself.
There seems to be a mismatch between the maintainer's expectations of the project and the community's expectations. It's unfortunate that the author decided to pull it, but hopefully this is a lesson to the community to make sure a project is a good fit before diving in with suggestions.
Should people wait until credit-card data or PII is leaked due to security vulnerabilities? The problem with security is that it impacts more than just the programmers using the framework, it impacts everyone. Does the author deserve the nastiness? No. Do security issues need to be reported, and if not fixed, called out? Yes, for big and advertised projects issues like that need to be reported. If not, there will be users that would naively expect the web-framework they're using to be somewhat secure.
The framework had a professional looking website advertising the project, it had good documentation, a user-friendly API. It advertised a actix open-source community. Had over a million downloads. I would say that expecting actix to be run like a somewhat professional project is not a strange assumption.
The way it was called out was pretty terrible though, and I doubt anyone is happy with what happened.
The author can write their entire code in an unsafe block for all they care. The buck stops with those that use the framework and that is made quite clear in the license.
Time to close up shop folks, we didn't personally perform a deep security audit of every single open source project we depend on!
Some people just never "grow up" and/or learn how to treat people with respect, and developers are not special in that regard.