The exponential curve behind open source backlogs
armanckeser.com
The exponential curve behind open source backlogs
1–10 of 53 posts
Re: The exponential curve behind open source backlogs
#2You 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.
Re: The exponential curve behind open source backlogs
#3You 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.
It is a rite of passage. Meet Jellypin, my fork that only allows watching media with subtitles
Re: The exponential curve behind open source backlogs
#4Fantastic 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).
Re: The exponential curve behind open source backlogs
#5You 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.
It is a rite of passage. Meet Jellypin, my fork that only allows watching media with subtitles
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.
Re: The exponential curve behind open source backlogs
#6I 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/...
Re: The exponential curve behind open source backlogs
#7Fantastic 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 effec…
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
Re: The exponential curve behind open source backlogs
#8I 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…
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.
Re: The exponential curve behind open source backlogs
#9I 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…
"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.
Re: The exponential curve behind open source backlogs
#10I 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…
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.