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).
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.
(There could be a long discussion here about expectations placed on unpaid maintainers, and what the real purpose of Open Source / Free Software is beyond merely being zero cost at the point of use, but those tend to just go round forever. There's even a paid alternative to Jellyfin: Plex.)
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/...
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.
In some commercial projects we use copilot reviews in github, and noticed this "low quality nit-picky" style of review comments as well - but there is no way of getting rid of them as it is managed externally by github...
[0]: http://lists.openwrt.org/pipermail/openwrt-devel/2026-April/...
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.
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.
There is a constraint still but a project like the Linux kernal has put a lot of layers of review and testing and merging between the source of truth and the underlying contributions. Having a number of leutenents that deal with subsections of the system that test merges and review the contributions is necessary for a project to grow.
The point of the article is: there is a feature that people would like, there is someone who wants to add it, the appropriate time and a lot more for this feature to be merged has been spent yet the feature is nowhere to be found. That's the two way street I am trying to get across. I wish I wasn't even able to open the PR, I wish the maintainer would utilize more automation tools to groom feature requests and potential contributors with agreed upon plans and agreed upon timelines so that both sides time could be used much more effectively.
As far as PR descriptions etc goes, I asked multiple times what the best route to merging would be. If that went through better descriptions, I was happy to do that, as you can see, I wasn't aware of the "no conventional commits" rule, so in my next PRs I used the correct approach, but that should be completely automatable. Yes, I should have spent more time studying Jellyfin's conventions, but I shouldn't have to, not because its unfair for me, simply because there are more contributors than maintainers, so maintainers should not rely on desired behavior from contributors, they should force that behavior as much as possible.
But also definitely start setting up linting rules / labels to indicate how healthy or close something is to being merged.
The goal is to limit work-in-progress, and focus on getting PRs that are easy to merge over the finish line.
Edit: and yeah, a weekly review cadence goes a long way to triage tickets and PRs and get some initial feedback to developers. I also like the "next review on this date" proposal to push certain problematic PRs to a slower cadence so they're not occupying too much bandwidth.
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.
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.
dvh•3h ago
armanckeser•3h ago
onionisafruit•3h ago
esafak•2h ago
pjc50•1h ago
(I suspect the answer ends up being no, but the reasons could be interesting)
zokier•2h ago
PaulKeeble•1h ago
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.