Contributing to the cause: Doing it the open-source way

Hello there!

Lately, I have been getting quite a few messages about how one should get started with developing open source projects, or contributing to projects out there. This blog aims to address those queries with the fullest of my knowledge! I tend to clarify the what's and why's of open-source development before actually jumping into the action.

Happy reading!

Intro

One of the most important rule of software development (and any other kind for that matter) is this - Do not re-invent the wheel. This means, we should stay away from working on developing something that already exists, and should reuse it. Therefore, developers often find themselves using a plethora of tools along with their projects to make their work (and lives) easier!

But have you ever wondered where these tools come from? We surely don't pay for using any of these development tools (at-least most of them!).

Well, these code (and also the binaries, sometimes) for these tools are hosted in a free, available to all and developer friendly space called Open Source.

So, what's Open Source?

If you do a Google search, it will give you the following answer:

denoting software for which the original source code is made freely available and may be redistributed and modified

Now, if you have eagle eyes and can understand what that means, feel free to move on to the next section :D, For the likes of me (affinity towards elaborations), do follow on.

Breaking down the definition, it tells us these few things:

We can host our software code in a "space"
This "space" is free to use and available to the world
Our code (and the software) can be distributed among other people, and also be reused by them.

Now, I'll be honest, this is too much an abstraction to build our understanding on. So let us give some life to it.

The "space" that we have been referring to, can be any of the following: GitHub, GitLab, BitBucket, and many more. For this blog, we will stick to GitHub, since that's more beginner-friendly.

GitHub

GitHub is a place where developers can create their accounts and host their code, completely free of cost. Other users (and non-users) would also be able so see the code (until and unless you make it private). It is highly recommended that you check out their platform (and preferably create an account) before you move any further.

Now that we have the stage set up (literally!), we are ready to delve deep into the "why's".

Why use Open Source?

So why all of this fuss, you might ask. To be very honest, this was my first question when I was introduced to open source.

Setting up the scene: Before I started using Open Source to develop my tools, I used to do the following:

Write and save my code locally.
Whenever I had to make any major changes to the codebase, I used to make an archive of the existing code, give it some version number, and then get started with writing the updates.
I used to share the zip files with my friends (who were from non-CS backgrounds) and asked them to MANUALLY set it up using the instructions.
When it came to deployment, I used to upload the code to the server manually and make the deployment run there.
And lastly, I was storing all of these zip files in my Google Drive

Now, any novice can see that there is too much of a manual intervention required in all the steps. To be precise, here are the drawbacks:

Reverting the codebase is impossible if you don't create the versions MANUALLY.
Distributing your code is a cumbersome task.
Collaborating with your friends is next to impossible.
Visibility of code is as poor as the fog in winter.

Back then, I believed that these were more than enough reasons for me to switch my old habits and learn something new. Not to mention, in the longer run, I found the switch helpful in more ways than I could possibly imagine.

Here are a few solutions that Open Source development gives you for the above problems:

All open sourced software use Git, a tool (which is open-sourced as well) that helps you in keeping a track of all the changes, giving you the ability to roll back, reset and fast forwards to any point of time.
Since open sourced software are hosted free of cost, everyone is able to view your code.
Collaboration is a cakewalk: git gives you the ability to develop your features on separate branches, while keeping the rest of the code intact.
Additionally, it provides us with automated notifications, builds and releases if we decide to opt into it.
Many companies open source their software to create a level of transparency with their user base. This helps them to gain trust.

If it's still unclear as to why people choose to develop their software for free, out in the open: It is because of the support of developer pool that you get

Getting started

I'm quite sure that you must be wanting to get your hands dirty, now that you have came across all of it. But, before you could move any further, you should be familiar with the concepts of Git. It is the building block of every open source project. Now, since this blog isn't explicitly about git, I will attach a few links for you to get started:

Now that you are well versed with some of the git terminologies, let's proceed to the actual stuff!

Finding your repository

The first step of this journey is to find yourself a decent project. You can search these projects from any of the following links:

To be very honest, selecting a project can be very tricky. There are a multitude of ways to shortlist a project, but here are some ways that I use:

