> There's 843 pull requests at this time, and I just looked and over 50 are from just the last month

That's kinda overwhelming though ... imagine that if the maintainer pops up somewhere, suddenly 100 motivated people may chime in "hey please review this important pull request that's been sitting over here for a while".

There are some kinds of open source projects that are prone to this ... some are really not so bad to maintain if you have the right kind of discipline, because they converge on a stable set of functionality and platform compatibility evolves slowly, but some just naturally have endless room for variations and special cases, and as users increase, PRs increase linearly (instead of sub-linearly as you'd hope). I'm thinking in particular of https://github.com/oauth2-proxy/oauth2-proxy (of which I contributed to an older fork)

youtube-dl relies on up-to-date definitions of sites in order to download the content.

When a webpage changes layout, youtube-dl needs updated as well.

We're talking mostly about a list of site definitions more than we are core development.

Months before the lawsuit, youtube-dl's maintainers frequently closed issues that reported ongoing breakage without giving a reason. Here is one especially illuminating example:

https://github.com/ytdl-org/youtube-dl/issues/23860

And there is also an entire fork that fixes the support for just a single provider, NicoNico, because the maintainers ignored its issues.

https://github.com/animelover1984/youtube-dl

A quote from its README:

All code in this project is licensed solely with the condition that any portion of it is not permitted to be used in the main youtube-dl fork, either directly or indirectly. It is also not permitted to be used in any project that contains contributions from either remitamine or dstftw.

The two users mentioned are or were previously major contributors to youtube-dl.

It seems that youtube-dl was already a dysfunctionally managed project at the time of the lawsuit and happened to ride out on the good PR for a couple of months, before returning to stagnation once again.

To me it sounds like a plugin system would have prevented centralization and the need for forks, but would have made distribution harder for average users.

Indeed, this has been years in the making. Maintainer activity has been slowly dwindling while would-be contributors were driven away by the maintainers’ lack of communication and abrasiveness. I myself have had pull requests languishing there for years with nobody bothering to review them. Other people had their issues closed with no explanation. It was just a matter of time. Good thing that the forks have sprung up some time before upstream development halted entirely.

Then the repo might be dead because of that. I don't think people are (or should be) necessarily making assessments as to the reasoning of the admins without evidence, and there's a bunch of reasons why they might not be able to participate for a few months or even ever again, but if they are unavailable for a few months and nobody can even explain why, the end result is functionally the same if they're the only ones with the keys to the kingdom, which is that it's dead until something changes.

Is it a way to work on FOSS in decentralized or even distributed manner? Without relaying on the Github index as the critical point.

Sure, fork it and have alternate implementations and releases. This will necessarily fragment the namespace for it though, and the only way around that is to have some shared responsibility for making releases, and at that point, you might as well have enough shared admin responsibilities on the one repo, and the problem is also solved.

Another way to look at it is that this is not a problem of lack of solutions, it a problem that the person or people at the bottleneck (merging pull requests, testing and releasing) haven't shared that responsibility with enough additional people so this isn't a problem.

That, or there's some legal case in the background and they are under advisement to not work on or respond to anything to do with this repository. That seems just as likely in my eyes. Doesn't change the situation though, this repo is effectively dead right now (but someone could fork and start applying an releasing if they wanted AFAICT).