4 Ways to Contribute to Open-Source Without Writing a Single Line Of Code

Open-Source works when everyone contributes, otherwise, it’s a personal project that somehow got made public by accident. But as developers we often think that the only way we can help a project is through our coding, and that can be a scary thought, specially so if you’re just getting started. This is why many new developers get discouraged from entering the Open-Source world, after all, why would their code be good enough to be accepted into the ranks of projects such as React.JS or Vue? Right?

Not quite, actually, as a Jr. developer your code is just as valid, but I get that not every project might be tailored to your particular level of skill. However, coding is definitely not the only way in which you can contribute and give back to your favorite Open-Source project. And in this article I’m going to show you 4 ways in which you can do it, without writing a single line of code.

1. Through bug reporting

It might not sound like much, but as a user of the project you’re very much responsible for letting their maintainers know if there is a problem. Why is that? Because you might be the first one to ever encounter this problem or even use the product in that way. By reporting your findings, you’re helping coders understand a lot about the way their users use their product. And let’s face it, it’s free and it probably takes you less than 5 minutes, why wouldn’t you?

Now, consider the following when writing the bug report:

1. Look for guidelines on their Readme.md file. Usually projects will have a section inside their documentation dedicated to bug reporting. If there isn’t anything, chances are there are templates for the type of ticket you can create. Make sure you fill them in with as many details as you can. This is because saying “The library isn’t working for me” is not a valid bug report. A basic report should provide, at least, clear reproduction steps, version number and relevant dependencies listed (with their versions), your expected output and the actual output received.

2. Don’t report the bug and forget about it. Sometimes maintainers might need to ask for further details or they might ask you to run some commands and report back the results. Since they can’t really log into your computer and run the tests, they might need you to perform some local troubleshooting, so maybe leave the tab open for a while before giving up on it altogether.

3. Do not demand your problem to be fixed. Look, I get it, you’re using their project for your own project and you can’t move forward with the bug there. Fine, but that doesn’t give you the right to demand anything from a team of developers working for free so you can get your project working. Instead, if this is your situation, try to fork the project and find a solution of your own. That way you can even try to send a PR and contribute through code as well.

4. Provide some visual aid if applicable. If your bug is also affecting the presentation of the application, instead of saying “it looks wrong”, provide a screenshot so they can see exactly what the effect of the problem is. Remember the whole “a picture is worth 1.000 words”? It might as well have been said by an open-source maintainer.

If you’re an active user of the project you want to contribute to, bug reporting might be one of the easiest ways to get started with contributing to it.

2. Writing Technical Articles about it

Open-Source projects rely quite a lot on their community. If their users don’t actively work towards telling others about these projects, then chances are, they’re not going to grow.

One major way you can contribute to this growth phase of an open-source project, is by spreading the word about it.

How can you do that? Through writing! Writing articles online is free, you can reach plenty of other developers with a single article and tell them all about your favorite open-source project, why it’s so cool and why they should check it out. Platforms such as Medium.com, DZone.com, Hashnode, Dev.to and many others allow you to reach thousands with a single article.

Granted, the better the article the more chances it has to reach more developers and convince them about checking out the project you’re writing about. And that can be hard if you’ve never written online before. If you want to know the structure of a good technical article, you can read my detailed review here, but in essence, you have to remember to:

1. Write an introduction that captures the attention of your readers. For example, open with a common problem that you can then solve by using the project you’re going to be covering.
2. Make sure the actual body of the article, where you go into the details is not too long or too boring to read. Keep the examples flowing, try to write casually and don’t use overly complex terms unless you have to. Remember, this is not a scientific paper, it’s an article meant to spread the word about an open-source project.
3. Remember to write a final section where you recap everything you’ve covered and ask the reader to share the article online, hopefully helping you spread the word as well.

Writing can be scary if you’ve never done it before, but it’s a great way to help projects organically grow their reach.

3. Teaching through the open-source project

Writing articles is one way of doing it, but there are many other ways in which you can teach others how to use the project you’re trying to help.

Do you not like writing? Maybe consider creating online videos then. A free and very well known platform for that is Youtube, you can get started with a Google Presentation (or a PowerPoint PPT if you’re one of those people) and a screen recording software like OBS which not only does it allow you to record your screen, but you can also record your own camera and capture audio at the same time. You don’t need to know how to do anything special, just select the input sources you want to be active (i.e your camera, or your screen) and click “start recording”.

When you’re done you can edit the video through some free software such as LightWorks and then upload the final file to Youtube or your preferred video platform.

Use the videos to teach about the project you’re helping. Make sure they’re interesting to watch, so spend some time in the visuals, use your own voice (don’t just write text with music) and consider adding your face in there as well. The latter might help your viewers to connect with you and keep coming for more.

Do you want to take your teaching to the next level? Then consider using one of the major online courses platforms, such as Udemy.com, Educative.io, and Coursera.org just to name a few. Each one will have different conditions and you’ll also be able to make some money out of the experience.

Open Source Session Replay

OpenReplay is an open-source, session replay suite that lets you see what users do on your web app, helping you troubleshoot issues faster. OpenReplay is self-hosted for full control over your data.

Start enjoying your debugging experience - start using OpenReplay for free.

4. Provide translations

Internationalization is a big issue with open source projects because providing language files requires people who actually speak that language. You can’t just go to Google Translate and call it a day, while the service is great, it’s not perfect and your project will end up with some very funny options on the menus and window titles.

If you happen to know a language that hasn’t been covered yet, consider providing them with the proper translations. Even if there are no tickets open to cover that requirement, a Pull Request that adds the ability to reach a brand new audience is a PR that the maintainers will love.

Even while this is probably not a coding Pull Request, remember to properly go through their contribution guidelines (you’ll most like find a reference to them inside the Readme.md file at the root of their repo) before pushing any changes. There might be explanations and certain considerations that might apply to non-coding contributions as well.

Conclusion

Perhaps none of these options sound appealing or interesting to you as a developer, but consider that if your aim is to help an open-source project then you’re probably doing more than any coding PR could do. You’re helping spread the word about it, thus helping them reach others and growing the community around the project. Contributions like these are just as valid and appreciated as taking the time to write code for a new feature or fixing a bug, so don’t disregard them as useless simply because they don’t involve code.