[MUD-Dev] code base inquiry

cg at ami-cg.GraySage.Edmonton.AB.CA cg at ami-cg.GraySage.Edmonton.AB.CA
Wed Nov 17 08:06:40 New Zealand Daylight Time 1999

[Ben Greear:

> It was also interesting to see how the MUD-DEV project burned so bright,
> but flamed out so quickly.  Too many indians, not enough chiefs, no
> benevolent dictator, and I think the fact that so few of us really want
> to work for others when we could implement our own thing killed it.
> We as a mud-developer community just seem too set in our ways, busy,
> or otherwise introverted to be able to collaborate on a meaningfull
> project.  However, don't think I'm trying to preach:  I know I wouldn't
> want to work on any server but my own either :)

Hmm. A benevolent dictator might have helped. It would have had to have
been somone technically knowledgeable, but able to completely detach
themselves from their own opinions, and run with the perceived concensus.
And someone willing and able to put a fair amount of time into it.

I think one of the biggest problems was that too many of the participants
had their own opinions on how things should be done (based on their
experiences with their own systems or those they had worked with), and
those opinions differed in substantial ways. One of them was that of
polling versus non-polling for socket input. Also, I think it was a
mistake for me to dump my big blob of telnet code into the project. That
was too much, all at once, and it effectively forced the non-polling
mode onto things. I think there should never have been any dumping of
existing code into DevMud, without lots of prior discussion.

I enjoyed working with the folks, and would be happy to do it again. I'm
even ready to share out more of my code, but I'm not sure that would be
to the benefit of such a project, simply because it would have too much
influence if done too early. I think there needed to be a bunch of code
written specifically for DevMud (like the dynloading code), and the base
built from-scratch on that, until there was a significant amount. Then,
larger pieces could be contributed without bad side effects.

Oops. Gotta run!

Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list