About one year ago I decided to dedicate some of my free time contributing to open source projects. The idea was to improve my coding skills and get in touch with newer technologies and frameworks. I learned a lot in this time and would like to share with you some tips I wish someone had told me when I was starting.

Here a summary of the tips, if you are more of a tl;dr; kind of person:

1. Start small, learn Git and Github's flows before diving into complex projects
2. Search for "good first issue" or equivalent labels on the projects you want to contribute and start with those
3. Don't be afraid of the feedback you receive on your PRs
4. You can create and manage a project yourself
5. Join or create a community for open-source related topics
6. Remember to have fun

The dawn of open-source (for me)

I figured it was a good idea to start with any of the services or applications I used on a daily basis, as many of them were open-source, and that folks, was my very first mistake. I was faced with really big and scary code base of Softwares like Inkscape and Gimp, overwhelmed by the components and not-so-documented infrastructure.
At first, I got unmotivated by the amount of effort I was putting into trying to understand the code and not being able to progress on simple tasks, so I needed to change my approach.

Baby steps

I realized there were more things I needed to learn, besides the code of a project itself if I wanted to contribute with that project: I needed to properly learn Git and also understand better how Github, the main platform for open-source projects, works.
So I started looking for smaller projects, especially those focused on documenting stuff or needing work on localization (translating software text to other languages). Usually, when the repository has these goals, you don't need to worry about building code, which simplifies a bit of the flow.
Here's my first tip: start small, get the hang of the tools such as Git, understand what are pull requests (PRs), and learn how the flow works.

Good first issue

Once I got the platform (Github) and the tools (Git) understanding out of the way, then I could go after issues that would require more "real" coding. Because I was already familiar with Github, I knew some of the projects have a label like "good first issue", that tracks smaller and simpler tasks. Usually, these repositories welcome new contributors better, with better documentation on how to build and test the code. Tip number 2: look for "good first issue" or equivalent labels on the projects you want to contribute and start with those.

Change requests are NOT your enemies

After a while, I was feeling very good with my progress and contributions, diving into more complex projects each week, becoming better, and strengthening my presence on several projects. My confidence (which I must say, is usually really low - gotta work on that) was over the roof, but even though, on each PR I submitted, I got nervous about exposing my, possibly bad, work for others to review.
In my work life, submitting reviews is something that I don't fear anymore as I know most of the people who review my code and am pretty confident about my coding skills and style for the project I work on. I know that (almost) every issue someone opens in my code had the goal of making the software better and can teach me something new, but I was not applying that on open-source, and that was holding me back.
Third tip: don't be afraid of the feedback you receive, learn from them instead.

The dark other side

After a few months, I saw the need for a simple software to help me control my working hours, and since I was deep into open source, why not make it a project on Github?! So Time to Leave was born and allow me to experience the other side of Github, by managing a project that receives the contribution of people around the world. This whole experience deserves a post just for it, but I'll leave here the next tip: if nobody did what you want, then, build it yourself.

With a little help from my friends

The main thing that motivates me to continue and to discover new things is that I found lots of friends that get excited about open-source just like me. We created groups on which we share projects we found interesting, discuss flows and development problems, and encourage people who want to start to actually do it.
So, my next tip is for you to find people and communities that share your interest in open-source and development. They might be colleagues from work or college, or even strangers on Twitter and Discord channels.

Make it count

My final tip for you is don't forget to have fun! Contributing to open source is an use of your free time. Not all the work you do needs to have a goal that will make your professional side look better. Sometimes you just want to have fun and contribute to a project that does not fit into your standard, and that's totally okay!