Leadership lessons from open source software

I’ve been involved in open source software since I was a university student, both as a user and a contributor. Later in my career, I served as an IT manager, IT director, and chief information officer in local government and higher ed. While these IT roles were completely unrelated to my personal interest in open source software, I found I could leverage many of the lessons I learned throughout my history in open source software projects.

My background in open source

Let me first share my background in open source software. I’m of the generation that used MS-DOS when I was growing up. MS-DOS was pretty much the workhorse operating system of the 1980s and early 1990s. As businesses began to deploy computers in the office, the odds were good that those computers ran MS-DOS.

As an undergraduate physics student in the early 1990s, I used MS-DOS for everything. I wrote papers in a DOS word processor, analyzed physics lab data using a DOS spreadsheet, and spent my free time playing DOS games. I considered myself a DOS power user.

So I was understandably upset when, in 1994, I read in technology magazines that Microsoft planned to do away with MS-DOS with the next release of Windows.

That was when I decided to create the FreeDOS Project, an open source software project to create a free version of DOS. FreeDOS caught the interest of many developers from around the globe who joined our growing open source software project.

Since 1994, I have served as the coordinator of the FreeDOS Project. In this capacity, I helped bring developers together to collaborate on programs, created “vision” statements and other documentation to get us all pointed in the same direction, and I oversaw each release of the FreeDOS Operating System, before handing off the "distribution maintainer" role to others.

FreeDOS is only one part of my open source software experience. I have served as founder and coordinator of several open source projects, and contributed as a developer to dozens more: the GNOME desktop, a music player, a game, a compiler, an editor, and other programs.

And in working in open source software, I have learned many lessons about leadership that I apply every day in my professional career. I’d like to share three key lessons from open source software that I later adopted in my career as chief information officer:

Leadership lessons from unusual places

Looking for leadership lessons through the lens of unexpected sources can be interesting and insightful. We need to find inspiration from everything we experience. For myself, I like to reflect on what I have done, to find ways to improve myself.

As chief information officer, I leveraged many of the lessons I learned from maintaining or contributing to open source software. While I find insights from other areas, experience drives learning, and my twenty years of personal experience in open source software has taught me much about accepting feedback, listening to others, and sharing the burden. This applies directly to my professional career.

1. Value the feedback

Every software project, whether open source software or traditional “closed source” software, will have bugs. There is no program so perfect that it is without bugs. In open source software, we rely on bug reports. That’s our feedback to what’s working and what’s not working.

But your open source software won’t get far if your default response to bugs is to make excuses. If a user discovers a problem in your software, you need to accept that feedback, fix the bug, and move on. If you instead respond with excuses (“But I did that because …” or “But that’s something you should avoid anyway”) then your open source software project is doomed to fail.

Similarly, in leadership, you need to accept feedback and comments, from all quarters. Feedback is a gift, and we should seek out feedback so we can improve ourselves. At the end of any large meeting, I like to pause and ask for feedback. A simple exercise to identify what worked and what we should change next time helps to keep things on track.

When soliciting feedback, your audience needs to know that you will listen to what’s said. Resist the temptation to respond with excuses (“Well, we did that because …”) but instead accept the gift, and say “Thank you.”

We all need to hear feedback from others, even if that feedback is difficult to hear. Managers who receive feedback from their staff become more effective managers, including coping with their emotions, empathizing with individuals and resolving conflict. But managers who do not receive feedback from staff are less likely to change their behavior.

2. Everyone brings different viewpoints

And those viewpoints make for a stronger open source software project. Eric Raymond coined “Linus’s Law” about open source software development, claiming “Given enough eyeballs, all bugs are shallow.” (Raymond, The Cathedral and the Bazaar, 1999.) More properly, the law states “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.”

When you have many developers involved in an open source software project, the solution to a problem will be obvious to someone. But one developer working alone may find they are stumped to find a resolution.

The same holds true outside open source software, in any organization. We don’t have all the answers. As a friend and colleague often advise, “the answer is in the room.” I find it helps to prompt a conversation with “How might we accomplish this?” The phrase is open-ended and encourages participants to find a solution.

3. You don’t have to do it all yourself

In open source software development, it can be tempting to do everything on your own. Many people get into open source software for the sense of accomplishment, and there’s nothing like creating a software package on your own to feel like you’ve really achieved something.

But you won’t get far in open source software with a “do it all yourself” attitude. In any sufficiently large or advanced project, you need to work together with users and developers.

Years ago, a mentor helped me realize that an effective leader delegates. I used to struggle with delegation; I always thought I could do it better myself. I feared that someone else might do the task incorrectly, or at least not to my preference. But we can’t do everything; we need to pass on assignments to those in our teams, and trust that they will do the right thing.