News for hackers. Stuff that matters.
Re:The exponential curve behind open source backlogs by armanckeser on Tuesday April 14, 2026 @09:30AM (#47765421)
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 by onionisafruit on Tuesday April 14, 2026 @09:58AM (#47765748)
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 by esafak on Tuesday April 14, 2026 @10:50AM (#47766409)
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 by jcelerier on Tuesday April 14, 2026 @01:05PM (#47768289)
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
Re:The exponential curve behind open source backlogs by pjc50 on Tuesday April 14, 2026 @11:33AM (#47767022)
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)

Re:The exponential curve behind open source backlogs by mike_hearn on Tuesday April 14, 2026 @01:08PM (#47768331)
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.
Re:The exponential curve behind open source backlogs by ben_w on Wednesday April 15, 2026 @04:55AM (#47776426)
I've been using 5.4 recently, and even on "extra high" some of the tests it wrote were opening the source code and doing a regex to confirm the presence (or in some cases the absence) of specific substrings. It wasn't running the code to confirm behaviour, and the regexes didn't even do a basic check to confirm the text wasn't commented out (not that it would've been sufficient if they had, this is just to illustrate how bad it was).

So, yeah. I'd guesstimate this model was fine 75% of the time, mediocre 15-20%, and actively bad 5-10% of the time. How valuable it is depends on how much energy you can spare as a human on spotting the bad.

Re:The exponential curve behind open source backlogs by mike_hearn on Tuesday April 14, 2026 @01:14PM (#47768381)
Forks don't have to be hostile. A perfectly reasonable way to react to an overwhelmed maintainer is just to do a friendly fork. Keep the original name, attribution, git history etc, update the README and start acting as a trustworthy lieutenant. You can review stuck PRs and merge them into your own branch, whilst also merging with upstream master. After a while if you seem to be making good calls the original maintainer can do a bulk merge from your branch to bring in many PRs at once, and maybe add you to the repository.