One of the things I wanted to write about for a long time now is how to start contributing to open source. In my case it’s mostly contributing to the Azure Terraform provider. This is mostly related to my work as a Cloud Platform Engineer, but I think you could apply the lessons learned to a lot of open source communities.

They are put in a random order, maybe some of them are not relevant in your situation. But at least remember the first one:

1: you’re welcome

One of the things I learned first, even before my first contribution: you are encouraged to contribute. Not only by the people filing the issues, but also by maintainers of a project. There are often issues marked as good-first-issue, but even without it your contribution on a simple matter are more than welcome. One of the things I realize in hindsight is that contributing doesn’t start with the first issue I picked up, implemented and filed a PR for. It started with reading the issues, looking at the PRs which were currently in progress of getting implemented, requesting access to the Slack channel of the project. Ask questions if you like. And it’s totally okay if it stops there.

If you are a (marathon) runner, it’s not only about you as a runner. It is also about all the people around it, the people planning and building the parcours, but also about the people cheering during the run. It’s even about the people who triggered you to run in the first place.

2: Encourage and cheer

The second lesson comes from the first. One of the things I always underestimated regarding the impact it makes is cheering and encouraging of others. And the best way to appreciate that is to pay it forward. Whenever you feel anyone deserves or needs some praise, put it into words! You might need the encouragement in a later stage yourselve. And it’s basically free. It feels good to give a thumbs up on an issue when someone started working on it. It feels also good to know that someone is watching the issue you are working on

3: Read first

Read everything you can get your hands on with regard to contributions to the project. It helps you build confidence and knowledge about the project without stealing time off the maintainers. Give the CONTRIBUTING.md or simular files a good and thorough look, as it might be different compared to how you are used to work.

4: Start small

After reading through PRs and learning how contributing is done, you are ready to pick up an issue. Don’t feel bad about not knowing everything. But at the same time, don’t pretend you know it all.

The smaller your issue is, the higher the chance it will succeed. And when you get that feeling and enjoy it, it will definitely lead to some bigger PRs in the future.

While I can imagine that your image of a good contributor is the lines of code you’re contributing, it might be that someone who is only answering questions (or at least tries to) has a bigger impact on the project by reducing the time spend by maintainers answering simple questions. Or, to give it another perspective: by adding the necessary tests to the project your impact in the long run might be higher than if you’re changing code without any tests.

5: Be humble

By letting the maintainers and other contributors know it is your first issue, you’re signaling them to give you an extra hand if neccessary. And add some extra explanation in the PR review how to handle some situations in general. If there is a contribution guide, they will probably point you towards it even if you have read it already.

Be prepared to rework your PR a few times, especially if the code base your working on is highly active. Your PR might not have the highest priority, and you might need to work on your git rebase skills during the whole process. These things in general are very useful to learn, especially if you are not a developer by trade. Enjoy the learning curve while you can ;)

6: Happy coding

While your contribution might also have direct value for you as a user of the open source project you are contributing to, it doesn’t have to. Maybe you are doing it as an exercise to get better in a certain programming language. Or you enjoy coding and want to make other people happy with your contributions. Anyway, enjoy it.

7: Contributing too early

Maybe it feels impossible, but it might be that you’re too early to the party. That is not a big problem, but it might give you the feeling that the project is not stable enough to contribute. One of the projects I wanted to contribute to had no good test system. This caused me to blindly contribute, without having the option to rely on the tests of the project itself. This makes it harder to maintain a good pace and makes it harder for a reviewer to check what functionality is actually added to the project.

8: Contributing too late

Actually, too late is not really a thing. It might feel a bit overwhelming to start contributing to a big project like Kubernetes. It is sooooooo big and you’re probably not smart enough to understand the whole code base without investing years into it first. But that should not withold you! It might influence your tactics, how to start your journey. In general I’d advise to start by getting to know the community and the subprojects/working groups better before you start contributing. Not that it’s completely necessary, but it gives a better foundation to build on. When you know some people and have the possibility to ask some questions over Slack you’d probably feel more confident to commit your code.