[MUD-Dev] Re: Commercial-use Restrictions on Code Bases (was: help me find 100% fre (fwd)

[J C Lawrence]

------- Forwarded Message
From: mk270 at cam.ac.uk (Martin Keegan)
Newsgroups: rec.games.mud.admin
Subject: Re: Commercial-use Restrictions on Code Bases (was: help me find 100% free  graphical mud)
Date: 2 Dec 1999 23:56:35 GMT

In article <383EC091.F94E9912 at spam.free.gamecommandos.com>, Ilya wrote:

>>I think that a mud will take care of itself.  If a mud is
>>run correctly, there will be people that play there.  If the
>>mud is a piece of crap, people might visit, but won't stay
>>long.
>
>True enough.  But I'm not worried about the player base or

Just for the record I must dispute the "but won't stay there long"
line and its blind acceptance, but that's not why I'm posting.

>Too many of our most creative and productive minds in the
>mudding world are finally forced by economic concerns to
>abandon it in search of activities which can provide at
>least a minimal reward.  If more code bases were out there
>and were promoted which allowed for commercial use, then

Now the Linux "counterexample" raised against you actually comes back
to help; since the Linux kernel, OS and operating environment are all
largely under free licences, it is possible, paradoxicly, for the
system to be exploited commercially. I'm sure we couldn't do this
with Minix.

So too mud server codebases. Geneticly we have various groupings of
server codebases which are related to one another by derivation or 
inspiration. More important, however, is the typological distinction
along a sort of hack'n'slash <-----> RPG <-----> MOO <-----> talker
continuum. What we find is that there are almost two separate communities,
the Diku/AberMUD crowd of D&D-style games (and I stress the word "games"),
and most of the other types of mud on the other side of the divide.
The Diku mob doesn't know or care about the existence of MOO/MUSH/LP, etc,
and the MOO/MUSH mob look down scornfully on the Diku people (to whom
they should be grateful for attracting losers and troublemakers away
from their own systems).

None of these communities (however you count them) is significantly
communally aware of the issues familiar to the Free Software/Open Source
movement, and it shows. One interesting cultural artefact demonstrating
this is the way mud adverts will use the word 'code' as a count-noun
"We use a SMAUG code" (which to an OpenSourcer is not a valid sentence,
"We use SMAUG code" being the only option), implying that there is little
communication between these groups. If there were greater overlap, there'd
be more opposition to the use of non-free mud servers, not only for the
ideological bigotry satisfaction reasons of the Free Software juggernaut,
but also because these people would be able to put forward strong practical
arguments against things like the Diku licence.

Elsewhere in this thread which I have been watching with interest, Matt
Chatterly identified three different types of reason someone might start
a not-so-new mud: coolness / powertrip, etc ; breakaway / disaffection ;
actual desire for originality. He said that the first two of these three
ought to be taken out and shot. A while ago I should certainly have agreed.
However, I have recently read a post [*] by Travis Casey on the MUD-Dev
mailing list in which it was argued that most of these StockMUDs about
there should be considered analogous to people running their own RPGs
on pencil and paper and someone wanting to be DM. Should the DM have to
invent his/her OWN regular polygon to get original dice? Of course not.

The analysis of the StockMUD phenomenon has fallen victim to a category
error. When I was compiling The Mud Tree, I counted as a single mud
variety all muds which derived from the same source (e.g., Diku, Circle,
SMAUG, MOO, Dirt, Mordor), but, not having the benefit of the insights
of Mr Casey or of Eric Raymond's Cathedral and Bazaar essay (which I
largely disagree with, but which would have proven useful), failed
to see that a lot of these people just wanted to run their own game,
rather than create their own unique virtual world (partially because of
the assumed orthodoxy (namely that all mud administrators should want to
be mud creators and innovators)).

The first and second groups (the harmless DM wannabes and the splitters)
ought to be considered separately from the innovators, even though they
are doing roughly the same thing in the same environment. The conditions
of this environment are that players don't communicate with a significant
proportion of the mudding community and there is a strongly defined notion
of acceptable variation. Players will tolerate changes in races, classes,
etc, but will strongly reject muds which have a different set of basic
commands or fundamentally different combat system. The "norming" effect
whereby GPLed code in free software projects ensures that forks and splits
don't occur too damagingly by all the useful changes being merged into
a central tree has its counterpart in the mudding world: popular innovations
within the permitted scope will propagate from mud to mud slowly through
the word of mouth transmission mechanism of a fragmented community. There's
certainly no central Diku clearing house for ideas, but there might as
well be.

So, why do all three groups choose the same old code? The first two groups
obviously want to attract players, and familiarity sells mud time. The
third group may (separately from the familiarity to the players issue)
also select a familiar codebase because it will be easier to modify to their
tastes, or because there is a particular set of desired features offered
by the codebase. I submit that the most desired feature is mud socket code:
it's the thing which constitutes a real barrier to entry for aspiring mud
designers. The easy way out is to use someone else's code ...

What this has led to is using not only stock socket code but a whole stock
mud, probably due to the difficulty of separating the two. For the want of
some socket code, the game mechanics and interface of an entire mud are
copied.

I think it would be quite beneficial (irrespective of the accuracy or
otherwise of my ever-haughty and possibly self-serving analysis) to have
a framework of LGPLed components (socket code, parser, game mechanics,
"database" (Ok, so the middle two are interdependent)) making up a mud
system, allowing coders to take only the bits they want, forcing them
only to conform to a particular set of interfaces between these components,
rather than forcing them to accept all the components just to get the
single one they want. By no coincidence whatsoever I have been writing
a component of just such a system ... :) and shall probably be releasing
it (the networking code) this weekend.

>perhaps we would have saved more of these creative/productive
>minds for the hobby/art and this would have been a good thing.

Perhaps as the maintainer of such a high profile site as gamecommandos
you are in a good position to promote things like this ...

Mk

[*] http://www.kanga.nu/archives/MUD-Dev-L/1999Q4/msg00467.html
------- End of Forwarded Message

--
J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev