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