An “open source” project is a development, whose source code can be accessed, modified, shared or used by anyone for different purposes. The public access and contribution keep these projects always updated, and also makes them very culturally rich, since people from all over the world, with different cultures and languages, work in them. The project’s license protects the project and set the rules on how it can be modified and/or used. Microsoft uses the MIT license for most of their open source projects, which is one of the most used licenses by other big companies. However, not all projects use this license as there are many kinds of them with different rules, which you can check out here.

‍

‍

Despite this, not everyone feels capable of participating in an open source project. It might seem like something very distant or hard to do, but in fact, it’s nothing like that. Furthermore, the diversity of opinions, cultures, and ways of working are the prime factor that makes the acceptance of open source projects within society.

In this article, we’ll look through some tips to encourage you to contribute to an open source project with worthy collaborations.

‍

My first thoughts about an open source project

I was never a huge fan of open source tools until I saw the possibilities. As for example, the inclusion of Asian writing support by the addition of vertical text boxes. Until that contribution, it never crossed my mind including support for that culture in any way. These kinds of contributions, done by people all over the world, help overcome physical and cultural barriers. This makes them better than any private development, in which only a few decide the roadmap and how inclusive the project will be.

When my lead told me that I was going to work in an open source project, the first thing I thought was “I’m going to work in an open source project, but my company pays me for it”. Contrary to the idea that all contributions are from non-paid people, many software companies work along with the project maintainers to keep it up and help them prepare everything for future releases. Most of the well-known open source projects (like TypeScript or Visual Studio Code) follow this practice as well.

‍

I began by reviewing the project issues and trying to reproduce them. At first, I thought it’d be hard to get the collaborators attention, as there were many open issues and PRs. However, I was surprised by how quickly they answered. The members’ main purpose was keeping order by tracking every update. In addition, open source projects have rules that help the inner organization.

A few months later, I started to review new features and fixes that people submitted to the project. I was very nervous because I thought “I’m not as experienced as the project maintainers to review others work”. I made a small review with a few naming corrections and… it was very well accepted by the community! This experience taught me that you don’t need to be an expert to contribute to an open source project.

‍

Sounds interesting but … How could I help in there?

No matter your skill, there are many ways to contribute and support is always appreciated.

‍

‍

I have no programming skills

There are many tasks that can be done without knowing how to code. For example, cleaning up the documentation and testing requires a lot of organization, and don’t involve programming. These are tasks that anyone can do (and many developers don’t want to). You just have to download and install the project to start testing it.

‍

I only know the basics

In an open source project, you can learn a lot from very experienced programmers. Most of the maintainers are well known and skilled at what they do. Moreover, they will review every commit you push to the repo and they will help you improve your code. It’s a win-win because you’ll improve your programming skills and the project will grow from your contribution.

‍

I know a lot about programming, but I’m not interested to work for free

Nobody can’t know it all, especially in this profession, where everything changes so quickly. You can still learn from developers that work on different kinds of companies all over the world! Don’t close up to that opportunity. Also, contributing will give you an extra status, which is very appreciated when it comes to new job opportunities.

‍

Things to know before starting

There are different types of open source projects, but the most common and the one we will focus on in this article is the developer community (You can read about other types here). These projects were either initiated by an individual or by an organization, such as a software company, a public administration, or a university. It has a project owner, a group of maintainers, who are responsible for managing the information and communication flow within the project, and a huge group of contributors. These contributors participate in the development process because of diverse motivations and follow different goals, as for example, ideological motives, develop a feature desired by the contributor, among others.

In this kind of projects, maintainers organize releases, prioritize the work, give contribution guidelines and review the submitted PRs. However, these roles are not exclusive, and it’s pretty common seeing contributions by the project maintainers. Sometimes, they’ll even be amongst the most active contributors of the project.

‍

A few tips to contribute effectively

‍

‍

Before starting

Most projects have what you need to know to get started outlined in several small documents. You should start by reading these.

