Different Ways to Contribute to Open Source
OSS is a wonderful thing! I was so grateful for the OSS tools I used in my projects, that I started contributing to OSS as retribution! If you want to get started with OSS contributions, here are several ways to do it.
In each section, I’m going to present a topic, explain it, and link some Pull Request that I did in that “category” so you can take a look to get inspired/learn something.
🐛 Bugfixes
If you fix a bug, maintainers will love you. It can be a bug you found, or an issue tagged with
a bug label. It is a good opportunity to fix that 1px misaligned item that is
bothering you since forever.
Or maybe you tried something and it didn’t work quite well on your machine. If you figure out what went wrong, don’t keep it to yourself! Open a PR!
Some bug fixes I did:
- Ameba GH Action - Prevent linter to run on external libraries code
- Ameba - Handle duplicated files when running linter
✨ New features
Do you wish that a library did X for you? Don’t expect maintainers do it for you. Code it and submit a PR! Maybe you already have something in your codebase that could be pushed upstream. That is what happened with the following contributions:
- RSpec - Allow ordering specs by modification time
- Long Haul - Add support for Disqus comments
- tiptap - Add support to history custom settings
- mintest-stub_any_instance - Allow stubbing without a value
That is one of the nicest things about open source: you can contribute back to projects that helped you! You may open an issue first, asking maintainers if they like your feature idea.
⚡ Improve performance / Refactor code
If you’re experienced in a language you probably know some patterns or methods that are more performant than others,
i.e, they run faster and/or with less memory. For instance, in Ruby using each + push is slower than using
map. This is an opportunity to find those patterns and replace them with more performant alternatives. When you do
this kind of contribution, don’t forget to add benchmarks to your PR to make it more compelling.
You can do some refactoring too: deleting unused code, fixing deprecation notes/methods, untangling some nested
if/else with guard clauses, etc. Making the code easier to read is important to add new features and finding
bugs in the future.
Here’s some PRs I did for Ruby on Rails in this category:
🧪 Add tests
Tests make us feel more confident about the code we write and the changes we make. Well-tested OSS benefits everyone using it! So, you can help yourself and the whole community by adding tests to a project! Adding a test coverage tool is another way to contribute to this topic. Setting up a coverage tool helps to understand which areas of the core aren’t tested.
This was exactly what I did for gem-web. I added simplecov and with the
coverage tool properly configured, I added tests for the missing parts:
🐋 DevOps
Adding a Docker/Docker Compose setup is a nice way to help newcomers onboard a project, especially when the project is
an app with several moving parts (core, database, cache services etc). Setting up all that may be hard, but running
docker-compose up is far easier.
There’s other things you can contribute: almost every project nowadays has a Continuous Integration (CI) pipeline (Gitlab CI, GitHub Actions, Travis CI, Circle CI, Jenkins etc). Setting up a pipeline is an contribution in itself, but you can go further and set up linters, security checks and even a staging build in some cases!
Here’s an example of a PR where I introduced a Dockerfile as an alternative setup build script:
👩💻 OSS is more than code!
As developers, we love to code, but OSS is far beyond just coding! Maintainers have to deal with a variety of different problems: documentation, helping beginners, handling poorly written issues, spams, reviewing Pull Requests, etc. We can do OSS by helping them with these tasks!
👍 Reviewing PRs
You don’t need to be a maintainer to do that! I took much time to understand this. Reviewing PRs also helps the contributor to not feel bad about their work not being reviewed for many days, and you help address issues faster (typos, changing naming, refactorings, adding docs, etc). Just be kind and helpful. Here’s more tips on good code reviews.
🕵️♂️ Reproducing issues
If you’ve been part of a reasonably used OSS project, then you know how hard is to handle issues. Many of them don’t even have enough information to reproduce and diagnose its causes. You can help maintainers by trying to reproduce issues! You may have to ask users for more information (OS, language, library versions, for example), or steps to reproduce it. Sometimes the behavior is not a problem, but a deliberate choice.
📝 Improving documentation
This is one of my preferred ways to contribute to OSS. Here we have a lot of options: fixing typos, rewriting confusing sections, adding docs where it’s missing. The best is that you can improve documentation as you read it! If you’re learning a new tool, this may be the simplest way to start contributing!
The contributions below were made just as I started studying the tools:
- Lucky - Fix long links in small screens
- Crystal Book - Use simpler algorithm in docs
- Amber - Fix broken links in README
🎨 Use your imagination!
As I said earlier, OSS is not only about code! Any skill you have may be useful to someone! If you’re a musician or artist, for example, there’s plenty of things you can contribute to. Here’s an example of a PR where I created a logo for a project of a friend of mine:
🎯 General advice
- Read contributing guide and code of conduct This should be your first step before actually doing some contribution. Reading those guidelines will help you understand what contributions are accepted, how to make them, and what is necessary for approving them. Those are generally the files CONTRIBUTING.md and CODE_OF_CONDUCT.md;
- Be patient and kind: Maintainers have lives too! Most of them make no money from OSS, so please be patient if your PR takes a while until being reviewed/approved;
- It’s not about you: Do not take things personally! If someone adds a comment about your code, it’s just about your code, don’t be sad about it, but use it as an opportunity to learn something;
- Not everything you do will/needs to be approved: Sometimes our contributions don’t match the project’s needs/vision and end up not accepted, and that’s okay. This is part of open source and we have to understand it. The code you wrote can always live as a plugin/extension too. Here’s three unapproved PRs I did:
💪 Yes, you can
First of all, contributing to open source is not a experienced-developer-only thing. Many of the contributions I did were because I was a beginner on the language/tool. Use this as your advantage: beginners have sharp eyes for missing or confusing docs, for example. Your trajectory can help future beginners have a smoother onboarding!
Look for issues with the tags first-timers-only-issue, easy, beginner and good first issue. And here’s a list of beginner-friendly projects.
Now grab your cup of coffee, stretch your hands and go do something awesome 😉!
