31–40 of 53 posts
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.
First, I think sorting PRs by "recently updated" can be a good proxy for "does anyone care about this PR"... If it's being bumped and reviewed, it is. 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 caden…
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.
Ultimately if the new contributor brings in others to the project to also review and progress the project then it will quickly outpace the development on jellyfin and become the successful fork. No maintainer can cope with the workload of something like jellyfin and if they wont assign maintainers there isn't much else to be done. The key to the success is dealing with the outstanding merges by bringing maintainers o…
Earlier quoted context omitted.
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!
Earlier quoted context omitted.
It is a rite of passage. Meet Jellypin, my fork that only allows watching media with subtitles
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)
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.
It is a rite of passage. Meet Jellypin, my fork that only allows watching media with subtitles
Earlier quoted context omitted.
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?…
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.)
The basic problem is that these projects need democratic governance, not dictators. If you do the thing that lawyers always tell us not to do and compare code to law, you'll see how inadequate a king alone is to maintain all the law of a kingdom. He does not have time to approve everything. He does not have time to even be aware of everything. He has no easy way to figure out what his subjects want. The problem is th…
This is to say, I do agree software and especially open source is a ripe bed to experiment with different ways to organize!
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.
Actual Budget uses this well and merges PRs much faster, because they have the "it's experimental" to hide behind.
The basic problem is that these projects need democratic governance, not dictators. If you do the thing that lawyers always tell us not to do and compare code to law, you'll see how inadequate a king alone is to maintain all the law of a kingdom. He does not have time to approve everything. He does not have time to even be aware of everything. He has no easy way to figure out what his subjects want. The problem is th…
The tension is that people start with writing code to scratch an itch and share it freely. Every bit of community management pulls away from sitting down and coding a personal project. Even accepting the free work of others.
There are people who like doing both, but someone publishing their code online doesn't imply that. And it certainly doesn't imply that they hate democracy.