Development issues part 1: Project communication [LWN.net]

By Jake Edge
January 9, 2008

Free software projects, like all projects, live and die by their communications; developers must be able to talk to each other easily so that a consistent, coherent result emerges. But developers have differing ideas about what methods to use. A discussion on the Emacs development list provides a nice contrast between two of the main communications methods used by projects today.

Traditionally, developer communications have been handled by the venerable mailing list, but that is changing, at least for some projects. Internet relay chat (IRC) has become the tool of choice for newer projects, which may leave those who are not inclined towards realtime communication out of the loop. Development methodologies are evolving, and some are adopting the new ways more quickly than others – some may never adopt them at all.

The difference between communicating in IRC or via a mailing list is in some ways like the difference between text messaging and email. Email has its advantages, in that the recipient chooses the time to read and respond to the message, but it is often seen as slow. Text messaging or IRC have the advantage of speed; people receive a message and generally respond immediately. But that speed comes at a cost – interrupting the recipient. It also requires a full-time internet connection.

While email archives are somewhat cumbersome to use, they are usable. IRC logs are exceedingly painful as they are not subject-based; they just cover a specific time span of all conversation on the channel. Email conversations may play out over days or weeks, but they are generally easier to follow compared to the multiple interleaved conversations that occur on IRC channels. It is in the nature of the medium: IRC conversations are meant to be used immediately, not reread weeks later.

It is, in some ways, a culture clash. Younger developers tend to be more inclined towards realtime communications, while older hackers tend to be more comfortable with mailing lists. In what would seem to be an uphill battle, Eric S. Raymond has been advocating a more "modern" development style for GNU Emacs. His messages, appearing on Emacs-devel, champion a development style that includes IRC communication, a bug tracking system, and a version control system (VCS) more advanced than CVS.

Raymond's experiences working with the Battle for Wesnoth development team exposed him to some of the newer techniques used in project communication, particularly IRC. He reached a somewhat surprising conclusion about IRC:

And far from finding I can't keep up, I've discovered that I like the stimulation. I grok how the kids feel about this, because mailing-list-only projects have started to seem slow and boring to me, too.

The Wesnoth project uses IRC for all day-to-day design and development decisions, leaving the mailing list for more complicated discussions and white papers. This has the effect of excluding interested developers who are not able or willing to monitor an IRC channel throughout their day, but that is unlikely to be the intent. The reverse is also true: the perceived slow pace of mailing-list only projects has the effect of excluding those with a strong preference for a faster style of development. As Raymond shows, though, there is hope that members of one school can retrain – if they wish – for the other.

While decision making by IRC does not seem to be in the cards any time soon for Emacs, an upgrade to something other than CVS seems to have gained more traction. Richard Stallman has been asking a lot of questions about git while other developers discuss other distributed version control systems (DVCS), like darcs, monotone, arch, and Mercurial. Raymond is working on a survey of the VCS landscape that, once completed, he and others hope will guide the project into a better VCS choice.

One of the main DVCS features that seems of interest to Stallman is the "offline" capabilities. Having the entire history of a project and being able to do commits of work in progress while being disconnected from the internet are features that CVS does not have. Stallman is adamant that the tools used to develop Emacs be usable by those who are not always connected to the net which makes a DVCS rather attractive.

The Emacs project is one of the oldest free software projects in existence; it is, like its founder, fairly resistant to change. While Emacs itself is used by hackers everywhere, it is increasingly falling behind its competitors, at least partially because of the slow pace at which it is developed. Raymond's belief is that by upgrading the tools used to take advantage of advances made since CVS and mailman were new, the time between Emacs releases could be reduced to something more sane. Doing that could go a long way towards making Emacs more relevant to younger hackers:

When those Eclipse fans pointed and laughed because we're still stuck on CVS and don't have a bug tracker, what counter could I have had? They know these are bad choices and they know that I know it -- so when they write off Emacs as old, tired, and irrelevant to anything they're interested in, I find it increasingly difficult to reply.

