5 Incredibly Useful Leadership Lessons Learned Working On Open Source Projects

Open-source software projects are fun, and they provide you with freedom of choices and creativity. However, it may come at a price.

The year 2019 marks my tenth anniversary for open-source software projects. I must admit it has been a great journey. Not only I have immersed my head into the arrays of software tools, but I have also learned a lot about the people. I had to work very hard on setting my mindset correctly from being just into the business of bits and bytes to being into the people business. Almost as Linus Tovalds - founder of Linux assesses:

In open-source, we feel strongly that to really do something well, you have to get a lot of people involved.

He's wright saying to get dome something well for the open-source we'll need a lot of people. That respectively means excellent leadership.

What are these leadership lessons?

1. Open-source is not a science. We are not establishing or creating a brand new theory, and we're trying to accomplish something; a piece of software that should do something great. There are no right or wrong answers; it just works or not. Your colleague gets it done in a nonconventional way, great, be thankful for that and move on. You can address coding and consistent quality further down the line.
2. Be teachable. You're not 100% correct even if you are correct. Indeed it has been the hardest lesson and the most challenging.  Imagine getting dome something amazingly great investing long hours and a ton of work, returning to work the next day, and it does not get through. For various reasons; does not comply with coding standards, does not pass automated testing, or even worse - lead developer wants to change it. You have to keep being teachable, remember, your attitude is that what matters.
3. Coding is not enough. You must also explain it. I think Albert Einstein said this:

   You do not really understand something unless you can explain it to your grandmother.

   That's the point; you should also convey your work to your peers. Take a simple situation - passing it to a tester or someone else further down the workflow line; like another developer, front-end person perhaps. A clear set of instructions are vital; in several cases, a supplementary collection visual aids (principal schemas, user workflows, etc.) becomes a must.
4. Your jokes are not always appropriate. Sometimes it feels the whole world admires British humour, yet it is not suitable for every working context. Don't get me wrong here, the majority of devs do love fun, sometimes a light teasing is highly welcomed. However, a script that makes someone laugh on one side of the world could abuse someone else on the other side. Just make sure that they make sense.
5. Maintain a curiosity mindset. As we have already defined: Open-source is not some scientific theory. It is a collaborative effort; there is no right or wrong. It is not easy to admit someone else is correct. Curiosity helps you to keep a healthy level of mental attitude. Implementation is rather simple, sometimes by just asking: "Let me understand your perspective on ..." or "I just trying to comprehend your thoughts ..." would push the air out of your frustrating nostrils.

Always remember; In the open-source, it's not about the linguistics of programming it about the linguist. Leadership is vital; knowing why it becomes more important than how.