Welcome to the World of Open Source!

Yes, this year also marks my fifth anniversary working in the world of open source. Before that, I had several incursions into this world as a developer, but always as an amateur. Obviously, I had already been a user of this software for years. The truth is that it is an exciting world as well as a complex one. For this post, I thought I would give advice to those developers who are getting involved in this world for the first time, rather than recounting my adventures (I may do that later).

Enjoy the journey. Seriously, absorb it all! Entering this world is not going to be easy or quick, but if you think it’s your thing, you’ll like it.

Above all, be patient. The world of open source is made up of a wide variety of people, and each project has its own set of rules and customs, which takes time to get used to. Keep in mind that project maintainers don’t have to do this professionally, so they may take a while to respond. It may also be that they have other responsibilities, or that they are saturated with reviewing other people’s code, or an even larger set of things that I’m not going to list but that I think you can imagine. To paraphrase a certain political leader: Ask not what the project can do for you, but what you can do for the project. By this, I mean that sometimes it is more useful to review other people’s code or improve the documentation to take some of the workload off the maintainers.

Next, read the documentation, if any. Projects usually document how to participate in the project, which is very useful when starting. If there is no documentation, you can switch to a project that does. Consider coming back in the future to create it yourself though.

Adapt to their customs. There are always customs, and in the absence of documentation, you can look at how the community behaves and imitate that behaviour.

Many projects usually have some kind of continuous integration. When you submit your changes, make sure it’s green. If it’s not, check the reasons and fix it. I’m serious! This is very annoying topics for maintainers.

Be polite when you communicate. Engineers sometimes seem a bit autistic in this sense, and we forget that there are other people on the other side of the connection, so it’s good to remember to be polite. This applies to all of us, even if there are people who forget it.

Projects often have tags or labels to indicate those bugs that are easy to fix. Start with these as a first contact. They usually help to understand the community, its rules, its customs, and in general how the project works.

And remember, enjoy the journey! The first change is usually the hardest, and you know that what is difficult for us is more satisfying.

Listen to feedback, especially from the people who maintain the project. After all, it is them you have to convince to introduce your changes.

Don’t give up and persevere. No one had their changes accepted at the first attempt. Here are some examples of my iterations and conversations so you can see that it’s not easy, but if you keep at it, you’ll get there in the end:

1. cache_req: Multiple objects were found when only one was expected: My first change in SSSD took several iterations, and it was quite simple.
2. ldap: retry ldap_install_tls() when watchdog interruption: This other change in SSSD took me a lot of iterations and you can see that it didn’t introduce many changes in the code, but it was difficult to explain and I was just a novice in these matters.
3. System test framework: This change in shadow is very recent and has more than 50 comments, but when introducing a new testing framework there is no choice but to revise it little by little and improve it as feedback comes in.
4. spi: dt-bindings: Document CS active-high: I had to make three versions because of a simple change in the documentation, but that’s what happens when the last time you contributed to this project was more than 10 years ago.