Interesting read about the Development Bystander Problem. I was indeed part of it. Maybe it is time to start contributing :)
He forgot some of the biggest reasons.
- A larger codebase is generally just harder to work on. A more established product with more users tends to be larger.
- More popular projects with many users tend to have developers that don’t welcome new contributions. The investment required for a new developer to make an initial contribution is huge. Things like setting up the development environment and the stack of technologies and understanding the basic architecture are significant barriers to entry. Existing developers tend to not care about reducing that burden. After all, everyone who’s *actually *contributing to the project is already over that barrier, right?
Developers, open source or otherwise, should generally be excited about people “taking their jobs”. Because you’re going to have churn of developers over time, and if you’re not bringing in fresh blood, then your project is eventually going to die. Do you really want to maintain every project you work on for the rest of your life? Encourage new blood. Do what you can to accept new ideas and directions unless you have very good and explicit reasons not to. If someone has a sightly different vision and is willing to hop that initial barrier and is willing to put in more work than you, don’t undervalue that. Be willing to compromise a little to bring in a new developer. Sometimes you have to say no, but consider that you’re saying no to a person who wants to volunteer their time to do work for you.
On the other hand, there are tons of people who say they’re eager to work on your project. You invest a little time into them, they provide nothing, and then vanish. It’s easy to get jaded when you keep running into people who are more words than action. Be very careful what you promise you’ll do, and if someone invests their time to help you, try to actually do what you said you would.
In some cases, PRs that have no merge conflicts can sit and languish for months on end. Example: https://github.com/jellyfin/jellyfin/pull/8914. I’m not suggesting cavalierly accepting all PRs, but the devs could do a better job of communicating with prospective contributors. My desire to contribute to Jellyfin was somewhat dampened by that initial experience.
Edit: To be more constructive, I’d recommend not just a call to action (the blog post), but explicitly reaching out to devs who submitted their first PRs within the past year and finding out what their experiences were. Discovering a leaky onboarding process that you lose potential devs through could be instrumental!
I know what you mean, my pull request also sat around for almost 6 months before it got merged.
Having some feedback whether something is wrong with the PR or just that nobody had time to look at it yet would go a long way.
I am once again waiting on a PR to get merged before I can continue working on mine but it seems like nobody is sharing their thoughts on PRs anymore because there is radio silence and open questions go unanswered. I’m not an expert on Jellyfin architecture so without a maintainer stepping in and telling me how it should be done I can’t work on Jellyfin.
Probably a chicken an egg problem though. Without more maintainers responses are sparse and with sparse responses, less maintainers.
A year or so ago I actually tried to get into Jellyfin and it wasn’t really that pleasant experience.
A bit of background: I am mainly a Java and JavaScript developer and have used Plex for over a decade now. I even developed a Plugin for Plex with Python. Naturally, Jellyfin came across my radar so I checked it out but they didn’t have a Metadata Provider for the Metadata Source that I needed for some of my Libraries. There were alternatives but this would require to completely change my libraries which I wasn’t interested in.
So, I set out to just do it myself. I did know some C# but was by far not as up-to-date as you could be but I didn’t really care because I wanted to see how that project went and if I could get into it I could learn more about C# while doing it.
However, while I could get the Plugin compiled and loaded into a Jellyfin instance and even get some metadata downloaded, I quickly hit brick walls. From what I could tell, there weren’t even method comments for, you know, methods you need to implement so that you can write a metadata provider.
Not being able to resolve this through trial and error or looking at other currently active Providers (who seem to all do things differently, so no consistency) I asked on the Jellyfin Subreddit for help and got told to use the Matrix Chat instead. This was already annoying because that isn’t how you amass knowledge that someone can fall back to and find when they have questions because Matrix is a walled garden. Regardless I asked there as well and didn’t get any help or the responses didn’t really help me.
So, I shelved the project.
What I want to say here is that FOSS Projects like Jellyfin should prioritize their documentation. The easier it is for people to understand how things work and “get into” the project the more people would be willing to actively contribute. I know that what I described above could just be my inexperience or lack of understanding and knowledge of C# and everything around it but I would imagine that many developers are in the same situation as me and would like to contribute but can’t get over those hurdles. This is even worse for new developers who might want to stretch their legs in the Open Source community but are still learning.
Reading this with “we need developers” and “you can contribute to our documentation” looks a bit contradictory to me because shouldn’t the “experienced” contributor not create the documentation?
Documentation tends to be “you take what you can get” on both sides. Are you going to turn down a PR because there aren’t supporting docs? That’s a good way to drive off developers too.
Generally someone who is annoyed with having to figure it out is the one who writes the documentation.
I personally completely require documentation. Adding a feature may be beneficial in the short term, but not documenting it can create increasing maintenance burden in the long term. Every PR merged without docs slowly kills a project, even if it feels like it’s better to merge initially. When this is repeated too many times, the project becomes increasingly difficult to maintain. Merging only PRs with docs is how you prevent a project from dying. Even the original author of the code will eventually forget why they chose to do something a certain way or what edge case they were covering at the time
Spot on, I’ve seen plenty of great looking projects that I could contribute to but have next to no onboarding or set-up process. I’m keen on helping out but I’m not going to spend days setting things up locally because the primary project managers CBF to simplify the process.
Minimizing the mental overhead to get started should be something these larger projects strive for, especially if they’re struggling to get devs.
Even something like having a docker container for web apps is massively helpful, being able to up a container and everything just works means more tech adjacent contributors can join the project (designers, UI/UX experts, testers etc)
I absolutely loved how easy it was to setup the HomeAssistant dev environment.
But on the other hand, I realized shortly thereafter that the changes k wanted to make had already been implemented by someone else, but were having a hard time getting them merged in… over the past 3 years.
I forgot to mention Mumble as an example. It was many years ago, so hopefully things have improved by now, but the dependencies and setup for that were insane. I felt like I’d made a mess of my primary OS by the time I was done.
More popular projects with many users tend to have developers that don’t welcome new contributions. The investment required for a new developer to make an initial contribution is huge. Things like setting up the development environment and the stack of technologies and understanding the basic architecture are significant barriers to entry. Existing developers tend to not care about reducing that burden. After all, everyone who’s *actually *contributing to the project is already over that barrier, right?
I’ve tried to set up the Jellyfin server project locally several times, but couldn’t get dependency resolution working on my machine. I assume this is because I use Linux Mint rather than Windows, but I wasted multiple entire weekends trying to get it working to no avail. I’m a senior dev with professional experience in Java, Javascript, Python and Scala, so it’s not like I’ve never done this sort of thing before. This particular setup just happened to turn into a nightmare.
This particular setup just happened to turn into a nightmare.
There are certain software setups in linux that are trials by fire. For me it was samba (which happily I don’t even use any more) and [insert any mail server here]. Thankfully, once I finally got exim setup and working right, it’s worked right for 10+ years.
Both of those points were actually covered in an earlier blogpost that was linked in this one. It talked about how the new contributors often have an incentive to make a quick easy fix to solve their problem while the established developers have a bunch of rules, often unspoken, that they use to try to keep the code base maintainable. If you just take in any old code, you run the risk of making the code harder to work with or alienating your developers who spend time cleaning up the code. If you dump a bunch of rules on the new contributor, you run the risk of making them feel unappreciated with your “nitpicky” feedback.
Honestly, I’ve been thinking about contributing for a while. This is the push I needed. I’ll check it out!
I submitted a pull request that was shut down and the only feedback was “I don’t think this is the way we’d do it.”
I know managing community contributions is a big task but if you want people to volunteer, a baseline amount of effort should be made to enable it.
It’s also helpful to have automated tests to increase confidence that a change won’t break existing features.
There was a baseline effort there. Your PR wasn’t a proper fix, but more of a hack which also isn’t in line with how a proper UI would display things.
Link?
They are probably talking about this one: https://github.com/jellyfin/jellyfin-web/pull/3522
Thanks for sharing, will check it out to see if there’s anything I can help with.
If the jellyfin android app didn’t encode the files and just served them like the web UI that would be utterly amazing.
I can play the file via VLC with hardware decoding, jellyfin should be able to do the same.
The android application has multiple “players” available to it.
- Web player
- Integrated player
- External player
Sounds like you want to be using the integrated player so that you can direct play on your device?
. . . Omg I hope that’s not it… I’ll feel like a fool if that’s the case!
You can start by opening the bag where you store the dunce hat. 🤣
Turns out it’s ASS. It forces transcoding.
Ugh yeah, I ran into that previously. In fact a post on that is still on the jellyfin subreddit from some time ago. It was real annoying to figure out.
That will get fixed eventually, it took plex years to get ASS support working properly, its a complex format to render client side, particularly when its doing the fancy moving overlay stuff to pull of tricks like replacing text on a poster or sign and such. Its one of the few things still holding me from totally switching over to Jellyfin.
Time to contribute to the docs
Who invited this guy
Turns out it’s the subtitles. As I watch a lot of anime it’s either good subtitles and transcode, or bad subtitles and direct. As the extra styling is not covered by the application
It’s true I could change it to external player but then you lose half the features…
For instances like this, you could either use the Jellyfin plugin that extracts embedded subtitles, such that they are stored in an .art file and don’t need transcoding, or set up Bazarr for the same (amomg handing all your subtitle needs).
I found that I preferred Bazarr, especially with notifications through Gotify, as I would directly see what took place when a subtitle was pulled, where as the Jellyfin plugin felt a bit like a black box.
Come join us on Roku. We have fancy hats!!!
I’m not approving any hat expenses
What if we put a cap on the expenses?
Got to keep a lid on the budget.
You’re just brimming with ideas Johnson, you’re hired!
How about a nice selection of American cheeses?
I wanted to join, but I think I’m good, thanks.
😆
Government cheese for all! Little American flags for others
Edit: I’m Canadian
What’s a roku?
The streaming device that is the easiest* to start programming on!
- I have no other streaming devices, so I’m unable to make any actual comparisons to back up my statement.
Why is this upvoted? Joke?
Joke.
I hope they find the help they need, it’s a very good app.
Discord invite is expired, but it could be a mobile issue because apparently invites being invalid only when opening on mobile is a thing I’ve experienced…
I just double checked it and it’s set to never expire.
They definitely are in need of developers, there’s an open ticket for memory leak issues and I just checked last week with the latest Master branch and it still exists at least on my system. Even if you just start the server and then never interact with it in any way whatsoever never load the interface play anything the memory just slowly grows and grows and grows until the system runs out of memory.
It also still has a lot of pretty basic media matching errors where it will pick the wrong show for files for some reason or just fail to find the show at all. I’ve seen lots of cases where the only way to match an anime is to use the Japanese name in the search even though that brings up the English name metadata and other Oddities like that. All of my stuff is organized and named by sonar using a very clean format that should be very friendly to finding metadata
i actually know a number of developers that are interested in jelly fin as a concept but when I ask if they are going to contribute they just go “eww no it’s c# and .net i ain’t touching that”. Perhaps the developers should consider a rust rewrite lol, get the rust hype devs.
I’m been wanting to ask for a while, and now seems like a good time.
Why do some programmers hate C# so much? What are the reasons for “eww no it’s c# and .net i ain’t touching that?”
Microsoft.
I’m a .NET dev, still hate Microsoft, but the language and ecosystem are fantastic. At least since .NET Core when it was mostly decoupled from Windows.
The misconceptions that persist to this day despite over half a decade of .NET Core are mind-boggling. MS has a steep hill to climb.
The language itself is great, but Microsoft the docs are sometimes horrible or outdated.
And most things feel like magic that you can’t or don’t need to understand. E.g. if you set up a modern asp.net project it’s some huge boilerplate with configuration files and what not…
Also standards often change… E.g. try figuring out what the best GUI framework is to create a full-fledged Desktop app in C#. There’s like a few different ones, and most are for basic mobile-style apps or not really mature. The best I found so far is WPF, which is kinda old though and everyone thinks it’s dead.
deleted by creator
i asked a few people and got the following answers
"cuz: 1: its fake java 2: eats memory like java 3: .net on linux is l-o-l 4: unlike java there is no C# kotlin 5: other better things exist (java, javascript, go) "
“the biggest issue with C# is that its just a fucking pain in the ass to use” (this one got several uses of a “yup” emoji reaction)
“wtf is a compiler macro and why would i use one”
"I dislike async/await garbage in most languages, this includes C#
like you need to designate some functions async and others are non-async and sometimes you run into a situation where you need to block on async from sync and you’re basically fucked"
I feel like most of them haven’t used C# in the last decade, let alone .NET since Core.
-
is smoking crack. .NET on Linux has been fine for years. Unlike Java there is no need for a .NET Kotlin (and there is F# if you really want a functional-first .NET language). If you want to call Java a “better” alternative to C#, power to you. But Javascript and Go shouldn’t be in the same conversation. Hence the crack.
-
Might be thinking about .NET Framework, which is a pain in the ass to deploy. Modern .NET is completely different. Can’t think of many instances where the language itself works against me compared to Java.
-
So you can conditionally compile code based on build-time constraints. For example, debug logging code can be removed entirely in the release build.
-
Has a point, but this also disqualifies them from using almost any language with asynchronous programming.
-
Funny how it takes a call for devs for everyone to voice their concerns and suggestions
Just a question, as I couldn’t find anything. What is this for? https://opencollective.com/jellyfin/expenses/163979
It says Patreon, but not really anything more than that
I asked Josh about this. His answer was:
It’s for the OMDB API key. The payment is just through Patreon.
To be specific, OMDB and TheDataDB.