Look for the programming stack they use. Are you comfortable with it? Do you have any prior hands-on experience with it?
Does the project align with your interest? Is it a tool, or a platform? Does using it feels good? - This matters because the emotional attachment with a project will stir a natural will in you to contribute to it.
Is it being actively developed? - Active projects will give faster feedbacks, and your work will be known to the people.
Are there any active issues in the Issues tab? If no, you might consider moving on to another project.
Can you understand the documentation? - You would be expected to set up the entire project locally without any help (most of the time). So it is super important that you can understand the docs.

Getting accustomed to the project

After you have made a decision, it is now time to start developing. Almost all the repositories follow the same pattern, and I will outline it for you.

The flow

Fork the repository into your account
Clone the fork into your local device
Create a new branch like: feat/feature-name or fix/fix-name

git checkout -b feat/add-logout-button

Develop on the new branch

The first step is to set up the project. All projects vary in this step, but gladly there is a common thread:
- Go through the README.md file. Most of the time it contains info about quick setup.
- Go through the CONTRIBUTIONS.md file. This will contain detailed information about the setup, and might also provide links to other docs.
- Lastly, scan for a docs/ folder, this might contain all the help you will ever need.

The next step would be to familiarize yourself with the codebase. Most of the repositories use monorepos for organizing and managing their code. A rule of the thumb here would be to make yourself familiar with what component lies in which place. It is next to impossible to understand the entire codebase at once. For starters, you can:

Understand how the environmental variables are used
Where does the UI/API/SDKs live
Where does the project fetch its configs from

Making your contributions

Now, we are ready to head over to the issues of the project. Start small - pick up issues that have a relatively smaller scope of impact, like updating something in the docs, making minor UI fixes, making changes in the file names, etc. Some projects use the good first use label to track such issues.

After you have picked your issue, now it's time for you to get assigned to it. For this, consider joining the community of the project - Discord / Slack / Telegram. Many projects encourage you to ask the maintainer to assign you to an issue before you start working on it. Many ask you to put up a PR directly. Most of this is mentioned in the CONTRIBUTIONS.md file. Again, the rule of the thumb in this step is:

Search for an issue
Ask the maintainers to assign it to you over the issue comments.
Optionally, you can provide a suggested way to fix the issue (this increases your chances of getting assigned)
Once done, start following the code guidelines and doing what you do best!
Always remember, deciding on the features with the help of the maintainers is a BIG PLUS. Although, keep in mind that you should not spam them.

Submitting a PR

After you feel that the feature is working as expected, you should always add tests or update them. Making sure your tests are up-to-date and passing makes the merge process effortless. Before you commit the code, do make sure you have gone through the commit guidelines of the project. Almost all projects use this pattern.

Finally, it is the time that you make the pull request (PRs). This is how you submit your code. To do this,

Go to your fork
Make sure your code is not outdated
Select the branch that you were working on
Make the PR from under the contribute section.

This stage requires the least effort. Generally, if you have communicated your way through the implementation, your PR should be merged in a short time.

Your gain from open-source

We humans are outcome-oriented creatures. So, for every action that we do, we expect some sort a reward. And, in case of open-source there are "many" rewards.

You will be surrounding yourself with a like minded peer group who think and act alike. This will enhance your skill set and also, help you become a better human.
You get to showcase your merged PRs on your portfolio! They will give you an upper hand in your itnerviews.
You can get an offer from any of the project you are working on. Most of the open-sourced companies look for full time employees from their pool of open source contributors. Although a bit difficult to achieve, it is certainly possible!
Lastly, you can go for bounties! Yes, bounties! Once you have quiet familiar with contributing, head over to Algora and start getting paid for your work!

Conclusion

To wrap up, I would say that, open-source is an ability that only software developers have. You get the opportunity to work with top class engineers, developing industry grade applications, all while improving your network. No hassle of interviews, no rat-race, no nothing! All that's needed is your time and dedication.

P.S.

A note that I would like to leave here on behalf of all the maintainers out there, which I believe most will be in unison with - When a regular developer thinks about making himself a maintainer of a project, the responsibility comes with a great many challenges. That person is responsible for not only developing the crucial aspects of the project, but also in managing a swarm of developers. Not to mention the fact that, the maintainer choose to open source their product so that world can see and lend a hand in its growth (also, making it free to use). It is my request to all of you who's reading this, to treat them with the respect they are deserving of. Open source is not all about being good at coding, it is also about becoming a better human, and to develop a deeper sense of understanding and sharing responsibilites.

Blog