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. Today, I’m a chief information officer in local government. While my day job is unrelated to my personal interest in open source software, I find leverage in many of the lessons I learned throughout my history in open source software projects.
Let me first share my background. I’m of an age that I used MS-DOS when I was growing up. MS-DOS was pretty much the workhorse operating system of the 1980s and early 1990s. If you had a desktop computer in the office, the odds were good that the computer ran on 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, I analyzed physics lab data using a DOS spreadsheet, and wiled away my free time by 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.
Looking for leadership lessons through the lens of unexpected sources can be interesting and insightful
And so 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, and in over the next few weeks, dozens of developers from around the globe 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, from Alpha 1 in 1994 to version 1.2 in December 2016.
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’ve carried into my career as chief information officer:
Feedback is a gift
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.
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.
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.
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 leverage 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.