[MUD-Dev] Re: Why did it take years?

Erik Ostrom eostrom at acm.org
Wed Oct 28 06:26:22 CET 1998


On Mon, 26 Oct 1998 20:29:01 -0800, Bruce Mitchener wrote:

[Why did it take years?]

>Well, a good server and the associated things like documentation, code
>running on top of it to make it useful and so on do take time.  A lot of
>time.  Many (most?) of us here probably aren't working on these systems =
in
>any type of full-time manner.  It is also somewhat hard to come by
>volunteers who are both willing and capable of assisting with =
complicated
>coding projects.  Cynbe has already said that he is pretty much the only
>person working on Muq.  How many people work on the MOO server?

This looks like a rhetorical question, but on the off chance that
anyone is interested, a quick and partial overview (not entirely in
chronological order):

Stephen White wrote the original MOO server.
Pavel Curtis developed it for many years.
I've been maintaining it for a couple of years now.
Ben Jackson and Jay Carlson wrote an extensive and widely used setof
performance enhancements, which have been integrated into the
"mainstream" server (although that integration has not been
distributed yet).
Chris Unkel wrote a Windows port, which is being integrated into the
mainstream server.
Steve Caron and Nick Ingolia wrote a Macintosh port, which I hope
someday will be integrated into the mainstream server.

And numerous people have written additional sections of the code--for
example, H. Peter Anvin added floating point support that Pavel
incorporated into the mainstream server; Ken Fox has worked with me on
support for adding new data types to the server's embedded language;
and Pavel had one or more student interns write server code for him at
PARC.

So, in short, quite a few people have actually worked on the MOO
server.  However, it hasn't exactly been a collaborative endeavor.

=46or the most part, when other people's code has ended up in the server
it has not been as a result of the author and the server maintainer
agreeing that something needs to be done, working out a design, and
doing it.  Rather, to take the example of Ben and Jay's performance
enhancements, they simply did the work because they felt it needed
doing.  (That's my impression; Jay can correct me if he chooses.)

Jay and Ben told me they were speeding up the server, and I said okay,
but we didn't talk about it much.  Much later, when I had more time
and their own work seemed to have stablized a bit, I chose to pull
their code into my own source tree.  But other people have written
server extensions that for one reason or another will never be
mainstream.

Likewise, I like to imagine the Mac and Windows ports were undertaken
in part out of desperation, when Pavel showed no indications that he
would ever attempt mainstream ports to those platforms.  Now the
Windows port is being integrated because it's a necessity for me.  But
the Mac port will have to wait until it bubbles up on my priority
list, or someone else takes over.

It's also worth noting that, although Ben and Jay maintain a CVS
repository and I maintain a CVS repository, all merging of our two
source trees has been done by hand, by me; I've kept a tight grip on
control of the source, as did Pavel when he was maintaining the
server.

All this is a far cry from the design discussions and modular
architecture and shared code repository being discussed on this list.
=46or better or worse.

In addition to the issue of cooperation, there is, let's say,
simultaneity.  No one has worked on the server continuously since its
creation.  And no one has put in full-time work on it (with the
possible and occasional exception of Pavel and/or his interns).  It's
taken years in part because the work has been spread very thin, with
sporadic bursts of intense activity.

I have no point to make here.  It may be interesting to someone that
MOO's development history is somewhere between the one-man crusade of,
say, Muq (as I understand it), and the proposed team effort of DevMUD.
But then, it may not.

--Erik, rambling





More information about the mud-dev-archive mailing list