[MUD-Dev] Re: openmud or pdmud or devmud

[Darrin Hyrup]

At 08:38 AM 10/25/98 -0500, James Wilson wrote:
>
>seems like the first thing people need to agree on is what name to use. ;) I
>like OpenMud myself. PDMud sounds like there'll be a lot of sex there. DevMud
>is kind of stodgy. There's always the Python option, i.e. go with something 
>that just sounds good.

Hehe.  I though dev-mud was going to be the name of the new mailing list?
As for the project name, I still like OpenMUD since that's what this really
is... An Open Source MUD project.  (If it ever gets out of the conceptual
phase anyway.) :-)  But, I don't think the name is that big of a deal,
since we all know what we're talking about.

>but maybe before that, it should be determined who is involved and what the
>roles are. There's been a lot of design thrash lately, which can be good, 
>but I recall numerous similar threads (not on this list) where people had
lots
>of grand ideas but no code ever got written. The Perfect is the enemy of the
>Good, cf. the Hurd project. Anyways, I guess there are two things that I
think
>need to get resolved.

I've tried to get folks to volunteer to head up parts of the design team in
an effort to see who is interested and feels they are up to the challenge.

>1. Who's in charge? Is it 'the consensus of mud-dev at kanga.nu'? Is it 'Bibi
and
>Bill and Yasser, but definitely NOT Muammar'? Is it 'Linus Torvalds
alone'? I'd
>like to believe that something good would happen without such a fascist
>structure, but I'm a little bit cynical. Someone (maybe multiple someones)
need
>to decide on big things like What License To Use, and have their decisions
>accepted. (I would imagine that different modules could be distributed under
>different licenses. However, the core should probably be licensed as a unit.)

In my experience as a game developer over the last dozen years or so, I've
found that no matter what, you need to have a clear structure for the
decision making process, or things will never get done.

A tree structure is typically being the most common (and best) way to set
up a project.  Each group has a leader, those leaders have (optionally)
other groups they belong to, and so on, until the top of the tree (the
project leader) is reached.  That way, when a decision needs to be made,
each group can make their own decisions when within their local scope, or
pass it up the line.  In such a system, everyone has a say in what goes on
within their own scope of the project, but decisions always get made.

>2. Who's going to do what? When? A number of fundamental design issues
need to
>be resolved fairly quickly if any further work is to be done. It's fun to
argue 
>about grand design schemes, but at the end of the day one has to make some
>difficult choices and stick with them. Whatever design is arrived at needs
to be
>documented thoroughly so people know how to proceed. I don't want to be the
>cause of needless bureaucracy, but we need to formalize things so everybody
>understands one another.

Having a clear line of decision-making is definately necessary, but so is
having a solid idea of who is dedicated to working on the project, and what
their talents are, so the design groups can be branched in a logical
manner.  Plus until we know what we have, we don't know where we need help.

>I'm itching to implement something (as are, I think, many others who have
>leapt up and shouted 'YES!'). I don't want it to fall apart in a month or
two,
>though, which is why I'm being so fussy and corporate.

I agree.  I'm really excited about seeing this get off the ground too.

Best,

Darrin