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.
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.
The level of entitlement here is absolutely insane.
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."
Following Dave Rand's framework, the conversation went something like:
"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.
None of the people made it safe because it is not in the code.
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.
If enough people support your idea you will get a new community around your fork.
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.
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?
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.