Traditionally, open source software has relied primarily on asynchronous communication. While there are probably quite a few synchronous conversations on irc, most project discussions and decisions will happen on asynchronous channels like mailing lists, bug tracking tools and blogs.
I think there’s another reason for this. Synchronous communication is difficult for an open source project. For any project where people are distributed. Synchronous conversations are:
- Inconvenient. It’s hard to schedule synchronous meetings across time zones. Just try to pick a good time for Australia, Europe and California.
- Logistically difficult. It’s hard to schedule a meeting for people that are working on a project at odd hours that might vary every day depending on when they can fit in their hobby or volunteer job.
- Slower. If you have more than 2-3 people you need to get together every time you make a decision, things will move slower. I currently have a project right now that we are kicking off and the team wants to do everything in meetings. We had a meeting last week and one this week. Asynchronously we could have had several rounds of discussion by now.
- Expensive for many people. When I first started at GNOME, it was hard to get some of our board members on a phone call. They couldn’t call international numbers, or couldn’t afford an international call and they didn’t have enough bandwidth for an internet voice call. We ended up using a conference call line from one of our sponsor companies. Now it’s video.
- Logistically difficult. Mozilla does most of our meetings as video meetings. Video is still really hard for many people. Even with my pretty expensive, supposedly high end internet in a developed country, I often have bandwidth problems when participating in video calls. Now imagine I’m a volunteer from Nigeria. My electricity might not work all the time, much less my high speed internet.
- Language. Open source software projects work primarily in English and most of the world does not speak English as their first language. Asynchronous communication gives them a chance to compose their messages, look up words and communicate more effectively.
- Confusing. Discussions and decisions are often made by a subset of the project and unless the team members are very diligent the decisions and rationale are often not communicated out broadly or effectively. You lose the history behind decisions that way too.
There are some major benefits to synchronous conversation:
- Relationships. You build relationships faster. It’s much easier to get to know the person.
- Understanding. Questions and answers happen much faster, especially if the question is hard to formulate or understand. You can quickly go back and forth and get clarity on both sides. They are also really good for difficult topics that might be easily misinterpreted or misunderstood over email where you don’t have tone and body language to help convey the message.
- Quicker. If you only have 2-3 people, it’s faster to talk to them then to type it all out. Once you have more than 2-3, you lose that advantage.
I think as new technologies, both synchronous and asynchronous become main stream, open source software projects will have to figure out how to incorporate them. For example, at Mozilla, we’ve been working on how video can be a part of our projects. Unfortunately, they usually just add more synchronous conversations that are hard to share widely but we work on taking notes, sending notes to mailing lists and recording meetings to try to get the relationship and communication benefits of video meetings while maintaining good open source software project practices. I personally would like to see us use more asynchronous tools as I think video and synchronous tools benefit full time employees at the expense of volunteer involvement.
How does your open source software project use asynchronous and synchronous communication tools? How’s the balance working for you?
Hi,
I do not think these are “new” technologies. I think a lot of the work force at Mozilla is “new”.
Open source projects with weak or no financial backings work out the kinks of communication fairly well.
There is always a mix of sync and async conversations. The bulk of it is “fast async” which means nobody expect an instant reply, but they dont expect a reply next week either (replies come within minutes,hours, sometimes a day). It happens over a mix of IRC, mailing list, instant messaging software, etc.
There are also fewer sync conversations, on IRC or video, and not at set times but in an opportunistic manner. Strong difference here: opportunistic discussions result in passionate, caring parties. You don’t have to have it. You’re having it because you love it.
Scheduled meetings result in boredom, people looking at their keyboards. These are small groups too – as you pointed out. More than 3 or 4 is not going to work out. (yeah, my own limit is at 4 rather than 3 🙂
This hybrid model works far better, achieves good balance (which is always the key) but of course, is much harder to apply to “companies” and very few do so successfully.
Finally, a note on async. People who let other people wait days for replies consistently are dropped out of projects. basically someone will take your responsibility and make stuff work – and that’s it.
In companies, nobody will take your responsibility. Rare people will even complain. Their salary, the thing that pays for their home and food is on the line. You could get fired for bringing up that X, Y, and Z do not work well async because they are sloppy with their communication (leave bugs/needinfo/etc open for days, months, dont reply emails, irc consistently) or sometimes are just useless (schedule meetings with everyone, large groups, to talk about ” lead stuff” or “direction” and everyone just look at their laptops.
Therefore, good luck!
That’s a problem. I’m not saying people should be fired necessarily –
My experience isn’t from open source, but I actually find the language issue works much better synchronous. I appreciate your point about the ability to look up words and compose messages, but I find these things are less important than the ability to correct misunderstandings quickly.
If someone has misunderstood something I’ve said, it’s better that they reveal that error as soon as possible so I can set them right, instead of giving them time for fixate on the incorrect version, and embed it into long-term memory.
Doing things synchronous is a lot harder, no question, but it’s also much more effective.
I strongly favor asynchronous, logged communication as the default. Even in small teams that are local. Misunderstandings happen again and again. And nobody notices it when it happens. If the majority of the communication is unlogged and gone in the void there is no way to learn from it. Instead mistrust grows despite everybody operating in good will.
This problem shows up less if your team is very homogeneous: everybody having the same personality, background, sex and age. But that kind of team will have a lot of blind spots that will bite them time after time.
Heh. I read your other blog post first, and was thinking.. so we need an app which promotes asynchronous meetings in open source. Of course it will end up being USENET newsgroups reinvented.. but that is a different blog post :).