When people ask me how to improve their skills, I often recommend contributing to open-source projects.

I don't recommend that only for honing technical skills. The truth is that I often suggest it to people who want to improve their leadership skills.

Contributing meaningful improvements to an established OSS project is a full-blown training program in technical leadership. One that will improve your skills in programming, documenting, communicating, and influencing people, all at once.

In today's article, I want to expose my thinking about the benefits of this approach, and why I prefer it over starting your own project.

🪴 Why should I contribute to Open Source Projects?

There are many reasons why I consider OSS contributions one of the best training programs for your hard and soft skills. These reasons can vary depending on the role you cover. If you are a software engineer you are looking for different results than an engineering manager or a director.

Let's look at the main benefits depending on your role.

For Software Engineers

If you're a software engineer, you're looking at this potential portfolio of benefits when contributing to an OSS project:

• Adapting to different Coding Standards. Chances are the project you're joining uses different coding standards and principles than the ones you're used to. This is a great exercise in flexibility that will help you move away from dogmatic approaches. Even if you disagree with some of the choices, you'll quickly learn that those standards exist for one key purpose: preventing people from wasting too much time arguing about them.

• Write good PRs. With OSS projects there is rarely an excuse for rushing things through due to production issues. Even when urgent security fixes are required, the process tends to be well-structured. All PRs go through an extensive review, and the bar for getting your code approved is generally high. As most people on the project are volunteers, they will reject PRs that lack clarity, context, purpose, etc. This is a great school for learning how to write PRs to ease the work of those who will review them. It's an exercise in empathy.

• Communication Skills. For any non-trivial feature you might want to propose or add, you will typically need to start by putting together a proposal. This will require you to come up with clear and compelling arguments. You will be required to pay careful attention to the comments or counterarguments you hear or read. As with code, you don't want to waste people's time as that will only increase the chances of your proposal being rejected.

• Influence without authority. If you want to get your ideas accepted and implemented, you'll need to practice influencing gymnastics frequently. You'll learn who are the most influential people in the community; what they care about; how to get their attention; and how to gradually earn the respect of the whole community. This is a long game, and you will face setbacks on the way. All the skills you learn here can be deployed successfully in any professional context.

For Engineering Leaders

If you're an engineering leader you might not naturally think about contributing to OSS projects. As your focus has shifted away from technical tasks, and toward leadership responsibilities, you might assume this task is better suited for software engineers.

I don't necessarily agree with that.

Even if writing code is no longer part of your main duties at work, there is a lot to benefit from contributing to an OSS project.

• Keep your technical skills sharp. Engineering Managers and their superiors often struggle with the need to keep their technical skills sharp while at the same time having to dedicate their time and attention to organizational and strategic topics. Some try to keep a certain percentage of their time devoted to coding with the team. I'm not convinced that's the optimal choice, and I've written about it in a previous article¹.

  Instead, I prefer to recommend contributing to open-source projects. It'll force them to get out of their comfort zone of the company stack, often requiring them to learn new languages, frameworks, or tools.

• Find inspiration for your team. This is one of the key advantages compared to working on some internal projects: you'll gain exposure to different approaches. Some will inspire you to explore new alleys with your team: architectural patterns, documentation platforms, testing frameworks… you name it. It might be as simple as giving you ideas on how to improve the Code Review process with your team, or how to improve documentation for new members. Regardless of whether you will adopt new approaches, this exposure will train your ability to keep an open mind.

• Influence without authority. This is as true for Engineering Leaders as it is for Software Engineers. The same benefits apply here. In addition, this could be a very humbling experience for more senior engineering leaders. Stripped of their titles, they will succeed in moving things if can convince people of their ideas. No executive decision cards are available.

🌱 Why shouldn't I start my own project?

There is nothing bad in starting your own project as a means to improve your skills. I won't be the one trying to discourage you from becoming the next Linus Torvalds.

The reasons why I don't generally encourage it though are various:

1. It might be a manifestation of the Not Invented Here Syndrome². It's a widespread issue both inside and outside of professional contexts. It tends to lead to tribalism, fights, and emotionally loaded debates. Not something I recommend, unless you have very solid arguments of how your new approach will be a huge improvement over all existing solutions.

