Why You *Shouldn’t* Contribute to Open Source

Thanks to Secretlab for being the title sponsor of LMG Clips this year! Check out their ergonomic gaming chairs at the link above. Your back will thank you!

Don’t contribute to Open-Source Projects you don’t care about for the sake of “resume padding.”


FOLLOW US ON SOCIAL
---------------------------------------------------

[David-tymy]

Luke is correct. Don't contribute if you don't know what you're doing.

[GSBarlev]

Pro tip: if you're a FOSS maintainer and you actually _welcome_ commits from people who want to build their resumé:

1. Mark some issues as "Good First Issue"
2. Use Gherkin or just make it *very clear* what the expected behavior is
3. Don't just blindly accept commits—force things to go through PR, and make it a conversation and a *teaching opportunity.*

If all of this sounds like more work than just doing something yourself, *you're right.* And no one is demanding that you take time out of your week to mentor. But if you _do_ have the bandwidth:

1. Think about how much you would have appreciated that guidance when _you_ were a junior dev
2. Remember that engaging in coaching like this is how you build your skills as a *tech lead* or project manager.

[ovflowd]

It’s important to mention that there’s an important point that some open source repositories are designed to be playgrounds and educational projects for newcomers to foster their skills, and some are projects that for better or for worse, you need to know what you’re doing.

Often maintainers will try to be helpful, mentor you and point you to the right direction to land the patch. But, if you have a huge lack of knowledge, in the end the maintainer will do more job providing that support to you than if they did the patch themselves.

Of course it’s always awesome to share knowledge and mentor folks, but that is done out of the good heart and kindness of said maintainers and they have no obligation at all to provide such support.

Of course there are also maintainers that simply do not want to accept changes or patches, just leave them be.

In the end, be mindful about your own time and the project’s and maintainers time’s

[italianbasegard]

1:07 I was waiting for Linus to intervene with the dad joke *”…like… a GitHub Issue?”*

[Immudzen]

I was interviewing some people recently. Two of them had public github profiles and had meaningfully contributed to open source projects for quite a while and that counted in their favor. However, one other person, had repeatedly tried to contribute very poor quality code .... that did not help them.

[SamiKankaristo]

Luke is right, but you also don't necessarily have to spend very much time in order to do something meaningful to an open source project.

If there's an app you use, and you notice a bug, report it and take a look at fixing it. Helps yourself and the project. You don't have to become a regular contributor in order to do something useful. But yeah, don't do meaningless refactoring, etc., that will just waste other volunteers' time.

[martindendis]

Yep. Do not contribute for the sake of contributing. Contribute to projects you are well familiar with and ideally use on a daily basis. E.g. you will discover a bug, then you can open a ticket with a pull request containing a fix, or you come up with some meaningful improvement or new features that you think other users would appreciate.
Do not just browse repos in a search for bugs that you could fix or requested features that you could implement as there is a high chance that maintainers are already working on it.

[SimGunther]

And this spammery behavior in regards to GH commits is a symptom amongst many of "software engineers" that are in it only for the prestige, monies, and easy "day in the life of" videos.

[daveg]

As a long-time many-decade professional software developer, years ago I used to work on some open source and Linux projects with other people, but I found that the majority of people who "want to get into software development" simply don't have the basic requirements, so the project falls apart or just stalls or is pure junk. The people in project management usually don't have the nards to correctly divide up work between the people with different skill levels, and it becomes a free-for all mess. So I completely stopped working on open source. People writing software that they put onto repositories like Git are also allergic to adding comments to their code.

[bnaZan]

I've seen some horrible code from the godot game engine.
Their raycast which supposed to be used thousands of times per frame returns **dictionaries** and you're supposed to get the results from string keys (?!?!!?) instead of using a struct like every other game engine

[Kisai_Yuki]

More to the point "don't contribute refactoring/syntax laundering". I hate seeing this. Let the developer dictate how they want their code style to be, and leave it alone. One of the things that quicky chased me away from doing any OSS work was having another developer basically hijack the entire project and "refactor" all the C code into unnecessary C++ abstractions. Unless the developer wants that, don't hijack it.

Trash commits are everything from "correcting typos", "camelCasing/uncamelcasing" local variables and functions for no apparent reason, and basically committing stuff that neither fixes a reported problem nor asked for. If you are a whizbang pro at Rust, or C++, or ObjC, don't take someone's C code and transform it into another language for the sake of NIMBY'ing the foreign code. That is extremely frustrating and annoying since it means you never benefit from fixes to that C library that worked just fine. Leave C code alone.

If you're a Perl/PHP/Ruby/Python/NodeJS developer, it's even more important to leave C libraries alone and not turn them into "native" interpreted code because that is slow. C code is already as fast as it's going to get, you can not improve it by remaking it in another language, and it's insulting the original developer.

[MrKlarthums]

The proper way to commit meaningful code to an open source project is to open an issue (or find an existing one), volunteer to implement it, get a thumbs up from the maintainer, write your feature, and submit a pull request. If you don't know the app's feature set or code base well enough, you probably won't make a meaningful change outside of simpler bug fixes.

Alternate ways to contribute are to answer questions in the community, help work on documentation, or write unit tests. Even feedback / feature requests can be helpful over the longer term because developers do not start a project knowing everything.

[JasonB]

Job postings are often more scary than what the actual job really requires. I am no programmer so can’t say anything about programming, but in my early years in my IT career, I had people try to train me how to map a network drive in windows and how to ping a server using the command prompt. I told them I already know how to do that. Sure it was just lowly help desk job but I thought that was common knowledge at this point. However those co-workers thought I was being a know it all jerk. This is the most important thing I learned. No one expects you to know everything. In fact they want someone who is willing to learn on the job and not be a smart aleck about it.

[thenayancat]

I only maintain small/niche projects and I can confirm this is incredibly annoying, people who just want to solve their hyper-niche problem, don't add any tests, don't look at the code style, sometimes don't even check if their change actually works or passes basic checks/linting. It takes me time to even realise this sometimes, at which point I could've written a solution that isn't total garbage

[randmtv]

The whole "contribute to open source to get hired" idea went too far and leads to projects being overwhelmed with low effort contributions or even worse, spam. Things like Hacktoberfest giving out free t-shirts also didn't help because people started contributing for t-shirts instead of actually wanting to contribute.

If people want to contribute to open source, they will do it. No need to push it as "must do" thing or even worse sell it for a t-shirt.

[FedJimSmith]

but how do the employers know if the commits are "of value" to the code base? Usually do employers contact the maintainers if not for the purpose of the application then it's a yes (contribute more)???

[SeanCassiere]

Actually a pretty good summary of Theo's video.

[SnowyRVulpix]

I have no idea what this video is about. I was too busy watching linus eat

[marufbepary]

Long story short, contribute if you have the skills.

[Random-video]

The only thing I learned on this video is don’t eat while on camera