this post was submitted on 01 Oct 2023
522 points (98.5% liked)

Jellyfin: The Free Software Media System

7060 readers
1 users here now

Current stable release: 10.10.7

Community Standards

Website

Forum

GitHub

Documentation

Feature Requests

Matrix (General Information & Help)

Matrix (Announcements)

Matrix (General Development)

Matrix (Off-Topic) - Come get to know the team and blow off steam!

Matrix Space - List of all the available rooms on Matrix.

Discord - Bridged to our Matrix rooms

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 64 points 2 years ago (12 children)

Interesting read about the Development Bystander Problem. I was indeed part of it. Maybe it is time to start contributing :)

[–] [email protected] 70 points 2 years ago (11 children)

He forgot some of the biggest reasons.

  • 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] 22 points 2 years ago (2 children)

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)

[–] [email protected] 4 points 2 years ago

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.

load more comments (1 replies)
load more comments (9 replies)
load more comments (9 replies)