Open source success starts at zero

Always give 110%? Maybe not. Here's why "aiming to be a zero" may be a better strategy for success
462 readers like this.
Top open source projects to watch in 2017

"Always give 110%." Many of us have heard this growing up, and throughout our entire professional careers. Although this is good advice on one level, it can also hurt our chances for success if taken to an extreme.

A couple of years ago, while on an international flight to Korea, I started reading An Astronaut’s Guide to Life on Earth, by Colonel Chris Hadfield, the first Canadian astronaut ever to lead an International Space Station mission. This book changed my perspective forever on how companies and individuals should approach working in open source communities.

Hadfield, like all astronauts, went through a lot of training, preparation, and hard work before he ever got to fly in space. What he learned from all of that was that team dynamics were a critical component to mission success and getting back to Earth safely. Through all of this, he developed a philosophy for working effectively in teams, especially as a new member. He called this method aim to be a zero. The basic premise is that if you try to give 110% (be a +1) when you initially join a team effort, you hurt your chances of long-term success in that effort. Aiming to be a zero means that you are competent, while learning how to be an effective member of the team.

This has applicability in a lot of different areas in life. For example, I use it in my volunteer efforts with Cal Fire, where integrating as part of an overall team effort in fire prevention and firefighting is required to get the job done.

Here are concrete ways you can aim to be a zero in an open source project, with your eye toward making +1 contributions in the future.

Do your homework

As Hadfield found in the space program, and as I’ve experienced in volunteering with Cal Fire, there is no substitute for doing your homework before you attempt to join or contribute to a project community you aren’t familiar with.

Here are some of the basics you want to determine:

  • What communication tools are in use? (IRC, Slack, email lists, forums, etc.)
  • What are the communication norms on these tools? (high-level discussions, deep dive technical, etc.)
  • What development process does the project follow? (short, active release cycles or longer, larger releases)
  • What does the project governance look like? (what does a successful pull request look like, how do people get code accepted/reviewed, etc.)
  • What does the project’s leadership structure look like? (benevolent dictator, distributed leadership, etc.)

Getting the answers to these questions not only helps you understand what the project is doing, it gives you a framework to determine where you can start contributing in a way that shows you are competent, but doesn’t scream, "I’m a +1; look at me!"

Offer to do the dirty work

Once you’ve established some understanding of the project and community, you are ready to start making contributions. A great way to do this in a "zero" way is to look for things that could be considered dirty work, especially areas like:

  • Documentation (open source projects almost always have a dearth of this)
  • Testing/QA (ditto to the point above)
  • Answering questions (which has the additional benefit of helping you learn the code/project more completely)
  • Bug fixing/triage (these are often challenging, but can be seen as mundane by other developers)
  • Community management/evangelism

By diving into these areas specifically, you not only get to learn on the job, but you also show that you are trying to have an initial "neutral impact" while you come up to speed. Existing project members will notice this, and you will help cement your reputation as someone who wants to make the project better, not just someone looking to flaunt their reputation.

Treat everyone with respect

Hadfield recounts stories of his fellow astronauts who never flew in space. Almost to a person, one of the overriding factors in their non-selection was their perceived "+1-ness." He points out that the notion of ‘expeditionary behavior’ is critical in space flight (especially long-duration missions). Simply put, this means that you need to be able to count on the people you work with and get along with them well enough to accomplish the goals of the mission/project.

This means treating everyone with respect, whether or not you agree with their position on a topic or a piece of code. Remember:

  • You never lose points for professionalism.
  • Criticize the code/solution, not the person.
  • Don’t wave your (or your company’s) reputation like a flag.
  • Understand that respect is a two-way street (you need to give it to get it).

At this point, you may be thinking, "Well, sure, this all sounds like common sense." Here’s the secret—it is; however, when companies and their priorities get involved in open source projects, sometimes common sense takes a back seat to what the company (or even the individual) thinks needs to happen.

Every company and every individual has a certain amount of ego—that’s healthy and expected. The trick, though, is to understand that human dynamics (the "soft skills" so often talked about) are at the heart of all collaborative efforts, whether you are orbiting 249 miles above the earth, working at a wildland fire command post, or contributing to an open source project.

Your ability to aim to be a zero before you start to have +1 impact is what gives you and your company the critical edge in helping both the open source project and yourself succeed.

Learn more in Guy Martin's talk Aim to Be an Open Source Zero at Open Source Summit in Los Angeles.

User profile image.
Guy Martin is the Director of Open Source & Standards at NVIDIA, where we works with the Omniverse product team on helping them navigate the open landscape with projects such as Universal Scene Description, MaterialX, and many others. He also consults with the rest of the organization on open source best practices.


There are a lot of good points here. One might sum it up as "wear your newbie badge proudly!"
One thing I would like to see, though, is a reduction on the disparaging comments about documentation: "Documentation (open source projects almost always have a dearth of this)". Maybe better to say, "Open source projects can always use more and better documentation." Turn blame into invitation and opportunity.

Thanks Greg for your comments. I'd agree that 'wear your newbie badge proudly' is a great summation.

I certainly didn't mean to disparage documentation, simply to point out that it's usually not the first thing a lot of open source projects get to. I do like your phrasing though, and I agree that there is always opportunity to improve more than just code in open source projects.

In reply to by Greg P

OUTSTANDING article. You should write a book on this subject; seriously.
As a long time Linux 'newbie', I am, quite literally, appalled at the tremendous amount of people who use their 'positions of aid' only to show others how smart they are.
A professor I once knew used to start out his new-term orientation class with "...I'm not up here to show you how much I know, but how much you are capable of...".
Very good!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Get the highlights in your inbox every week.