Communication and the Open Source Community

The Open Source movement has produced some of the world's finest software through the cooperation of developers worldwide. While it may be the most effective way of writing software the planet has ever seen, it creates its own communication challenges, as well. The days of private, closed-door meetings in pretty offices are over; disputes of all kinds are dealt with publically.

For those lucky enough to live close to people working on their project, development conversations can take place at the local pub, but it's not always that easy. The typical method of communication in Open Source project development is the time-honored mailing list.

The problems with E-mail are numerous, and using smileys and winks only get you so far. In many ways, people communicating via E-mail have the same issues that were addressed back in the BBS days. Sarcasm is a difficult thing to convey, and most programmers are not professional writers. This is also a problem in the private sector, but it's a lot easier to talk your differences out with a beer after work when the person you're arguing with works two cubicles away, and not on the other side of the planet.

If you're working on an Open Source project, the chances are good that you've never met most of the people working on it, unless you and your project-mates frequent Linux tradeshows and the like. However, the rapid deployment of PGP and GPG help authenticate that you're getting mail from who you think it is, not an impostor.

Impostor or not, it's very easy to get impolite when sitting in front of the keyboard, and Open Source project mailing lists are no exception. You've got the basic bugbears of E-mail communication, combined with the very real chances that most of the developers haven't slept in a few days. It's easy to get snippy, especially with the realization that most of the people working on the project are there because they love to program, not because they are being paid to do so.

While mailing lists represent the tried-and-true method of disseminating information among your development brethen, it's not the only way. IRC has been used as a development meetingplace for a while, but also has its own problems. Netsplits, nick problems, and the occasional channel flood can make things difficult.

Jeremie Plante, occasional developer for RPGen, brought up a communication problem of a temporal nature. "I used to have a friend from another time zone who was coding with me, and that was a problem for IRC meetings and other real-time communication. Open Source development takes place all around the world, so time zone is an issue."

One of the biggest problems is that all arguments are usually very public, and can lead to a political struggle within the project. The argument between Eric Raymond and Bruce Perens, although it took place over a year ago, is still fresh in people's minds. When the mainstream media has their ears on the Linux railroad track listening for the oncoming train, they are more than willing to consider an argument between two Linux people as a portent that the house of cards is about to fall. Decentralization of control leads people to believe that just about anyone can be in charge, and the media will consistently rally around the loudest.

Debates and arguments about licensing and definitions of 'free software' will continue to rage on in newsgroups, mailing lists and IRC channels. While some view these issues as divisive, many more inside the community feel that these arguments and debates represent the diversity necessary for Open Source to remain strong and successful.

Comments

Very shortsighted

[FascDot Killed My Pr]

"In many ways, people communicating via E-mail have the same issues that were addressed back in the BBS days."

This sentence is just deliciously indicative of the REAL problem: education, particularly reading/writing skills.

"...back in the BBS days"? How about back in the pre-computer days. Back in the days where, not only did you have to express yourself fully and clearly but ALSO concisely (paper's expensive) AND with a large message latency (several weeks for the Trans-Atlantic mail service).

Managing a large, far-flung project via written communication is not an unsolved problem, although it is clearly a forgotten one. What's the first step? Learn to read. Second? Learn to write.
--

Communication problems actually a benefit

[jabber]

Yes, that's right. I think that the communication problems that open source has to contend with are actually a benefit.

Open source projects involve many people, in different geographical areas, from different backgrounds, often speaking different languages. This level of diversity would be near impossible to manage in a 'traditional' conference room.

The ego factor alone, with cultural alignments taking hold against those who do not pronounce something correctly... Office in-fighting.

The fact that there is so much difficulty bridging interpersonal differences, time zones, cultures, genders (I know, a little) actually helps open source projects get done.

People know that communication is difficult, and they make an effort to circumvent the problems. Knowing that sarcasm is hard to convey, that gestures are not part of the conversation, that tone of voice does not translate into ASCII, all this makes for BETTER communication.

The information that flies between open source developers is often clearer and less ambiguous than corporate memos. There's no room between the lines, so everything needs to get spelled out. In my office, the biggest source of frustration is not the lack of communication, it's the 'fluffiness' of communication.

Memos are sent in response to memos, but do not say anything. Information is provided by indirect reference, not directly (not my job to keep you informed). Everything is phrased in such a was that any semblamce of commitment to anything is purely implicit (it depends on what "it" means to YOU). Every concrete piece of information must be assumed, and things are only stated outright behind closed doors, so it's my word against yours. You CAN'T do that when your developers are half way around the world, and read your email with a dictionary in hand.

The open-forum nature of open source communication also keeps the politics and marketting from taking center stage in the development of the product. There are few clandestine meeting, and few sideways glances. The product is developed on it's merits, and the people with the right skills do the right work.

Competence can be faked in an office, and assignments can be made by and to the wrong people. You can fool the fans, but not the players, and in open source - with poor communication, everyone's a player.

So, sensitivity to the challenge of communication results in less ambiguity and BS-bingo; AND on the Internet nobody knows you're a dog, but everyone knows you can't code.