When was the last time you used open-source software?

Don’t answer. I’ll tell you when: right now. Regardless of which browser you use, most likely there are open-source components in it. Firefox is open-source as a whole; Chrome, Safari, Edge and Opera all have open-source rendering engines; the only notable exception is Internet Explorer, but it is increasingly obsolete. Open source has taken the world by storm: it is everywhere.

This is especially true of the most prominent projects, like browsers, but they are only a part of the picture. On the other end of the spectrum is a long, long tail of small codebases, a lot of them being one-man projects. Millions of them, in fact. At the time of writing, GitHub alone has 37 million registered users and over 100 million repos, a huge part of them open-source.

And you’ve decided to contribute to this richness. But how? Let’s find out.

Find a project you want to contribute to

The journey starts with you. Ask yourself: why do I want to contribute to open source? Put another way, what are your goals? There are a number of common answers to that question, and they’ll affect the choice of project you want to work on.

In his essay “The Cathedral and the Bazaar,” Eric S. Raymond quipped that “Every good work of software starts by scratching a developer’s personal itch.” Perhaps you’d like to reuse that React component for your brand new app, but it doesn’t support the thing you need. Or perhaps you’re just sick of that bug in the password generator you’re using. Either way, you have a specific need, and that need is not met by the software you’re using.

Or you might be in an exploratory mood. Machine learning is all the rage these days, right? So you might want to find a ML project and add your own little piece to it.

Your goal might also be career-oriented. If you want to land a job at a specific company, it’s a great idea to find out whether they are maintaining any open-source projects, and become involved with one of them. To help you out, WorksHub lists some companies that need help with their open-source projects. Some of the issues there also come with financial compensation, so you can earn while you learn!

Contributing is participating in a community

So you know your goals and have a project you’d like to contribute to. The next thing to realize – perhaps the most important in the whole process – is that developing open source is a social activity. There is a community around your chosen project, and you’re about to become a part of that community.

Different communities are organized in different ways, have different priorities, and communicate using different means. Your first step is to find out what specific rules and guidelines your project follows. Read the README, the contributing and coding style guidelines, and the code of conduct if provided. If these documents point you at any other information you need, read that too.

Needless to say, you should follow that guidance. Be respectful to the community and open in the way you communicate. You can’t get wrong with that.

Once you have absorbed all the official info, it’s time to approach the community. It’s probably a good idea to start passively. Does the project have a mailing list for developers? Subscribe to it, and spend some time reading it. Is there an open issue tracker? Read the discussions that are taking place right now. That way, you’ll get a sense of what’s happening, what the current priorities are, and who can help you out if needed.

Find a specific thing you want to work on

Depending on your story so far, you may already know the answer to this one. If not, though, it can be hard to decide.

One important thing to keep in mind is that coding is not the only way you can contribute. In fact, you don’t have to be a programmer. Many projects are in dire need of good documentation: writing documentation can be one of the most beneficial things you could bring to the project. Look at Write the Docs’ Guide for some valuable tips.

If documenting is not your thing, another great way of contributing is reporting bugs. As an old adage goes, “A well-written bug report is worth its weight in gold.” Heed the advice in this excellent article.

Many projects have localized user interfaces. If you speak a non-English language in addition to English, you can help to translate the UI and make the software accessible to more people.

These are the most common, but not the only ways to help out. Your project may maintain a list of most urgent tasks, or ones most accessible to newcomers. On GitHub issue tracker, as well as on WorksHub’s Issues page, look for the “good first issue” tag. If you can’t find such a list for your project, feel free to ask the maintainers.

It’s also a good idea to discuss your proposed solution if you do know exactly what you want to solve. It can save time to both you and the other members of the community if you reach out and say “hey, I want to do this thing, I have this idea of proceeding.” This gives you the opportunity to discuss alternative approaches. People can find flaws in your reasoning or offer valuable suggestions. Often, the end result is a high-quality contribution and a more pleasant experience for everyone.

Hack hack hack

You have a project, you have a task, you’re all set to go! On WorksHub’s Issues page, click the Start Work button: it will mark your interest in the issue at hand and give you some initial useful information.

Often, your first step will be building the project and setting it up locally so that you can make local modifications. This will be explained in the README and can be either as simple as one command, or a complicated process taking hours to set up properly. If it’s on the complicated side, don’t give up too early: the obstacles will be opportunities to learn.

Start small. Make a tiny change, such as altering a message displayed by the program. Rebuild. Invoke the action that triggers the message. Did it work? If it did, congratulations: most of the obstacles are behind you, and you can start doing the actual thing. I can’t offer any specific advice, but the great minds that Peter Seibel interviews in his book “Coders at Work” share some tips about how they approach familiarising themselves with a new codebase.

Good luck!

Submit your change

You’ve made a change, you’ve tested it, and you’re pretty sure it works as intended. It’s time to share it with the world.

Create a pull request (on GitHub, GitLab, as a mailing list post, or whatever way your project prefers). Write a clear message describing what your PR changes, what key decisions you made, and why you did things the way you did. Put yourself in the maintainer’s shoes: given your description, will they be able to assess the merits of the change? It’s also a good idea to make the PR self-contained, and not too big. If it changes more than one thing, maybe it makes sense to make more than one.

Once you’ve submitted it, the ball is out of your hands. If you’re lucky, you’ll receive a thank-you message, and your PR will be merged straight away. Chances are, however, that you might receive comments and a request to revise your changes before they go in. Don’t take them as criticism of you; rather, think of them as an opportunity to learn – or at the least as a sign of different preferences. There’s more than one way to do it, as they say. It may take a couple of iterations, but as long as everyone cooperates, the change will eventually be accepted. Congratulations, you’re officially an open-source contributor!

Open-source maintainers are busy people, so it may take time to review your changes. Be patient and understanding, and remember that there are humans on both side of this process.

The alternative route: maintain your own

Sometimes, you have a specific problem that you know how to solve, but the existing solutions just don’t quite cut it. Maybe you want to explore a novel approach to a problem, or just play around with some ideas. In this case, why not go the alternative route, pick a license and put your work in a publicly accessible place for all the world to benefit?

There’s nothing inherently magic in open-sourcing your project. Most people won’t initially notice, unless you spend some time announcing it in places frequented by your potential audience. And then, once people start using your code, submitting bug reports, enhancement requests or PRs – you’ll find yourself on the other side of the fence we were talking about. You’ll assume the role of a community builder. You’ll be the person reviewing things, talking to people, encouraging them to contribute and making decisions – a one-man steering committee.

Have a look at the tips on how to maintain an open-source project. And remember to take good care about yourself.

Wrapping up

Contributing to open source is not easy, especially as a beginner. However, it can also be a very rewarding experience. Everyone’s path through their first contribution will be different, but I hope this article will help to clear the typical route up.