📅 Published 2021-09-04
Somewhat shamefully, I have only recently begun to contribute anything more than bug reports to free software projects. (I once released a small utility, now obsolete, but that's it.) I know that bug reports can be useful, but I definitely had the ability to do more, and I didn't use that capacity until now.
Why did I wait so long? I'll be honest: I was intimidated. But what I've found is that contributing is easier than I thought.
In today's world, people use their Github timelines like resumes. A poorly considered commit sits around for all to judge, from here until eternity. Or at least it feels that way, as a nervous newbie.
Who wants to cross the threshold of a pull request unless you're absolutely *positive* that your work stands up to scrutiny? What if your peers were to judge you, and find you *lacking*? The shame!
The thing is, even if your patch is flawed, nobody[^1] cares all that much as long as you aren't being disruptive. This is especially true for small contributions to more casual projects. If your patch moves the project forward, and it doesn't conflict with the project goals, it's worth putting it out there. Even if the maintainers don't use it, you may start an important discussion or provide a base for someone else's work. That's a real contribution, and it's helpful!
[^1]: Okay, a few people do get angry when someone submits flawed code, but they are jerks and you shouldn't work with them.
If you are charitably minded, it's tempting to try and contribute to projects that seem "important." There are many projects that need help, and some of these are critical to the free software ecosystem. There's quite a lot of reputation to be gained by contributing here. But first, you must ask yourself... is this something I'm actually *excited* about?
I'm not the first one to say this (see Drew Devault's article "I want to contribute to your project, how do I start?"), but your contributions will be better if you work on projects that deeply matter to *you*. If you use a tool, you are likely to be invested in its continued existence. If you want a feature that doesn't exist yet, writing the code that brings it into being will likely be less taxing. Less like a job. More fun! (We all like fun, right?)
I want to contribute to your project, how do I start?
This is not to say that you should shy away from contributions to "boring" but necessary projects. That work is important. But maybe that work is something you can do when you have more experience and confidence, or when you have excess energy and nowhere to apply it.
It's tempting to jump in head first and contribute to a big project. After all, these projects have a huge impact, and contributions are very visible. And how cool is it to have your code running on devices across the world?
Unfortunately, it's not always easy to contribute here. The tech press occasionally brings us news about vicious slapfights and harassment campaigns in popular software projects. To counter this, big projects are adopting bureaucracy: codes of conduct, contributor covenants, and more. Not to mention, for larger projects, the dreaded P-word: *process*.
Popular projects are subject to all kinds of attacks, from reputational attacks against developers to attacks on build infrastructure, and even the occasional obfuscated vulnerability. When thousands of developers (or more) rely on your project, that's a huge burden of responsibility to contend with. It's no wonder that these projects are sprouting the same kind of red tape that you find at growing companies. They are facing many of the same pressures!
This phenomenon is most obvious with popular projects in fashionable (or profitable) domains. Not to pick on any one project, but take a look at Tensorflow's RFC process. As a casual contributor, there's no way that I would touch that. I'm sure it's very effective for keeping things serious, professional, and focused, but that sounds like a *job*, man. I just want to give back a little!
Fortunately for new contributors, there are a few ways to avoid this situation:
Any one of these is less of a pain than jumping on the hot project bandwagon, yet you are making a **much** bigger impact with this kind of work. Most big popular projects have no shortage of contributors, so you are less individually useful, especially as a new contributor. These projects also typically have a well-considered plan that can't be influenced much by outsiders. Not that I want to discourage contributions to, say, the Linux kernel or Debian. (This work is super important!) But if you can, help fill in the gaps in less popular projects.
Approaching a possible FOSS contribution as if it's a huge chore is the wrong mindset. If you feel this way, consider the following:
If your answer to these questions is "yes," then maybe you should just stop thinking about it and jump in. Sure, you could go watch another YouTube video, but what would you really get out of that? Take five minutes to pull down the repo, make a new branch, and build the code locally. Suddenly the barrier is gone.
I'll admit, it's hard to get into this way of thinking. I'm still working on it myself. We're conditioned to avoid extra effort, taking even the slightest mental exertion or discomfort as a sign that maybe we should just go do something *easy*. But that's the path of the passive consumer. You are capable of doing more than you think, and you will get plenty of satisfaction from the process if you just put in the effort.
When you encounter a bug, try and fix it! When you have an idea, submit a patch! If you're not familiar with the language or tooling, think of it as a learning opportunity. The only way to learn and grow is to push yourself a little. You can do it; trust yourself.
---
Comments? Email the author: mntn at mntn.xyz