[PaulKeeble]

Ultimately if the new contributor brings in others to the project to also review and progress the project then it will quickly outpace the development on jellyfin and become the successful fork. No maintainer can cope with the workload of something like jellyfin and if they wont assign maintainers there isn't much else to be done.

The key to the success is dealing with the outstanding merges by bringing maintainers onboard that are trying to contribute, build up the team and then the merges will get processed a lot faster.

[armanckeser]

So this is exactly what's unintuitive about queues, an analogy would be car lanes. Intuition might lead you to conclude that if a 2 lane road has traffic constantly going to 4 lanes will solve the traffic. But this is not true. Many people that would have used the road might have been using public transport or just decided not to commute or stay inside normally will join the traffic until it once again equilibriates. Adding more maintainers without addressing the core problems of the queue won't lead to success

[saulpw]

If you only focus on "solving the traffic" then you're right, adding more lanes ultimately just leads to more lanes being full. But the overall throughput is much higher! We need more holistic solutions, to be sure, but I hope no one thinks that means I-5 around LA could just be 2 lanes of traffic because they'll be full of traffic either way.

[nemomarx]

Does induced demand apply to open source maintaining? What would be the mechanism for that?

For traffic, more users note that the highway is easier to drive on and come over. Would people notice development speeding up and start adding more issues?

[armanckeser]

I think even just seeing the number of open PRs might be a deterrence to contributors thinking of opening PRs.