10 Steps to Becoming an Open Source Contributor

10 Steps to Becoming an Open Source Contributor

In my previous article, “Top 10 Reasons Your Company Should Contribute to Open Source Projects“, I listed the why?of open source. In this article I’ll explain the how. Many developers shy away from open source for various reasons, such as lack of time, fear of putting in public poor craftsmanship or concerns about getting involved with toxic people. Assuming this is not you, this is where anyone can get into open source and grow as a developer.

The main take away is that you don’t have to be a superstar in order to contribute and even make a significant contribution. Just by getting familiar with a project, you can put yourself in a prominent position and help the community quite a bit. The power of open source is in the community. Successful projects are the ones that have an active user base. If you can help a project grow the community or help existing community members be more productive, then you have a real impact.

1. Read the Docs

It is surprising how many people participate in various projects and activities (not just open source), but don’t take advantage of available materials and help. Just read the docs and you’ll automatically jump to the top 10% of the community members. Reading the docs will tell you a lot about the state of the project, and of course, of the documentation itself. You can start helping right away by fixing typos and grammar and noticing inconsistencies.

2. Participate in the Conversation

Join the mailing list, IRC, Stack Overflow or any other communication channel that the community uses to discuss and share ideas. Listen and read first and as you become more familiar and involved you can start posting too. You can help newbies almost immediately by pointing them to relevant sections of the documentation (which you’ve wisely read) and later respond to deeper questions as well as suggest features, comment on posts and discuss future directions.

3. Use the Software

But, don’t just mince words. Take the software for a spin. Use it earnestly and get a sense from a user perspective. If you have no use for it, maybe it’s not the right project for you to work on. Looking at the software from a user perspective is invaluable. In most successful software companies it is a common best practice called “dogfooding” where developers use the software they develop. You will very quickly run into issues that annoy you. This is good. Don’t be frustrated. This is one of the great benefits of open source. You have the power to change what you don’t like. The next three sections propose several ways to scratch your itch.

4. Report Bugs

The simplest and most basic form of participation is reporting bugs. You see something broken ??? you report it. It’s that simple. Hopefully, someone will take notice and fix it. When you report a bug it is very important to provide as much context and information as possible. The ideal bug report has exact steps to reproduce. When a developer wants to fix a bug, they have to be able to reproduce it first, understand what the problem is, fix it and then they can test and verify that after the fix, it is not possible to reproduce the bug anymore.

5. Contribute Fixes

Now we’re diving deeper. You’re an active member of the community. You’ve got the coding chops. You want to help even more or there is this bug that’s low on the priority list, but you decide to make it your personal quest. You will need to feel comfortable with source control systems, coding and testing, as well as the whole open source development life cycle (forking, pull requests, etc.). If you’re not there yet, there is definitely a learning curve, but there are many resources to learn all about it. Once, you have the necessary skills, just pick a bug and fix it. Make sure to test it properly and document your fix and potentially discuss in one of the appropriate forums before you even begin your quest. In general, be a good citizen of the community and follow the development guidelines.

6. Contribute Features

By now, you feel very comfortable with the code base. You read it multiple times (at least parts of it) and contributed a few minor bug fixes. You understand the architecture and how different parts communicate and exchange data. You have this really cool idea for a new feature. Unlike bug fixes, it is very important to discuss new features beforehand with the relevant stakeholders (in particular the lead developers). Your feature may or may not be in kind with the general direction of the project. Maybe there is an alternative solution. Maybe someone else is working a similar feature. The last thing you want is to work hard on a new feature and have it rejected outright. Make sure you work on things the community and committers can get behind by discussing them first.

7. Write a Tutorial

Some open source projects are huge and very complicated and it is difficult even for experienced developers to contribute bug fixes and features to the core. You can still contribute a lot by writing a tutorial. The more mature and complex a project is, it typically has more options, modes, configurations and different ways to use. Potential new users can get lost and lose interest. By writing a clear step by step tutorial that demonstrates how to use the project and how to accomplish something is priceless.

8. Write an Example Application

This can be done as part of a tutorial or on its own. Write a non-trivial application that other people can use as a starting point and have a real-world example. This is often what’s required when people finish with the documentation and the tutorial (which is often geared more toward readability and conciseness). Writing an example application will boost your own understanding and knowledge of the project and may help feel confident to start contributing to the core itself.

9. Start Your Own Project

This is a great avenue if you’re a little shy and worried about getting into the mix with a lot of talented people and not sure if you’re up to it. Start your own project. Get familiar with the process, distributed source control, the tools. As you gain experience and knowledge, and your project grows, you may cultivate a community of your own or some people may just find your project useful and start using it.

10. Speak at a User Group

This is more about interaction and communication. Public speaking can be intimidating for some people, but is a worthwhile skill to have and can help new open source projects (either yours or one belonging to someone else) by making other developers and users aware of its existence and starting/growing a community. There other similar channels, such as hackathons and conferences, and even writing blogs and essays.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist