If this is the issue, one of those forks will become the new mainline repo everyone contributes to. Expecting a maintainer to behave the way the community wants is unreasonable. Maintainers are not public servants.

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.

> If this is the issue, one of those forks will become the new mainline repo everyone contributes to.

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.

Just as you shouldn't eat everything you just picked up from the sidewalk, you shouldn't just use any code thats available out there.

check, check and check again...

What is "a timely manner"?

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.

> The problem was that PRs which would have fixed security issues where not accpeted.

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.

Based on the noise the "maintainer shall/should/must/ought to" crowd is gigantic. It should not be an issue for this group to fork whatever they are kvetching about and do whatever "shall/should/must/ought to". So fork it and implement it!