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