Contribute to FOSS

27-03-2022

Recently I have been making more and more contributions to free and open source software and I would like to share why you should too. I'm still new to contributing to FOSS but it's been very fun.

Why

There are plenty of reasons for somebody to start contributing. Firstly it's fun, seeing features and fixes that you made be merged into a popular project and seeing them be used by people really boosts your motivation. Secondly you learn, more experienced developers will guide you and help you. You'll be learning better programming, better communication skills and teamwork. Thirdly you might want a feature really badly or some issue is driving you nuts but for some reason nobody is working on it, well you have the control to fix that and others will thank you. This is the reason I got into contributing to FOSS. Additionally it's good for the community, FOSS devs usually are working on their projects in their free time so they don't have much time to do everything they want or need to do. Lastly you might want to check for vulnerabilities and backdoors in a crucial program.

Choosing a Project

Now you are convinced and want to choose a project, how do you go about that you ask. Here are a few suggestions:

How

For software that is on github, gitlab, sourcehut, codeberg what you usually need to do is:

Then you wait for feedback from the devs, make the required changes and at some point your changes might get merged. If you continue contributing to that project you'll need to frequently update your fork by:

You should also read any guidelines on how to contribute that the project may have. There should be some mention of this in the Readme, in the wiki or a Contributing.md.

Tips

Navigating a code base that's not your own might be difficult the first few times, you won't know what is where or what's happening. There are however a few tools you can use to make the process of getting to know a new codebase easier.

Fuzzy file finder

First of all you'll need one of these. A fuzzy file finder returns a list of files based on a search query. Not only is it extremely helpful when you don't have the file structure of an unknown project memorized, it also is extremely fast for projects which you know like the back of your hand. I'm using fzf with vim which is extremely fast. Find something similar for your own workflow.

A screenshot of fzf

Searcher

I don't know exactly what to call this but I mean tools like grep rg and ack, tools that will search your whole codebase for instances of some word or regex pattern. This is useful for when you want to search where and how a particular function is used or something particular happens (example: a property of an object gets assigned). I use ack.vim with rg which lets me also jump quickly to the results.

A screenshot of ack in action

Go to definition/declaration

Another handy tool is the ability to go to the definition of a symbol. Let's say I find a function in my code and then I want to see how it's implemented and what's inside it, I press gd in vim and vim-lsp gets me to the function.

Debugger

Lastly you will need a debugger. Getting a backtrace showing which function called which and how we got to the current point in code, or monitoring state in real time as well as catching segfaults and crashes is extremely helpful. If you are not using a debugger start using one. I have a short tutorial on gdb here.