[DGD] Re: RE: Pros/Cons of Releasing Mudlibs

[Jason Cone]

::NOTE::

I had originally tried to post this, but it failed due to my using a
different email address (my work one).  I registered it and am assuming this
one will work, but should an identical post come through later on, that
would be why. :)

-----Original Message-----
From: George Reese <borg at imaginary.com>
To: Jason Cone <jcone at cs.tamu.edu>; dgd at list.imaginary.com
<dgd at list.imaginary.com>
Date: Wednesday, May 20, 1998 4:30 PM
Subject: [DGD] RE: Pros/Cons of Releasing Mudlibs


["Pro" comments]
>>
>> Cons to Releasing
>> =================
>> * Attention is focused to the development of the lib rather than the
>> development of the MUD.
>
>This is actually a plus, IMHO.  But it assumes you have separated the
duties
>of running the mud into taking care of the lib and those who take care of
>the game.  Specifically, it allows you to view features people are asking
>for *on the mud* in a more generic context and thus allows you to come up
>with more flexible solutions.

Yeah, this is something I realized after posting the original thoughts. This
concern is negated for the most part by a well designed responsibility
heirarchy on the MUD and a group of commited people.  Being that there's
only 3 of us working on it right now, it's hard for me to visualize having
the kind of man-power to be able to delegate development in the way that you
suggest. :)  I foresee that changing once we are totally open, though.
Actually, it's probably best to say, "I'd <like> to see that change..."  ;)

>> * You lose all functional uniqueness (potentially numerous clones of your
>> MUD).
>
>This is a HUGE problem... especially a year or two down the road.  More
>specifically, every mud has the problem of player X disagrees with the
>admins and declares he or she will start their own mud.
>
>Guess what.  If your mudlib is being publically distributed, not only can
>they start their own mud, but they can start one JUST LIKE yours.  And then
>they can come back to your mud and say "we have started a mud just like
>CornerStone, except it is run by players who remember what it is like to be
>a player" (as if you somehow don't have a clue).

Yet another good point.  I'm tiring at having my mind constantly change on
this matter.  As one who's dealt with this a lot more than most, if not all,
of us, would you agree with an earlier point that was raised that claims
that the "physical" area defines the MUD rather than the underlying lib
code?  If not, why?

>And don;t forget having to provide tech support for people using the lib!

As one who does software development to pay the bills and put food on the
table, providing tech support is something I hate with a passion.  I fully
conceed that it's a necessary evil as there are those that still think that
mice are absolute input devices (ie., pointing it at the screen should move
the pointer). :) It's still something that I shy away from doing.  That
said, I'd go nuts if that were to become (one of) my primary duty(ies).

Of late, I've become more concerned with getting to the point of being able
to distribute rather than whether to distribute or not. :)  Semester breaks,
moving, etc. are always couter-productive and there's not a huge group of
active developers to depend on picking up the extra slack (which is
preferable in our case, I believe).  Anyway, expect this topic to come up
again in the (hopefully) soon future.

--
  Jason Cone
  Software Developer
  Usability Sciences Corporation
  jcone at usabilitysciences.com






List config page:  http://list.imaginary.com/mailman/listinfo/dgd