The exponential curve behind open source backlogs • Hacker News Board

Re: The exponential curve behind open source backlogs

#51

Post by theturtlemoves » Wed, Apr 15, 2026, 5:32 AM UTC

erikerikson wrote: post #31

Have you paid? 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 goal…

Exactly. There has to be a payoff. When that's sheer enjoyment, that's fine. But that could flip and then payment, exchange of honest value, is a good model between people to do things and get mutual value exchange

Re: The exponential curve behind open source backlogs

#52

Post by ben_w » Wed, Apr 15, 2026, 8:55 AM UTC

mike_hearn wrote: post #35

pjc50 wrote: post #24

Earlier quoted context omitted.

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)

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.

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

#53

Post by pseudohadamard » Wed, Apr 15, 2026, 3:44 PM UTC

pwdisswordfishs wrote: post #47

armanckeser wrote: post #7

Earlier quoted context omitted.

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

Git is a DVCS, created to help manage Linux, which uses a distributed cabal of individuals, each of varying "authority" who choose whether something gets in or not. The problem is that despite using the same DVCS for source code management, other projects insist on a hub-and-spokes development model, which does not scale. Projects would be a lot more productive (and a lot more resilient) if they also followed a model…

Nothing to do with the devs, it's that Linux has, as you say, a distributed cabal of individuals while most things on Github have a nondistributed set of size 1. The reason why it's hub-and-spokes is that that's all you can do with only one or two people, or even half a dozen apparently when only one or two are doing all the work. If the maintainer doesn't accept your PR it is a big deal because there's no-one else there to accept it. Even worse is when you've got the opposite, one or two devs spread across half a dozen projects (HACS springs to mind) where they never respond to anything on most of the projects because there's essentially 1/10th of a developer on each one even if the apparent maintainer list is several people.