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
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:
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.
to post comments)