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

Huh?

[Garpenlov]

What was the point of posting this, exactly? Just to say.. "open source is the best development method, and although it sometimes seems like the communication methods it forces developers to use can be a problem, actually they are really good, all hail open source." It just seemed like an empty piece of propaganda.. Do we really need that?

why we can't communicate

[gnarphlager]

liver tonuges under goldfish. your egg underneath a telephone wax not unto signal fires dismissal night. BSD concave north button mother pirate other futon! Boxes! Boxes BOXES! Their your our their our our my your. Silver finger people dried ruler. Number meaning star whirl block buddy. Money storage gallon expert library plenty tax the to to two the the two the to.

Once plaid insurance nurse junk early mate hand revised memory stop me practical this a this. Real garden Christ future decomposed designate digits. Private medicine aardvark unless devices and services. Mistaken Lumpar impending eligibility. Hungry vagabonds! You own ham warlords glass household juices.

programmer ego

[Deadbolt]

It seems to me that we nerds have religious attachments to whatever our toy-of-choice is. That's why flame wars and public arguments erupt. One of the problems in developer communication comes from the formation of an open source process: since anyone can come in at any time, different philosophies of approaching the same problem are constantly introduced. The positive effect of this is sometimes overweighed by the inevitable "that's a stupid way to do that. Everybody with half a brain (read: everyone who thinks like I do) knows that the best way to do that is x.")

Since programming is usually such a solitary exercise, I wonder if we get too used to working in our own worlds and have a hard time learning to operate in someone else's. What some of us forget from time to time, though, is that for the process to work, we HAVE to compromise occasionally. <ASBESTOS> Wish someone had told the xemacs crowd that...</ASBESTOS> :)

Literary quality in communication does help

[Animats]

Managing a large, far-flung project via written communication is not an unsolved problem, although it is clearly a forgotten one.

It can be done. See The Autodesk File, a collection of memos from the early days of Autodesk. Autodesk started out with thirteen programmers working out of their homes, coordinated almost entirely by E-mail. AutoCAD was written in that environment.

As Autodesk became more successful, they continued to insist on literacy. From an Autodesk job ad of 1986:
You'll be literate, and able to communicate complicated technical concepts in simple and readable language. Your work documentation will meet the standards of the best tech writers and be suitable for immediate inclusion in our user manuals. You'll be able to express yourself clearly and persuasively, whether in a design session or while speaking with prospective customers at a trade show.

That's how it's done.

Communications & Software Development

[Tassach]

I'm not exactly sure what the author's point is; but he raises some interesting points.

Communication is always a challenge in any software development effort. The problem is worse in a distributed effort like an open-source project, because face-to-face communication is difficult, if not impossible. Voice-over-IP and IP videoconferencing technology is maturing rapidly and will help in this regard; but even this is still a pale imitation to face-to-face communication. It may be low-tech, but a conference room with a white board is still one of the most efficient programming tools around.

The real question here is, I think, "How do you run a successful open-source software project." The answer is that running a successful open-source project isn't much different than running a sucessful closed-source project. From a programming & leadership standpoint, there isn't really much difference between the two. The main difference is that in OSS, it's rare for the team members to meet face-to-face; but this isn't actually all that uncommon in the traditional corporate IS world, especially in big companies. All the lessons learned from corporate software project management still apply to OSS. Good programming and project management principles are universal -- the distribution model is (mostly) irrelvant to the development process

Open-source isn't a panacea; just because it's GPL'ed dosn't gaurantee that a project will be successful. For every OSS success story like Linux, Apache, or GCC there are a dozen OSS projects that are utter crap.

"The axiom 'An honest man has nothing to fear from the police'

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.