"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.
3 Comments