• Readme. Available as readme.md, you’ll find it as soon as you enter any repository on GitHub. This document usually includes a description of the project and links to the rest of the documentation.
• Contributing guidelines. Available as contributing.md, you’ll likely find it on the root folder of the repository or linked from the readme. This document describes how to contribute to the project (mostly focused on creating issues and submitting PRs).
• Code of conduct. You’ll likely find it linked from the readme, if available. This document describes several guidelines to follow when interacting with other users in the context of the project, be it the repository, email chains or calls. Many open source communities adopted the Contributor Covenant code as a guideline, because it expresses their values properly.

‍

‍

Submitting an issue

• Search for similar issues. In the active communities, it’s common to find issues reporting a similar or even the same behavior. This makes it hard for the maintainers and the community to keep track of them. Before submitting an issue, search among the existing ones for similar behaviors and, if you find one, add a comment if you have more information instead of creating a new one.
• Check its current status. Before you start working on an issue, you need to check that nobody else has committed to solving it. Same as if you want to solve an issue, you must let them know to the community that you will be working on it. The key is not to do the same work twice.
• ‍

• Read the official documentation. Many times, mostly when a feature is still in an active development stage, you might find known issues in the documentation. Before submitting an issue, make sure it’s not already listed there. If you’re not sure about the current status of the issue, you can ask first too.
• Follow the template. Many projects include a template to help you write down everything needed to reproduce the issue. In case it doesn’t have one, you should describe the current behavior, the desired behavior, the software and platforms you’re using, along with their respective versions, and steps to reproduce it. You can also include gifs and screenshots to improve your description, and a small project to easily reproduce it is always appreciated.

‍

‍

Submitting your work

• Keep your fork updated. Before you submit the code you’ve been working on, make sure to be on the latest revision. As there are many people working simultaneously, you’ll likely find changes affecting the same code that you’ve been working on, or even code in other sections that indirectly affect your work. Updating your codebase and doing a final round of testing before submitting can avoid finding out later that your submission doesn’t work and having to start over.
• Always test your work. Before submitting your work, make sure to test it through (most projects will let you know how you should do it) and, if there are unit/integration tests, add more or update as required to cover the work you’ve been doing.
• Follow the template. Same as the issues template, it also exists one for the PRs. In case the project doesn’t have one, you should describe the features/issues you’ve been working on, if there are any breaking changes, how you tested it (in case there are no guidelines in the project), the previous behavior and the current one.

‍

Reviewing others work

• Follow the example. Take a look at how the community and the maintainers review the PRs and what they focus on. If there’s a continuous integration set up, make sure it ran successfully and, if it’s not the case, analyze what failed and let the contributor know so they can fix it.
• Help others improve their code. As we said previously, you’ll find people with different skills submitting work on the project. If you find code that can be improved or refactored, explain and help the contributor make the changes.
• Make sure everything works. There are many cases where the code may look fine, but the desired behavior is not working as expected. Before approving a PR, you should pull the code and test it on your machine. If you find any issues, report them in the PR with as much detail as you can (the tips for submitting an issue are also applicable here).

‍

Conclusion

Working on open source projects is a nice way to learn new skills. The OS community works every day asynchronously, and their members are looking for more contributors to expand themselves even more.

You may feel oblivious to the idea of contributing to the world of open source because you know little or nothing about programming, or you do not want to commit to working for free. However, you can contribute no matter your skills and it’ll help you grow as a professional.

I hope this article helped you clear your doubts about this way of working and motivate you to contribute. It’s a huge community that is constantly looking for volunteers, and your help will be very welcome.

If you want to start contributing and you don’t know where to start, you can start by checking out the Windows Community Toolkit repository and look for issues labeled as help wanted, or you can find more information and projects here.

‍

Thanks to Nicolás Bello Camilletti and Kevin Bronstein

‍

Originally published by Barbie Martínez for SOUTHWORKS on Medium 20 December 2018