Forks don't have to be hostile. A perfectly reasonable way to react to an overwhelmed maintainer is just to do a friendly fork. Keep the original name, attribution, git history etc, update the README and start acting as a trustworthy lieutenant. You can review stuck PRs and merge them into your own branch, whilst also merging with upstream master. After a while if you seem to be making good calls the original maintainer can do a bulk merge from your branch to bring in many PRs at once, and maybe add you to the repository.
Check out my fork, Jellyden(iro). It’s the best way to watch Heat 2. All the media selection garbage is removed for a streamlined Heat 2 experience, because why would you want to watch anything else when you could be watching Heat 2 instead.
It's worth asking "if AI is so great for software development, won't that make it dramatically easier for people to maintain their own forks of software?"
(I suspect the answer ends up being no, but the reasons could be interesting)
I'm curious why you think the answer would be no. I've had some success with resolving complex merges with GPT 5.4, and it seems obvious enough that AI is a good solution for maintainers who don't have anyone they can trust to take over the project whilst also needing to boost throughput.
I've been using 5.4 recently, and even on "extra high" some of the tests it wrote were opening the source code and doing a regex to confirm the presence (or in some cases the absence) of specific substrings. It wasn't running the code to confirm behaviour, and the regexes didn't even do a basic check to confirm the text wasn't commented out (not that it would've been sufficient if they had, this is just to illustrate how bad it was).
So, yeah. I'd guesstimate this model was fine 75% of the time, mediocre 15-20%, and actively bad 5-10% of the time. How valuable it is depends on how much energy you can spare as a human on spotting the bad.