It is unlikely that just some tool changes will be enough to resurrect the flagging popularity of Emacs, but there are hopeful signs. Some of Raymond's suggestions met a warmer reception than one might have expected. It is clear that a fair number of Emacs fans and developers are frustrated with the current state of affairs. It may be that "just some tool changes" are enough to reinvigorate the project to a point where it attracts more developers and users. That can only be a good thing for Emacs.

(Log in to post comments)

Development issues part 1: Project communication

Posted Jan 10, 2008 7:25 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

The article says, "Richard Stallman has been asking a lot of questions 
about git"....

Distributed version control

Posted Jan 11, 2008 9:42 UTC (Fri) by man_ls (subscriber, #15091) [Link]

Actually, in a general context "distributed" calls for online working -- different machines connecting between them. "Distributed version control" (the phrase in the article) used to be what CVS does -- instead of one machine where everyone develops and keeps code, there is a central repository and a network of distributed developer machines. So you need to be online. Technically git is a "distributed repository", where many developer machines keep different repositories that can be synchronized between them, and that allows for offline working.

Just a pedantic point, but it might illustrate the irony of the situation. For old-school people like Stallman "distributed" does not call for offline working, but just the opposite.

Not just a culture clash -- classes of contributors

Posted Jan 10, 2008 10:29 UTC (Thu) by jschrod (subscriber, #1646) [Link]

The question of IRC vs. Email list is only on the surface a culture clash. But below, it's the
difference between people who can work full-time on a project (or are, at least, full-time
reachable for communication on a project) and people who do so in their spare time. Since more
and more people can afford to make a living out of Open Source software, the first class of
contributors gets larger.

Now, these full-time contributors have already a big advantage when it comes to shape a
project; not only code-wise, but also in architectural and design decisions. This is already
visible on mailing lists, where some people can always respond within the hour (and thus shape
the future discussion) and others answer that evening or the following day. Moving
communication to IRC as some ``standard'' communication medium that's expected leaves those in
the cold who can work only in the evening (or live in other parts of the world and not just in
another US time zone, but ESR seems to be oblivious to that point). And, as noted already, to
read up such discussions later, is much harder with IRC than with email.

Moving day-to-day communication to IRC has the effect of building a cabal for a project, it
forwards the creation of an `inner circle', loosing the bazaar effect that ESR says is so
important. That said, IRC is a very good medium to have project meetings at preset times, to
discuss things that would take too long over email.

For me, the difference boils down to the questions: ``Are main developers expected to be on
IRC the whole day through?'' vs. ``Why don't we use IRC as an additional communication medium
for project meetings?'' The first is bad, the second is good.

Cheers, Joachim

PS: I'm the CEO of a small consulting company. My staff can spent 20% of their time on Open
Source projects of their choosing. But I would not allow them to be on IRC full-time for the
rest of their working time; after all they have projects to do that bring in the money for
those 20% free work.

Development issues part 1: Project communication

Posted Jan 10, 2008 12:37 UTC (Thu) by massimiliano (subscriber, #3048) [Link]

Well, IMHO the two mediums are complementary: both are extremely useful. Only mailing lists are indispensable, and I could never imagine a project managed exclusively on IRC, but having both is the best: you can really "have it both ways"!

My experience is limited to the Mono project (or, better, I have a very deep experience only of this project...). Here, the key is that the mailing lists are the official place where decisions are taken. However, all key contributors (and for sure all Novell employees working on the project) are expected to be present on IRC during their working time. In this way the IRC channel becomes a sort of "virtual office", where anybody can pop up and ask a question, and expect to receive an answer (or generating a discussion) immediately. And this is a huge time saver.

Of course, it is perfectly fine to be on IRC but unresponsive for several hours because you are busy in a debugging session or things like that. And, even more important, key decisions taken on IRC must be summed up on the mailing lists, so that everybody has a chance to participate, and maybe revert the decision (this also mitigates the problem of living in different timezones).

All in all, IMHO both mediums are essential in this project.