Tips for getting started with OpenSource
I recently read this interesting article What contributing to Open-source is, and what it isn't. They made some good points on how low-quality drive-by contributions are bad for both OSS maintainers and new contributors. However, I felt like the article was missing good tips for serious contributors looking to get started with OSS.
I owe a lot of my career and learning to OSS. I think it is a great way to build up your profile and quality contributions will have a big impact on your career trajectory. But it is not very easy and like all good things, it takes time.
There are many different ways to contribute to an OSS project, but here are a few tips aimed at those looking to contribute code, and looking to become long-term maintainers.
Pick the right project
The single best decision you can make is to pick the right project for your contributions.
You can use it regularly
I always suggest picking a project that you are using or willing to use regularly. This is because you’ll ideally contribute to the project for many months and it’s always easier to keep up the motivation and energy if you are an end-user of the project yourself.
If you work on a project that you don’t use, after a while, you don’t know what to work on, and which issues have more impact than others. You’ll also be building features based on user-feedback but if you can’t relate to the feature requests, then it gets harder to build the right features.
However, I've seen people get stuck choosing that right project. Sometimes picking a project might be a big enough blocker that you never get started. If that is the case for you, just pick any good project and start contributing. Once you're comfortable with contributing, you'll also gain a better understanding of what is a better project for you. You can then find that project and switch. I started with Reaction Commerce, and later switched to Prometheus :)
Has an active community
Pick a project that has an active community and maintainership. This means checking if the discussions are active and if users are getting enough support. Checking if the PRs are getting regular reviews and if enough PRs are being merged every month.
You’ll have a ton of questions as you start contributing and it’s important to make sure that the community is active. Further, if you spend a couple of days getting a PR up, not having any reviews for weeks is a disappointing contributing experience that will push you away from OpenSource.
Struggle before you reach out
A lot of the guides tell you to reach out and introduce yourself before you contribute, but I don’t think that is helpful advice. Maintainers see A LOT of enthusiastic people reach out, only for them to disappear before submitting a PR. You’re going to get a much better response after you put some effort in.
Every project has a contributing guide and I recommend reading it and running the project locally and playing around with the build and running process first. After that, find an issue to work on. Most projects have issues tagged as “easy” or “good first issue” for new contributors to get started. There are even a couple of websites like https://goodfirstissue.dev/and https://goodfirstissues.com/that help you find these issues. If the project doesn’t have any such tags, I’d still peruse through the list of issues and find one that “looks easy”. It’s ok if it turns out too complicated later, but the idea is to pick something that looks obvious or easy.
And then I’d recommend spending multiple hours trying to solve it. The more time you spend, the better. This would get frustrating, but it is an important step because it’ll help you run the project and understand how the codebase is structured. It’ll help you understand how to run the tests. Whenever I start contributing to a project, I pick a simple issue and then put in a bunch of fmt.Println statements in the codebase to understand how the logic and code are structured.
After struggling to solve the issue for at least 3-6 hours, if you haven’t yet solved it, write a message to the discussion or chat forum with roughly the following information:
- Your name and introduction
- A short line about your motivation and interest to contribute to the project
- The issue you picked, and the approaches you’ve tried to fix it
When a maintainer sees that message, they’ll understand that you spent many hours trying to solve the issue and it shows commitment. They would likely instantly drop what they’re doing to help you. You can then work with them to open a PR with the right approach and get it merged.
Once that issue is done, you can move on to the next easy issue or ask the maintainer to suggest an issue in the same section of the codebase to get you even more confident :)
Stick with it for 6+ months
Once you’ve gotten going, you will quickly be able to contribute an important feature or two. But if you’d like to have long-term impact on both the community and your career, you need to be consistently contributing for at least 6 months.
When I say consistently, I don’t mean working on the project for several hours every day but trying to get in 4 to 5 hours over the week, every week. If you show up consistently, respond to issues, answer questions and start contributing to one part of the codebase, you will very likely become a maintainer for the project in 6 months.
Being a maintainer will add a lot more weight to your profile than simple drive-by contributions. It shows that you can work in a distributed environment, are self-guided and are extremely helpful to others. It will unlock a lot of doors, and you will soon be getting inbound offers for contract work or full-time employment.
Write, speak and build a public profile
While being a maintainer is pretty good, you can maximise your impact by writing and speaking about your work. You should ideally have a blog and start speaking at local meetups. Once you’ve gained some confidence around public speaking, you should try speaking at conferences.
This will help a LOT of people and will also expand your reach. Most conferences also have a “speaker dinner” where you get to meet other speakers. These dinners have let me meet and have meaningful conversations with other developers and leaders I looked up to and helped shape my career trajectory.
Finally, having a good technical blog and conference talks will help you and your profile stand out when applying for jobs. And like above, having a strong public profile will also bring you great targeted, inbound job enquiries. And these enquiries will also likely be around the OSS project you contribute to, making it possible to get paid for your OpenSource work :)