A Call for Developers

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!

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?

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)

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.

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.

They are probably talking about this one: https://github.com/jellyfin/jellyfin-web/pull/3522

What if we put a cap on the expenses?

How about a nice selection of American cheeses?

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.

Joke.

. . . Omg I hope that's not it... I'll feel like a fool if that's the case!

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

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

@1hitsong @LordKitsuna

Programming in the Microsoft world is like working at McDonalds.

Everything is fine as long as all you want is a McDonald's hamburger. Try coloring outside the lines and you're basically screwed.

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"

To be specific, OMDB and TheDataDB.