Re: What a modern collaboration toolkit looks like

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

Alan Mackenzie <acm@muc.de>:
> A few suggestions:
> o - Emacs is implemented in a wierd special purpose language.

Right.  And how many hundreds of thousands of users do we have
teaching themselves beginning elisp by doing small local
customizations to their .emacs files?  No, that won't hold water.
 
> o - Emacs is already so good that it's difficult to see room for new
>   features.  

I had to rewrite VC-mode recently because it couldn't drive modern VCSes.
When I did so I discovered that several key functions had been hacked
into a state of severe mal-design.  No, "Emacs is too good" won't 
work either.

> o - Much core Emacs code has, despite RMS's good sense and emphasis on
>   simplicity, become tortuous and difficult to get into.

There is probably something to this.

> o - Emacs is a victim of its own success - as its new features make it
>   steadily easier to use, it becomes steadily more intricate and thus
>   harder to learn.  A non-user of Emacs cannot become an Emacs hacker.

And to this.  Though why it's a problem that non-Emacs-users can't hack Emacs
when we have so many users, I don't see.

But while your last two problems contribute to the mess we're in, they're
not sufficient to explain it.

> I'd think it's worth emphasising that CVS is _NOT_ a poor tool; it's an
> exceptionally flexible, solid and reliable one, free from feature bloat,
> and I'm grateful indeed to the hackers who've maintained it over the
> decades.

Clearly you've never used a decently-designed VCS.  Do you have any idea
of the kind of horrible shite CVS can land you in if you try something
as basic as renaming a file?  

I'm gathering not, and you should perhaps be grateful for your
ignorance.  It's not just that the operation isn't supported, it's
that the crocky workarounds recommended in the CVS manual are highly
likely to corrupt your repo.

CVS's key hackers abandoned it to start the Subversion project in 2000
because they had concluded CVS was unsalvageably bad.  I've studied
how CVS works internally for a survey paper on VCSes I'm doing, and --
believe me -- they were right to do so.

> o - They must support "batch mode" working, for RMS and others who
>   concentrate fiercely on a single activity at a time.

This problem doesn't have any technical solution.  What you appear to
be thinking of as "batch mode" (disappear into a cave for months at a
time) is not compatible with the communications practices we need to
move to in order to make the Emacs project agile and responsive again.
In particular, it's incompatible with engaging our users in real-time
via IRC and other messaging channels.

There's still a role for people with a "batch mode" working style, but 
it's more in the background working on large semi-detached projects.
Project leads have to face the world.

> o - They must, like Emacs, be fully usable on a text console without a
>   mouse as well as in X.  There are at least 3 hackers here who prefer
>   such a setup.

This *does* have a technical solution: lynx.  Or links.  Text-mode
browsers aren't what I'd call pleasant compared to graphical ones, but
they are usable.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>