Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The exponential curve behind open source backlogs

armanckeser.com

Post reply on HN
Print view View original

11–20 of 53 posts

Re: The exponential curve behind open source backlogs

#11

Post by asdfasgasdgasdg »

ACCount37 wrote: post #9
lstolcman wrote: post #6

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…

"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.

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.

Re: The exponential curve behind open source backlogs

#13

Post by zokier »

dvh wrote: post #2

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.

You jest, but I think there is kernel of truth here. I do think people should be doing more (friendly) forks instead of funneling everything through upstream.

Re: The exponential curve behind open source backlogs

#14

Post by lstolcman »

ACCount37 wrote: post #9
lstolcman wrote: post #6

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…

"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.

Apparently, this is what they are trying to do [0].

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/...

Re: The exponential curve behind open source backlogs

#15

Post by [deleted] »

spenrose wrote: post #4

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 effec…

[deleted]

Re: The exponential curve behind open source backlogs

#16

Post by esafak »

onionisafruit wrote: post #5
armanckeser wrote: post #3

Earlier quoted context omitted.

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.

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!

Re: The exponential curve behind open source backlogs

#17

Post by esafak »

When it comes to open source software I would:

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.

Re: The exponential curve behind open source backlogs

#18

Post by Orygin »

twp wrote: post #10
lstolcman wrote: post #6

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…

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.

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.

Re: The exponential curve behind open source backlogs

#19

Post by larrytheworm »

spenrose wrote: post #4

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 effec…

[flagged]

Re: The exponential curve behind open source backlogs

#20

Post by spenrose »

armanckeser wrote: post #7
spenrose wrote: post #4

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 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

Indeed. The problem arises from a two step:

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.

Post reply on HN