I brazenly believe that contributing to open source puts you miles ahead of the average developer.
Saying this after collaborating with developers for years. Contributing to open source nurtures some great habits and etches them in your brain’s muscle memory. People used to contributing to open source have good developer reflexes as secondary nature.
The main thing about open source is that it trains you to become considerate. You care for collaborators, users as well as your future self. You modulate the project’s direction towards stellar maintenance. You care about engineering a swift and painless onboarding experience.
Developers who don’t contribute to open source miss basics such as writing a good README. A good README is the first step for open source projects as it is the project’s window display. It boosts or dunks adoption.
A good README ensures that even when the developer is not around people can come and setup the project. It is a basic litmus test for your professionalism. I would be less inclined to work with someone who has to be begged hundred of times to craft a good README, don’t you think?
Constantly contributing to open source makes you a generally good developer in the sense that you are exposed to production-grade software. This of course if you contribute to software that’s used. You get an idea of the level of professionalism needed and learn about the importance of foresight. You are always on the lookout for things that could go wrong and how to handle them as gracefully as possible.
If you are exposed often, you also learn the very latest standard for your tech-stack or field. For example: what is the best way to run CI or the best test framework or better libraries. Oftentimes contributors propose great changes and you sit back and learn. Oftentimes you just spy on competitors and learn.
Often contributing to a quality project means that you routinely are in a mature contributing cycle. You are sometimes the reviewer, sometimes the one correcting your own PR, sometimes going back to the drawing board. You also write based documents explaining your idea or feature and why you think this should go forward.
Then you also have the ability to communicate asynchronously and drive initiatives forward. You don’t have constant meetings. Sure the setting is different and the pace also but, you bet on being able to communicate clearly and objectively, without office politics.
Open source also teaches about dealing with people. You need to deal with contributors, orient them for proposals and be willing to sacrifice part of what you wanted. You learn to codify your vision, hoping for at least the evolution looking like some 80% of what you intended. You also learn to take ownership and look how the overall picture impacts your part.
Dealing with open source people in commercial setups is really nice as you have someone who has a decent level, can communicate and collaborate smoothly with autonomy.