Contribute to Open-Source Software: A Beginner's Guide
If you like this video, you can find more on my YouTube channel :)
Transcript
How to build a strong profile for your next job? Or your first job? If you don’t have a lot of commercial experiences, one good way to do it is to contribute to open-source projects. In this video, I’m sharing my experience in contributing to open-source projects, and some tips and tricks on how to make your first contribution.
Hi, my name is Adler, and today I’m sharing the basics and some tips and tricks in contributing to open-source projects. I wouldn’t say that I’m an expert, but I did contribute to some of others’ projects, and I would say these contributions do help me build a better developer profile when creating a resume.
For those who have no idea what open-source software is, it is, literally, softwares that has their source code publicly accessible. Everyone is able to read the code, participate in the discussions, and contribute their own code to the project. Some famous open-source projects include programming languages like Ruby and Golang, database systems like Redis, and virtualization tools like Docker. They are basically everywhere in all free and commercial software products.
The next question is: should we start our own project? Or should we contribute to existing projects? These are two different directions. In terms of building a developer profile, it would be fantastic if we can build something to resolve a real-world issue. It can demonstrate that the creator is a person who puts his thoughts into actions, and is able to complete it. On the other hand, contributing to existing projects demonstrates that we’re able to do teamwork, understand code written by other developers, and communicate with other team members. Qualities from both sides are equally important. If you have your own idea, that’s good. You can start creating your own open-source project. If you have no idea what to build yet, let’s take a look at how to contribute to other projects.
When we talk about making contributions, there are actually many approaches. First, we can write some code to add new functionalities, debug, or refactor the existing code. Or, we can help answer questions in issues, do code review for pull requests, or become a sponsor. There are many other ways as well, but In this video we are focusing more on writing code or documents for a project.
Next. Which project should we contribute to? If you just get started in software development, you probably don’t know how many projects are there, and even how many fields are there. Luckily, there are some tools to help us find the right projects to contribute to. Since most projects are on GitHub, it’s convenient to just use the GitHub “Explore”. We’ll be able to browse by projects, or by topics that we like. However, the projects listed there might not be that beginner-friendly due to their complexity. An alternative is to use Google. Search “X programming language open-source projects for beginners”. Usually there will be a couple of blog posts introducing some interesting projects that we might not have ever heard of. I would like to also recommend “Awesome-for-beginners”. It’s a list on GitHub showing some repositories that are beginner-friendly. Or we can find similar results by searching for open issues with a “first-timers-only” tag on GitHub. These issues are more descriptive, and these repositories usually include with more guidance for new contributors.
The most important factor in choosing a project is that it sounds cool. OK. Don’t judge. What I mean is that it has to sound cool TO YOU, personally. Contributing to open-source projects can be very frustrating sometimes, and the best thing that would support us on this journey is our love for this project. If we don’t LIKE a project, it’s very likely that we’ll just leave it there if it’s not going well. However, in addition to “sounds cool”, it would be a huge plus if it also looks cool on our resume. Imagine this. If we’re applying for a Ruby developer position, and we have made contributions to Ruby programming language itself, there’s no way they are not going to ask us for an interview. So, it’s something to keep in mind.
Personally, I would also consider choosing a project that can be run or executed locally on our computer. If your expertise is in C, Ruby, Go, or similar languages, then I would recommend choosing projects that can be used through the command line. It’s easy to run the program, directly see the result, and gives us an idea what this program is doing. On the other hand, if we choose something like “docker” or “kubernetes”, it might be more difficult to test it out directly because we need to set up environments and install many other dependencies.
OK. After we pick one or two projects that we like, we would then inspect the three indicators: complexity, activity, and friendliness. For complexity, a good indicator is the number of commits. The more commits there are, the more complicated the project is. However, don’t be scared away by a high number of commits. Every big project is built on small pieces. As long as you can find something small to start from, it should be ok to choose a big project. On the other hand, if it’s too challenging to find a place to start, we might consider working on other projects. Another indicator is activity. We’ll be able to tell how active a project is from the frequency of the commits and how many interactions there are in the pull requests and issues. These information can be seen from the “insights” of a repository. A good frequency would be having interactions at least once in a few days, including responding to issues, merging pull requests, and closing issues. We want to avoid spending a lot of time writing code and sending a pull request, and then no one even takes a look at it. The last indicator is friendliness. We don’t want to spend time committing the code but getting a negative or discouraging response. Click on the “closed” issues and pull requests in a repository, and see how the conversations went for other developers. Are the maintainers responding to contributors properly, or are they just ignoring the issues? Read the comments and interactions between the maintainers and the contributors. Imagine that if we are having the same conversations, are we comfortable with it?
If we feel that everything is good so far, it’s time to move on to the next step. We’ll need to read and understand the code. We can either start from the entry point of the program, or we can search for specific parts that we are interested in. If the project is beginner-friendly, find a beginner issue and start from the part where the issue is trying to resolve.
Also, here’s a tip. From my experience, as we read the code, we might spot some other issues as well. From there, we are able to make additional contributions by creating separate pull requests for those issues. First. Some documentations are not as good as others. It might include typos, and miss some of the logic in the functions or logic they are documenting. It would be a good time to slip in and improve it. Second. Some scenarios in the codebase are not covered by unit tests. If we find that, don’t hesitate to add more test cases to the code. It’s a quick win, and it actually improves the quality of the project. If you are not familiar with what a “unit test” is, I’ll put a link in the description below for more details.
Keep in mind that for contributing to open-source projects, we want to START WITH SOMETHING SMALL. At this stage, we’re not familiar with the project yet, so there’s no way we’ll be able to open a pull request with some groundbreaking changes. Once we have two or three pull requests merged to the codebase, we’ll have a better idea of the code itself, and we’re more ready to make a bigger contribution. At the same time, we can put the project on our resume, and proudly show that we are part of the open-source world.
OK. That’s it for now. One final suggestion. It would really take some time before we can submit our first pull request. We’ll read a lot of code and figure out their connections. Be patient, and don’t get too frustrated.
If you find this video helpful, please hit the like button and subscribe to the channel. Leave a comment below if you have any questions. I will see you next time.
