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

[Jon Leonard]

On Sun, Oct 25, 1998 at 08:38:02AM -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.

I like OpenMud too, except that it has already been used.  I recommend
"DevMUD" for a few reasons:

1) It doesn't seem to be used yet.
2) It fits the project:  Dev -> Easy to develop on/for, MUD -> It's a MUD.
3) Tribute to MUD-Dev, from which it originates.

> 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 think it's too early to really resolve much of this stuff, but it should
get resolved eventually.  There's a lot to think about before we commit to
any decisions, and we may still be missing critical input from someone who
just happend to be busy this week.

I'd consider no decisions final for at least another week, and no code
final for _at least_ a month.  One of the essential lessons from
"The Mythical Man-Month" (which I think should be required reading for
anyone working on a large software project) is that concentrating too
much (or too quickly) on implementation is a recipie for disaster.
It's only about a sixth of a project when you factor in design,
debugging, documentation, etc.

> 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.)

How about a somewhat anarchistic structure?

Since much of the point of DevMUD is to have a codebase that developers can
freely use, extend the freedom to include being alternate code repositories
and development centers.

I'll contribute to this by providing a code repository on mud.slimy.com
and doing my development there.

My tentative policies:

* Code is usually available on "Steal This Code" terms.  The authors take
  no legal responsibility for use/abuse, and anyone can take it to do
  cool stuff with it.  Code with different terms (credit-me, GPL, etc.)
  will be clearly labeled on a per module basis.

* If someone else has a repository, I'll provide a link to it.  Where
  appropriate, I'll try to help keep other repositories up to date.

* For most DevMUD related code, I'll mirror it on my machine.  I may
  also provide versions of modules modified to my taste alongside the
  originals.  I'll occasionally decline to mirror something, either
  because I can't legally do so (being in the US, there is some crypto
  code I can't make available, for example), or possibly because I just
  don't want to.  I'll usually provide links in such cases.

* Others who want to make mud.slimy.com the primary home of a module
  they develop on are (usually) welcome to do so.  Shell accounts are
  available for this purpose.

If someone else provides a better code repository, then I'm effectively just
being a mirror, which is fine.

If no one else provides a similar repository, then I'm de-facto the project
coordinator.

Comments?

> 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.

I don't think there's a big hurry.  Any code done now should be considered
a prototype anyway.  To quote "The Mythical Man-Month", "Plan to throw
one away."  That said, I think it is very important to document what we're
doing and why.

> 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.

Depending on what "fall apart" means, I think it won't.  Even if everyone
else loses interest, I'm still going to implement at least a simple set of
modules to demonstrate mix-and-match MUD components, and provide example
code for someone starting a MUD from scratch.

Jon Leonard