Slashdot Mirror
Communication and the Open Source Community
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.
You trust all three less once you learn how they're made.
Seriously, my opinion is that there isn't a problem. Frankly, the debates open source has are exceptionally polite and professional. This is how programmers talk to each other- cope with it. They do it in the corporate world as well.
There are three differences. First of all, it's done behind closed doors, so you never hear of the personality conflicts, shouting matches, and even physical assaults, that occur. All you see is the corporate flack painting a Leninist picture of unity of purpose as the entire company strides in lockstep towards a glorious future of increasing shareholder equity. Pay no attention to the men behind the curtain.
Second, in open source, your career isn't threatened by the decisions made. And, by armchair phsycoanalyst extension, neither is your identity. A better example of this than the Bruce Perens/Eric Raymond/Richard Stallman bruhaha is the Gnome/KDE conflict.
In a corporate environment, only one of Gnome or KDE would be developed. The other team would be told "Sorry- you can't work on that anymore, and we're going to throw all of your work into the bit bucket, where it'll never see the light of day again. Better luck next project." Development on Gnome does not preclude development on KDE, or vice versa, giving advocates on both sides room to back off and not take it so personally.
Of course, there is still a lot of strutting and bragging that goes on- "My project is better than yours!" (Especially from those who are at most marginally associated with the projects- AC, this means *YOU*. You rarely see this sort of strutting from the project leads). This is normal, and goes on in the corporate world as well. Heck, it's natural human behavior- listen to new parents talking about their kids.
The third difference are that the debates are public.
Brian
Funny to see this topic on /.
m .org/58.txt
t ml/1999/06/msg00319.html
I *just* discovered IPSec's rather bloody implementation history. I think I'm just gonna Res Ipsa Loquitar here...trust me. If you ever wondered whether RFC's had any drama in their birth, well...
Take a peek:
http://www.google.com/search?q=cache:gnietf.vls
http://www.sandelman.ottawa.on.ca/linux-ipsec/h
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
One argument in defense of public flame wars, that's always struck me as misguided is "In open development, these things are public. You don't think Bill Gates and Steve Ballmer go at it like this also? The difference is they're doing it behind closed doors so it's not in the press."
No doubt that's true, but it seems to me to miss the point. To the degree that you're conducting activities in the public view, you need to behave differently.
What I'm listening to now on Pandora...
I don't want to start any of your people's damn religious wars but I think this is very valid for the discussion. The BSD license allows for a more centralized appraoch to the development of said program. If a project has a core group that is in charge of all actual code changes with other people suggesting and contributing you'll have that number fewer people you don't know communicating. Having a core group also prevents people from seemingly controlling the project because they whine the loudest. Closed source development is pretty efficient in development because it works in this fashion. Open Source still has something to learn.
I'm a loner Dottie, a Rebel.
First of all, this is not a problem that is only relevant to open source development. I pay the bills by doing commercial projects on a freelance basis. I now live in New York City, but used to live in the country. My current project involves collaboration with a group in holland, and business types who work down in the financial district.
Email and Listservs are very useful because you get a nice record of everything to reference later. Another nice thing about email is that it encourages (at least in theory) people to think carefully about what they want to say, and how to say it. Unfortunately, the latency is high, and for highly interactive exchanges, this can slow things seriously. IRC would be a decent way to work, or perhaps even just ICQ/AOLIM or the like. Haven't tried it yet.
We use the phone a lot. It's nice to be getting payed, because you can justify this. Of course, conference calls for OSS development is sort of out of the question.
This brings an interesting question - where are strong realtime collaboration tools? Preferably free ones. While not everyone has a fast connection yet, soon voice-over-ip should be plausable.
Also, I know of commercial collaborative-whiteboard type applications. I can imagine how this could be very useful. We recently flew the dutchies here just so we could draw shit on paper/walls.
So, who wants to start a conference-call/shared whiteboard OS project with me?
I'd rather be able to sail toward fish and turn up toward tide pool with a little sidewinder than be restricted by the user interface which you're looking at but merely wrapped around you.
This /. BBS has a prettier look but is very similar to forums back then (and PLATO had graphics then, even if only in orange-on-black), although now there's a Web to point links at. IRC is old hat also, there were talk programs on hundred-user systems with dozens of participants -- using a network instead of a central computer is only an implementation detail.
The worst thing is when you find yourself simplifying some data structure so that you won't confuse someone who thought his freshmen "algorithms" class was the sum total of human knowledge of the field.
On the other hand, I've known a few old geezers (no other word for it, even though they were young) who insisted that every meaningful discovery in computer science was made by 1982. Nothing since then - Red-Black trees, splay trees, the astoundishing advances in solving matrix equations, are worth learning or using.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Let's put this education argument in perspective. I've seen this argument before, and as I recall the educational norms of the period you refer to (mid-18th Century to mid-19th Century, ending with the contemporary introduction of the telegraph, railroad and steamship) include:
<ul>
<li>High schools either did not exist, or were a weird idea out of the rebellious American colonies. The elite had private tutors, but the vast majority of the public learned from on the job. BTW, adolescence and even "childhood" are modern concepts. Even a 6-year-old can work in the field pulling weeds, etc.
<li>In the 19th Century, when universal public schooling was becoming widespread most working people dropped out by the 8th grade. Among blue collar urban workers and rural residents a 4th grade education wasn't uncommon.
<li>A typical 12th grade education included a strong emphasis on the classics - Latin and Greek, with an extensive reading of the classics in their native language. Don't believe me? - look up the history of the Kansas City public schools sometime.
<li>Even "professionals" often had shockingly modest backgrounds, in modern eyes. A country doctor might not even have a high school degree, and no collegiate experience outside of "medical school." Don't forget that this period predates not only drug therapy (which requires a solid foundation of organic chemistry), it predates the introduction of "germ theory." A modern boy scout with a "first aid" merit badge knows more about medicine than most of these doctors... with the notable exception of practical experience.
<li>A college degree was a mark of extremely priviledged background. There were no college majors as we know them today - everyone studied everything. (Hence the term "university".) Of course, to them "everything" meant more Classics, modern theology, and maybe an incidental class or two to cover everything that happened in the past 1500 years. IIRC the first College of Engineering wasn't founded until well into the Industrial Revolution -- definitely after the era of rapid transcontinental communications.
<li>Finally, take a close look at the educational credentials of our modern heros. Charles Darwin was a professor of theology - IIRC the only college degree granted in England at the time he was a student. I'm not so sure about James Watt, but again I'm sure it was primarily, if not exclusively, classical and Christian theologian.
</ul>
And never forget that this period was far more classist than ours. There were no "self-made men" - most other business owners would shun someone without the proper background regardless of the merits of their business offer.
In this environment, <b>of course</b> your average business correspondence would shame modern authors. However, if you make this a fair fight and compare the top 2% of the population you'll find that our ancestors come across as one trick ponies. They could write better, but we are better at communicating to the masses. They would have a better understanding of classical music, painting and sculpture, but we have a better understanding of other culture's art and abstract art. The know Christian theology... and why everyone else is going to Hell. We have an awareness, at some basic level, of other theologies. Their natural science is laughable - the modern 2% reads Scientific American, a magazine which wasn't founded until after the end of the period your refer to.
Overall, I think I prefer generalists who occasionally have a hard time articulating their ideas than one-trick ponies whose primary skill, in hindsite, was in running the European Colonial system.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Brilliant. Get that in a book, and you will be bigger than Joyce!
-
We cannot reason ourselves out of our basic irrationality. All we can do is learn the art of being irrational in a reasonable way.
BTW, I'm talking about this paper on the UC Berkeley campus this weekend.
Ceterum censeo Microsoftam esse delendam.
I wrote a paper a while back about whether/why Slashdot is a successful 'community' and talked a bit about communication structures, kinda. Feel free to email me for it.
BTW, I'm talking about this paper on the UC Berkeley campus this weekend.
Ceterum censeo Microsoftam esse delendam.
BTW, I'm talking about this paper on the UC Berkeley campus this weekend.
Ceterum censeo Microsoftam esse delendam.
As for the disputes, I have found that participation in open source mailing lists has led me to be more polite, and more deliberate in what I say. I try not to give offense, even while I am opinionated. Based on what I have seen, there are a lot of people who act the same way. We are trying to exchange ideas and we are willing to put in the effort to make it work.
The net will not be what we demand, but what we make it. Build it well.
Take slashdot usually people disagree and can flame others. However people have things called lives. Usually this allows the individual to calm down and think things through. Plus e-mail is usually not instanteneous and allows for greater though than say IRC or another near insteneous system.
Slashdot social engineering at it's finest
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?
Development of open source is not the only development model where this is a problem. Increasingly companies are hiring coders. Now consider that if I want the best I may not be able to have that person get into the office. Communication via e-mail and chat systems would become an ideal solution to that problem. All code could be done via ssh or whatever with cvs.
So basically this is not propaganda but a methodology that is almost necessary given specific circumstances.
Slashdot social engineering at it's finest
A few obvious guidelines:
--
Listening for the sound of the coming rain...
In my experience the best programmers on any team are not motivated by money or the threat of losing their jobs. The portrait of a hacker from the Jargon File is very accurate in describing what motivates good programmers. Let's face it, any halfway talented code-jockey can quit his job and get one paying the same (or more) quite easily; this has been the case for several years at least, and probably will remain so in the forseable future. If you don't keep your hacker happy, she'll walk, regardless of what you're paying her. If you have to hold a gun to your programmer's heads to get work out of them, you need to take a serious look at your corporate culture.
I've been programming professionally for nearly 12 years, and have worked on a lot of different projects in that time. Without exception, the projects that had an opressive enviornment worked slave-driver hours, and produced crappy, bug-ridden, ugly software. The projects that produced good results were the teams that fostered a fun working enviornment. In my experience at least, productivity and quality of work are directly proportionate to team morale.
"The axiom 'An honest man has nothing to fear from the police'
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
It seems that email is often too harsh, because the "normal" way of social control does not work. But this social control often is there because someone is the chef, and because agreeing to someone's else sayings has something to do with the figures on my paycheck...
In "normal" companies the decision-makers are often not the same people that are competent enough to make this decision. And often we struggle to agree with them because this will push our career up. Ever wondered why companies do not often use the technical optimal solution?
The nice thing in OSS: this kind of social engineering does not work quite the same way. We listen to Linus because most of us agreed that he is competent enough to make a decsision - not because he is good at playing career-games most adult people are wasting their time with.
That is, the technical best solutions are discussed in an open atmosphere by people willing to archieve something other than climbing the social ladder.
This is: to me, even the flame wars will do us better than the I-agree-with-you-because-you-pay-me. And it seems: OSS has shown this already.
You found a sword: +4 damage, +5 moderator points
Traditional programming process has had almost a half century to mature, where open source has had maybe five years to climb out of the ad-hoc status it has held so far. So naturally there will be some jaggies along the way.
Perhaps even more important, though, is that OSS is, right now, almost as much a rebellion as an enterprise all its own. Rebellions always attract fractious people who have an emotional attachment to "the cause". When OSS becomes mainstream and people start calmly devoting more attention to processs design than holy wars, most of the flame wars will settle down, IMHO. No one wants to be known as the asshole.
-N
I am the one true god. However, as an atheist, I don't believe in myself. I guess I have a self-esteem problem.
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?
--- Where's my X.400 protocol decoder?
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.
Bad things often happen to good people,
It is up to them to see that they remain good.
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> :)
"Honey, it's not working out; I think we should make our relationship open-source."
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.
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'
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
"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.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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.
-- What you do today will cost you a day of your life.