Discussion
dvh: 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.
spenrose: 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).
lstolcman: 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][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/...
armanckeser: Agreed. A problem I see with how AI reviews have been used is that after one kicks it off, now the maintainer has to review both the PR and the AI's review which doesn't really save time. Like you said, if AI review was used more intentionally, e.g. all PRs have to go through AI review that checks for the baseline requirements and only after the contributor signals "I addressed everything AI commented either by giving my disagreement reasons or making the changes", maintainers spending time on the review could save a lot of quality time.
ACCount37: "Pointless and nit-picky-annoying code review comments" seems like it could be mitigated with better prompting?Leverage the innate in-context learning - by supplying the code review AI with an annotated list of "do" and "don't". Define the expected reviewer behavior better, dial it in over time.
asdfasgasdgasdg: Additionally, I can't be the only person who has initially viewed a received code review comment as a pointless nitpick only to realize it prevented a serious bug. I think as a code review recipient there is a natural human bias to believe that our code is already great and to see feedback as being less important than a truly neutral observer would.
twp: AI reviews are flaky - maybe correct 80% of the time - and everyone hates flakiness.AI code reviews easily double the work in reviewing: you have to both review the original code and the AI code review. The AI code review can be 80% correct, but you never know which 80% is correct and which 20% is garbage, so you have to review all the AI's comments.
zokier: > Open Source has no adequate answersThe answer is simple: take responsibility and ownership of your software. That is the very core premise of FOSS after all, enabling such agency for users instead of being reliant on some vendor or other upstream.
Orygin: Maybe but I'll take a 80% correct review over no review at all. If it alleviates a good chunk of back and forth between the reviewer and the committer, it's still overall a time save for the maintainer.
armanckeser: It is a rite of passage. Meet Jellypin, my fork that only allows watching media with subtitles
pjc50: 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)
mkj: Looking at the PR discussed, it's 34 commits! I'd probably ignore that too as a maintainer. The PR description isn't particularly motivating, "Cleans up the implementation", "see #6735 for the actual motivation".
Liskni_si: Many of those are "Merge branch 'master' into armanc/subtitle-sync-refactor". Rebasing the PR on top of master would bring that down to like 15 or something.
mike_hearn: 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.
onionisafruit: 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.
esafak: Now all I have to do is pull both your forks and create my own so I can add one more feature. This is the future!
jcelerier: Here I was, naively hoping for a fork that would only allow watching Heat 2 with subtitles... Welp, time to put these tokens to good use
