Re: What a modern collaboration toolkit looks like

["Eric S. Raymond" <esr@thyrsus.com>]

Richard Stallman <rms@gnu.org>:
>     > I usually don't have an internet connection, so I could not possibly
>     > use the methods you recommend.  I cannot communicate with people by
>     > IRC.  I cannot get information from a web interface.
> 
>     Er...perhaps you should fix these problems, rather than allowing them
>     to limit and damage Emacs and every other project you are involved in.
> 
> I will not turn my life upside down to follow your recommendations for
> development tools.

It's not the fact that they're my recommendations that is relevant.  Don't
turn this into a personality issue, it's not one.  It's a question about
how your choices affect the projects you are responsible for.

*You* are talented enough that you can out-code most other people even
when they have modern tools and you're refusing them.  But this isn't
true of most of your contributors -- by imposing your limits on their
working methods as well as your own you're putting the projects you
run under a severe handicap, damaging their ability to ship timely and
high-quality code.

Telling evidence for this is the very long interval between Emacs
point releases and the trouble you have been having clearing your bug
list.  In 1997 the Emacs project's performance on these scores would
have been well within the normal range, given the number and quality
of developers you have -- but the world has changed, the tools are
better, the typical tempo of development is faster, and in 2007 this
project's performance looks really bad.  Unpredictable intervals of
more than a year between point releases just do not cut it these days.

Here's a scale indication: Battle For Wesnoth does a point release
pretty regularly every three weeks, and they're usually good releases.
This is by no means exceptional performance in 2007.  With decent 
tools and practices I'm sure we could match it.

Very unfortunately, the second-order effects of poor productivity
may be worse than the first-order ones.  Many younger developers out
there think Emacs is limping along on old ideas and old tech, its
glory days long in the past.  I think they're seriously wrong,
because...well...I think Lisp is eternal; earlier this very evening at
a holiday party I was defending Emacs against a bunch of Eclipse fans
who think I'm nuts to hold onto it.

But it gets harder to maintain that position as time goes by.  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.

Emacs will never be irrelevant for *me*; it fits my hand too well.
But a thing I was painfully reminded of just a few hours ago is that
we're losing the kids (for values of "kids" up to about age 35).  That
means we're losing the future.

And that's why, when you block your projects from using modern tools,
it's a serious problem.  I certainly don't expect you to "turn your
life upside down" to meet my preferences -- but if you're not willing
to do it so the projects that have been your life's work will remain
able to attract new blood and have a healthy future, that's entirely
another matter.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>