# Leadership lessons from open source software

Jim Hall

I got involved in open source software, both as a user and a contributor, since I was a university student.
Eventually, I would found one of the longest-running open source projects still in existence.

At the time, all that seemed unrelated to my career as an IT manager, IT director, and chief information officer in local government and higher education.
But I'd come to learn that it wasn't.

Because as I was learning to lead a globally distributed, volunteer open source project, I was also learning lessons that would help me become a better leader in all aspects of my career—and my life.

In this chapter, I’d like to share three of those key lessons.

## My background in open source

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, odds were good that those computers ran MS-DOS.

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

So you might imagine how upset I was when, in 1994, I read that Microsoft planned to retire MS-DOS when releasing its next version 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've helped bring developers together to collaborate on programs. I've 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.

Through it all, I tried to remain open to the leadership lessons that presented themselves.
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.
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.

## 1. Value the feedback

Every software project, whether open source software or more conventional "closed source" software, will have bugs.
There is no program so perfect that it is without bugs.
Those of us who maintain open source software projects rely on bug reports to identify, locate, and fix those bugs.
Those reports are our primary channel of feedback about what's working and what's not.

But an open source software won't get far if its maintainers' 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, when acting as a leader anywhere, 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;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: they get better at 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. Appreciate perspective

Every contributor to an open source project brings different viewpoints to that project.
And those viewpoints make for a *stronger* project.

In his 1999 book *The Cathedral and the Bazaar*, Eric Raymond coined "Linus’s Law," a general rule about open source software development: "Given enough eyeballs, all bugs are shallow."
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."

With 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 projects, in any organization.
No single person has all the answers.
As a friend and colleague often advises, "the answer is in the room."
Effective leaders help to prompt the conversations that reveal it, using statements like "How might we accomplish this?"
It's an open-ended phrase that encourages participants to find a solution collaboratively.

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

In open source software projects, leaders can be tempted to do everything on their own.
Many people get into open source software for the sense of accomplishment it provides, and nothing like creating a software package on your own can help you feel like you've really achieved something.

But you won't get far in an open source community by adopting this kind of 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 once struggled with delegation; I always thought I could do the work better myself.
And 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.

## Conclusion