Fantastic piece: shows how fundamental dynamics (queuing) generate practical problems AND what to do about them. This essay is better than 95% of tech blog posts I read via HN. Kudos!
An original sin of Free Software which carried through to Open Source and infects HN via its many Open Source believers is a reluctance to take project management seriously. OP shows that Jellyfin’s dictat... er, maintainer is not effectively managing the project. Open Source has no adequate answers (“fork” is not adequate).
Thanks a lot! I appreciate the kind words. I do want to clarify that I think in Jellyfin-web's case, the maintainer does mean well and doesn't really have the "benevolent dictat... er, maintainer" approach. But there seems to be this defeatist argument of: we have one maintainer which means 6 months per PR and features not being merged, that I think Open Source projects could do a better job at
Git is a DVCS, created to help manage Linux, which uses a distributed cabal of individuals, each of varying "authority" who choose whether something gets in or not.
The problem is that despite using the same DVCS for source code management, other projects insist on a hub-and-spokes development model, which does not scale.
Projects would be a lot more productive (and a lot more resilient) if they also followed a model where "The maintainer hasn't accepted my pull request" just wasn't a big deal.
Nothing to do with the devs, it's that Linux has, as you say, a distributed cabal of individuals while most things on Github have a nondistributed set of size 1. The reason why it's hub-and-spokes is that that's all you can do with only one or two people, or even half a dozen apparently when only one or two are doing all the work. If the maintainer doesn't accept your PR it is a big deal because there's no-one else there to accept it. Even worse is when you've got the opposite, one or two devs spread across half a dozen projects (HACS springs to mind) where they never respond to anything on most of the projects because there's essentially 1/10th of a developer on each one even if the apparent maintainer list is several people.
1. Free Software / Open Source are Good and True by assertion. There is no God but source code, and Stallman is its prophet.
2. Questions whose answers tend to contradict point 1., such as “Gee, the world runs on Python — as wonderful as job as Guido and his inner circle have done, is it time to ask what an ideal management structure for a technology worth (tens? hundreds? of) billions of dollars might be?” are not welcome — are largely not asked.
I too have been frustrated by the way open source works. Maintainers are frequently people in high demand and open source rarely pays commensurate.
So too have I given my work away and been met with entitled demands for service and time. I enjoyed writing the code and making something useful. I enjoyed the validation of that belief based on use but that doesn't feed the family or further my actual goals in life.
I read about similar issue today in another context, in a thread about introducing AI code review in OpenWrt [0]. The idea came from the fact that the project has too few maintainers compared to the number of incoming patches.
Automated code review is supposed to help catch the most trivial and basic mistakes (which, as the author claims, are often repetitive), and also speed up feedback. Ultimately, this should help push issues forward and let maintainers focus on harder problems like architectural issues, which needs deep knowledge, and AI can't solve this part yet.
On the other hand, there are comments opposing the policies of AI companies, complaining about pointless and nit-picky-annoying code review comments, that don't add much, and raising the concern that AI reviews are treated as checklist for getting things merged; which can be frustrating regarding to the amount of bot comments. The suggested mitigation would be to explicitly note, that the AI code review is only a suggestion of changes. [1]
In the end, I think accepting AI in a way similar to the rules introduced in Linux (i.e., you can make your life easier, but you still have to understand the code) makes sense, given the limited code review capacity, compared to the volume of incoming contributions - which is also referred in a mailing list thread I'm referring to [2]
The basic problem is that these projects need democratic governance, not dictators. If you do the thing that lawyers always tell us not to do and compare code to law, you'll see how inadequate a king alone is to maintain all the law of a kingdom. He does not have time to approve everything. He does not have time to even be aware of everything. He has no easy way to figure out what his subjects want.
The problem is that we haven't created theory and tools for online governance. We just went with dictatorship. If using a piece of software automatically made me part of the community of that piece of software, we'd have something. Only to the extent that I felt like participating of course, but if software would aid that, in a uniform manner, across projects, that would be an achievement.
The code has been treated as the end-all be-all, but projects get rewritten. The important part is the institution. We've been regularly concentrating that institution into one unpaid or poorly paid guy, until it gets handed to some corporate vulture who thinks of the users as prey.
The irony of this situation is that a backlog of PRs means that you have a overwhelming surplus of people willing to do free work. Seeing it as a problem is some sort of ideological failure. We just hate democracy and losing control so much that we're willing to starve surrounded by food.
You need to go back to the roots of open source. Fork it, merge your two changes, remove 90% of code you don't need, rename it, write article about speed up in the new successor vs the old thing.
1. Modularize the code to allow plugins so users can start using them immediately, and you can vet them at your own pace.
2. Make tests robust and easy to run (one command to run, at most one to setup) so you don't have to pore over their code to have some confidence that it works.
49 comments
An original sin of Free Software which carried through to Open Source and infects HN via its many Open Source believers is a reluctance to take project management seriously. OP shows that Jellyfin’s dictat... er, maintainer is not effectively managing the project. Open Source has no adequate answers (“fork” is not adequate).
The problem is that despite using the same DVCS for source code management, other projects insist on a hub-and-spokes development model, which does not scale.
Projects would be a lot more productive (and a lot more resilient) if they also followed a model where "The maintainer hasn't accepted my pull request" just wasn't a big deal.
1. Free Software / Open Source are Good and True by assertion. There is no God but source code, and Stallman is its prophet. 2. Questions whose answers tend to contradict point 1., such as “Gee, the world runs on Python — as wonderful as job as Guido and his inner circle have done, is it time to ask what an ideal management structure for a technology worth (tens? hundreds? of) billions of dollars might be?” are not welcome — are largely not asked.
I too have been frustrated by the way open source works. Maintainers are frequently people in high demand and open source rarely pays commensurate.
So too have I given my work away and been met with entitled demands for service and time. I enjoyed writing the code and making something useful. I enjoyed the validation of that belief based on use but that doesn't feed the family or further my actual goals in life.
Automated code review is supposed to help catch the most trivial and basic mistakes (which, as the author claims, are often repetitive), and also speed up feedback. Ultimately, this should help push issues forward and let maintainers focus on harder problems like architectural issues, which needs deep knowledge, and AI can't solve this part yet.
On the other hand, there are comments opposing the policies of AI companies, complaining about pointless and nit-picky-annoying code review comments, that don't add much, and raising the concern that AI reviews are treated as checklist for getting things merged; which can be frustrating regarding to the amount of bot comments. The suggested mitigation would be to explicitly note, that the AI code review is only a suggestion of changes. [1]
In the end, I think accepting AI in a way similar to the rules introduced in Linux (i.e., you can make your life easier, but you still have to understand the code) makes sense, given the limited code review capacity, compared to the volume of incoming contributions - which is also referred in a mailing list thread I'm referring to [2]
[0] http://lists.openwrt.org/pipermail/openwrt-devel/2026-April/...
[1] http://lists.openwrt.org/pipermail/openwrt-devel/2026-April/...
[2] http://lists.openwrt.org/pipermail/openwrt-devel/2026-April/...
The problem is that we haven't created theory and tools for online governance. We just went with dictatorship. If using a piece of software automatically made me part of the community of that piece of software, we'd have something. Only to the extent that I felt like participating of course, but if software would aid that, in a uniform manner, across projects, that would be an achievement.
The code has been treated as the end-all be-all, but projects get rewritten. The important part is the institution. We've been regularly concentrating that institution into one unpaid or poorly paid guy, until it gets handed to some corporate vulture who thinks of the users as prey.
The irony of this situation is that a backlog of PRs means that you have a overwhelming surplus of people willing to do free work. Seeing it as a problem is some sort of ideological failure. We just hate democracy and losing control so much that we're willing to starve surrounded by food.
1. Modularize the code to allow plugins so users can start using them immediately, and you can vet them at your own pace. 2. Make tests robust and easy to run (one command to run, at most one to setup) so you don't have to pore over their code to have some confidence that it works.