2. It might be a form of Escapism³. You might be fed up with the hard reality of projects where you need to discuss and agree with people instead of doing it just your own way. You might feel the lure of a greenfield project where you can just use whatever technology you feel like, without having to justify it. Maybe you want to show them that you were right all along, etc. Fine. Whatever your motives are, make sure to be honest with yourself.

That said, launching and maintaining your own OSS project can be a great opportunity for improving yourself and learning new skills, while at the same time contributing something valuable to the community.

If the possibility of leading your initiative still drives you, you might consider assuming the maintainership of an OSS project that has become orphaned.

According to a recent study⁴, half of open-source projects die during the first 4 years of their lives.

Chances are you could find a project in there to make your own.

💡Tips on how to pick a project

Here are some tips on how to pick the project you want to contribute to, starting with generic advice and finishing with a detailed checklist for evaluating candidates.

🎯 Start small, Focus, and set goals

• Pick one project. Resist the temptation to start contributing to 5 different projects. You'll quickly run out of steam.

• Set goals in terms of contributions. To build some accountability and discipline, it can be useful to set goals for yourself. e.g. Have my first PR merged within the first 30 days, or Have 1 proposal for a new feature approved and implemented before year's end.

• Start small: minor bug fixes, documentation improvements, etc. Don't immediately attack the hardest problem, as you're unlikely to succeed. Nothing is more annoying to a maintainer than new contributors joining with plenty of enthusiasm, only to disappear after a few weeks because they picked too hard of a task.

🔺 Mastery, Purpose, and Autonomy

If you're familiar with the concept of intrinsic motivation, you should remember that there seem to be 3 key drivers for it: Purpose, Mastery, and Autonomy⁵.

A complete discussion of this theory is outside of the scope of this article. Suffice it to say that OSS projects provide a great opportunity to find all 3, increasing your opportunities to cultivate intrinsic motivation.

Purpose will be provided by the project's reason to exist. Successful OSS projects tend to be so because they solve a compelling problem. Few things in our industry can match the sense of purpose provided by knowing that your code is used by millions or even billions of people around the world.

Even more so when no one paid you to do it.

Mastery will be provided by the need to improve the skills we mentioned earlier in the article.

Autonomy is at the essence of OSS projects: most people are volunteers, and as such they have full autonomy in deciding when to dedicate time to the project, and whether they do it from home or a beautiful Caribbean beach. No Return To Office policy hanging over you here!

📋 Projects Checklist

With that in mind, let's look at the traits you want to look for in a project. The project you pick is not supposed to tick all the boxes, but the more the better.

Health

✅ An active community and validated user base.

✅ Respectful and welcoming to new contributors.

✅ Limited presence of purist debates. e.g. space vs tab, Vim vs Emacs, etc. That is unless you're really into that kind of stuff.

Relevant

✅ Something you use or are willing to use it once some gaps are fixed.

✅ The technology stack should be somewhat familiar or appealing.

Challenging

✅ It should stretch your skills: new frameworks, patterns, domains, etc.

✅ Avoid - if possible - projects run by friends, your company, etc. That familiarity might turn into a comfort zone.

Realistic

✅ Keep it within your reach. Ambition is good, but maybe don't pick the Linux kernel or K8S as your first project, unless you have extensive familiarity with them.

✅ Bigger projects mean higher complexity, which means higher demands on time and mental energy. Choose a project where the size will not become a major obstacle for you to find the time to get involved.

🏁 Conclusions

I hope this article will motivate you to contribute to OSS projects in the upcoming future.

I used to be quite active in the space. I worked with 3 different Linux distributions, contributed code to Gitlab, and even got a one-line fix merged into the Alan Cox kernel tree about a century ago.

My last contributions to OSS software though date back to 2018, when I added support for TuneIn radio to Volumio⁶.

That initial contribution even turned into professional collaboration down the road. That is another potential benefit of such contributions: you never know what they can lead to until you try.

Maybe it's time for me to find a new project to contribute to.

While I'm mulling that over, I'd love to hear your comments on your own experience with OSS contributions and whether you have similar or different views on the merits of engaging with them.

See you next week!