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.
He forgot some of the biggest reasons.
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.
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.
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.