Hacker News Reader

Comment by spenrose | Hacker News Reader

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 effectively managing the project. Open Source has no adequate answers (“fork” is not adequate).

View on HN

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.

People get what they pay for.

(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.)

We can have a business model. I can pay the developer to prioritize my PR if I consider it worthy enough that it solves my pain point. Companies do that as I have heard. There could be a Groupon like model where multiple people facing the issue can pool the money for prioritization.

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 where "The <x> maintainer hasn't accepted my pull request" just wasn't a big deal.

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

Reply on news.ycombinator.com