Communicate more, not less.

A couple unrelated comments and discussions I saw over the past few days prompted me to write about how the open source way should affect conversations in Fedora. Our modus operandi in Fedora is “default to open.” It keeps us accountable to each other, honest in our assessments, and (hopefully) constructive in our relations with each other.

Most importantly, though, open communication lets others know what we’re thinking and doing, and gives everyone a chance to participate and assist. Without open conversation, it’s infinitely harder to tell what people are up to in Fedora, or any open source work. Sure, you could watch myriad commit lists or RSS feeds, but the trouble with that is there’s no human context around it. And often those automated messages can be confusing or surprising unless someone’s established a prior context around them. The cornerstone of collaboration is communication, and the success of open source depends on collaboration.

Here are some of the opportunities I’ve sometimes observed in open source efforts (not just Fedora) to encourage positive growth toward openness. Sometimes I run into these opportunities personally, and regularly remind myself that increasing communication (rather than simply work output) can often be the best answer.

Do you feel like a lot of work is hanging on you personally? Nothing contributes to burnout quite like when you feel you’re a single point of failure. Making your work more open forces you to confront areas where you’re having trouble, and to ask for help. You can’t be a force for positive change unless you embrace the fact that you can’t do everything yourself. Lydia Pintscher hosted a wonderful article by Asheesh Laroia the other day about how Fedora Design team lead Máirín Duffy avoids this problem by effectively turning “to do” items into open calls to action for the community.

At times it may take more time to tell people about the work than it would to do it. But explaining and documenting are, more often than not, the key to spreading knowledge of, and participation in, an activity. Yes, it is possible no one will help even after you explain and document how to do something. But it’s certain no one will help if you don’t. Building an architecture of participation is to create opportunities for others.

Do you see an area that’s not getting enough attention in your team, even though it’s assigned to someone? The best answer isn’t necessarily to cajole that person, even if you feel like they’re responsible for it. Sometimes the best thing you can do for them is to ask for help on their behalf. There are numerous outlets where you can call out for help: (1) write a blog post that’s carried on one or more aggregators (like Planet Fedora), (2) send status messages on social networking using identifying hash tags about your subject, or (3) make contact with other open source groups outside your project that work on related material, to see if someone’s interested in helping.

Real life happens to all volunteers, and it’s not always possible for them to cover all their responsibilities — volunteer activities frequently take a backseat when available time shrinks, whatever the reason. In Fedora, our teammates are our friends, and we do what we can to make them and our team successful. That might mean helping them find someone to take over for them, if they’re too swamped to follow through.

If you see this happening as a pattern on a team, perhaps it’s worthwhile to examine the scope of the work you’re doing. Do you have enough people to cover it? Consider contracting efforts around a smaller target for a time, while you look for new contributors who are interested in participating. Doing a few things well can be much more rewarding for the team than leaving lots of things incomplete or finishing lots of tasks in a less satisfactory way. (This is also true in the scope of a single contributor — each of us can likely get more satisfaction and pride out of a few jobs well done, rather than many jobs not so well done.)

Are you having substantial conversations privately where the community can’t participate? You could unknowingly be sapping energy from your own team! Remember, one of the reasons we’re involved in free and open source software is that more eyeballs, heads, and hands are inevitably better than a few. Agree on the problem you’re trying to solve first, so you can have a productive conversation about how to solve it. Then make sure you have that conversation in a mailing list, where everyone can see it’s going on, and offer input and assistance.

Community maven/wunderkind Mel Chua has frequently written, “If it didn’t happen on the list, it didn’t happen.” More and more I’ve come to appreciate that wisdom, because frequently the biggest frustrations, confusions, and misunderstandings arise simply because people don’t know what their teammates are thinking or doing. The more open we are in our communications, the less likely we’ll cause those types of problems. Of course, open communication doesn’t equal “no arguments.” But you can choose to have an argument purely about the merits of different types of solutions, rather than arguing about that, plus conflicts over perceived slights, plus issues of hidden agendas, plus… Get the picture?*

Do you feel the need to encourage teammates toward positive transparency? You can help others be transparent by simply asking non-loaded questions in a public forum. Make it clear you’re supportive of their work, and that you’d like to know more about it so you help either by participating, or encouraging others to participate. You don’t even need to mention transparency, since it’s implicit in your public question. In fact, doing so can often be detrimental, with the exact opposite effect of what you intended. If someone communicates with you privately, let them know you’d like to share that with the community, and if it meets with approval, do so promptly and fully. It usually only takes a couple of minor, non-judgmental efforts to help teammates understand the value of “default to open,” so everyone can benefit.

Many times, I find people aren’t transparent simply because they’re tentative. No one wants to be publicly embarrassed, after all! This is why it’s so important to nurture a culture of positivity and constructive behavior in an open source team or project. No one should be afraid to speak up for fear they’re wrong. Being wrong is an opportunity to learn, and not just for the people involved in the conversation. The opportunity also exists for those reading along on the list, or who come across the conversation later thanks to a search engine. Encouraging people toward transparency requires both halves of this strategy to be effective — you can’t simply make requests unless people feel they (not just their open communications) are welcome.

Anyway, these are just some idle thoughts I was having today while exercising and thinking about open communication. I’d love to hear trackbacks and comments from people about their personal experiences and approaches with communicating more openly and transparently, especially specific experiences and how it improved the outcome.

---

* Admittedly, it’s much easier to defuse those problems later if everyone assumes good intentions, but in my experience, most forms of electronic communication make that quite difficult. But that’s a behavior we can all still aim to practice every day!