Aim to Be an Open Source Zero

My two biggest dreams growing up were to be either a firefighter or a space explorer. Though I didn’t get to do either of those things, I satisfy the former via being a volunteer in prevention with Cal Fire, California’s state fire department, and the latter by reading everything I can get my hands on about space—both fiction and non-fiction.

I recently picked up Col. Chris Hadfield’s book about life as an astronaut, An Astronaut’s Guide to Life on Earth, and began reading it during one of my international trips to Asia.

Besides being a fascinating read (I highly recommend it), it has also been enlightening as I think about how I can do my own job better and counsel internal developers and Samsung as a whole on doing a better job in open source.

Aim to be a zero

In chapter 9 of the book, Hadfield writes:

“In any new situation…you will almost certainly be viewed in one of three ways. As a minus one: actively harmful, someone who creates problems. Or as a zero: your impact is neutral and doesn’t tip the balance one way or the other. Or you’ll be seen as a plus one: someone who actively adds value. Everyone wants to be a plus one, of course. But proclaiming your plus-oneness at the outset almost guarantees you’ll be perceived as a minus one, regardless of the skills [or value] you bring to the table or how you actually perform.”

While this may sound defeatist, it actually has a lot of relevance for how individuals or corporations should approach working in open source.

It resonated with me as I considered other things I’ve written on community interaction, including the last statement of one of my recent blog posts: "Be humble, but bold."

As I thought about Hadfield’s words, it was very clear to me that he’s talking about the same thing. While you certainly should want to be a 'plus one' in any open source community you're a part of, you need to do your best to be a zero—not tipping the balance one way or the other—especially at the start of your interactions.

This applies to individual open source developers, but is especially so for those working on behalf of a company. There is nothing that will cause a community to, at best, ignore you or, at worst, actively campaign against you, faster than jumping in and immediately trying to be a ‘plus one’ from the start.
Does this mean you should shrink into the background and not ever speak up? Absolutely not, but there are some general guidelines you can follow to help you get to that 'plus one' status.

Do your homework

There is simply no substitute or shortcut for doing your homework/research before attempting to have an impact on an open source project.

Among other things, you need to understand how the community communicates (mailing lists, forums, or internet relay chat (IRC)). You should also know how ideas get proposed (bug tracker or mailing list) and discussed.

Additionally, it helps to understand how the community is governed—is it hierarchical with maintainers/sub-maintainers (like the Linux Kernel), or is it a mostly flat structure (such as the Debian project)? Understanding this helps you identify the key leaders and influencers in the project, which will help you later on as you start to propose changes or new ideas.

Finally, understanding the flow of development is critical—how many stages does a bug or new feature go through before it’s accepted into the mainline? Are some areas more contentious than others? All of this research will help you when it comes time to fix a bug or propose and implement a new feature.

Offer to do the dirty work

When explaining how to enter the International Space Station for the first time, Hadfield writes:

“The best way to contribute to a brand-new environment is not by trying to prove what a wonderful addition you are. It’s by trying to have a neutral impact, to observe and learn from those who are already there, and to pitch in with the grunt work wherever possible.”

In an open source project, just as in the space station, there are innumerable tasks that need to be accomplished. Yes, the glory may be in writing code, but almost all projects I’ve ever seen have urgent needs in one (or all) of the following areas:

• Documentation
• Testing/quality assurance
• Bug fixing/triage
• User interface/user experience
• Community shepherding/evangelism

Often by contributing in one of these areas, you’ll gain expertise and understanding you didn’t have about the project before you started. You’ll also show your fellow community members that you can be trusted with more and more responsibility as time goes on.

Treat everyone with respect

There has been a lot of commentary in the last several years about how some open source projects are "hazardous work environments" because of the vitriol spewed on mailing lists, IRC, etc. However, as I tell staff within Samsung (and other companies I’ve consulted or worked for), "You never lose points for professionalism."

Learning to take feedback gracefully (even if it was not given that way) and reworking your code, suggestion, or just commentary on a mailing list, is important in learning how to work effectively in this environment. While the transparent nature of most projects’ communications helps enforce this a bit, remember that any private communications you have with project members are important as well.

Hadfield tells a story about how would-be astronauts were basically disqualified for space duty because they couldn't 'play well with others,' or treated medical or other support staff poorly. You may be the most brilliant developer on the planet, but unless you can interact gracefully and treat everyone with respect, you're unlikely to be successful in open source in the long term.

Bringing it all together

All of these points are really about a single thing: understanding your environment. Hadfield sums this up beautifully:

“When you have some skills but don’t fully understand your environment, there is no way you can be a plus one. At best, you can be a zero. But a zero isn’t a bad thing to be. You’re competent enough not to create problems or make more work for everyone else. And you have to be competent, and prove to others that you are, before you can be extraordinary.”

It’s important to remember that the lessons he shares in his book were born out of hard-fought (and sometimes life-and-death) situations. While working effectively in open source projects isn’t in the same league, the lessons he shares about living and working 255 miles above earth in a multi-national collaborative effort are just as applicable to being a trusted member of the open source community.

Originally posted on Open Source Delivers. 
Reposted with permission and under Creative Commons.