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.

[–] [email protected] 25 points 1 year ago (2 children)

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?

[–] [email protected] 8 points 1 year ago (1 children)

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.

[–] [email protected] 7 points 1 year ago

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

load more comments (8 replies)