[MUD-Dev] Re: DevMud RFC #1 - Was Re: DevMUD considerations and the Halloween article
jwilson at rochester.rr.com
Mon Nov 2 23:09:47 New Zealand Daylight Time 1998
On Mon, 02 Nov 1998, J C Lawrence wrote:
>Alan Cox has written a differently themed but equally useful and
>insightful analysis for a Slashdot article:
>Key points: We have a lot of blather and no code. We have no benign
>dictators (and I'm not volunteering). In summary we have much hot
>air, exercised keyboards, and no product.
I found this anonymous comment (a response to Cox) especially salient:
When a project is just germinating it sometimes doesn't
make sense to open the entire thing to discussion before
the core developer(s) has/have come up with basic ideas for
the project... Sure, the project should be announced to the
masses so that they can email people with their suggestions
and ideas, but perhaps mailing lists give people to much of a
sense of actually making a contribution when in fact all they
are doing is filling up other peoples mailboxes with spam. Once
the project is a little more established it makes sense to open
up a mailing list so that people can contribute bug fixes/submit
problem reports (sometimes not even then IMHO).
as Ola has pointed out (thanks for being so mean, Ola!) there are few
seminal concepts that we agree on beyond "modules" and "reusable". even
worse, and this is something I asked about a while ago and got entirely no
answer, there is no authority figure to set direction or maintain
>This needs to change.
Indeed. Are y'all detecting a challenge? ;)
I think the first question is, WHO IS THE DEVELOPMENT TEAM? This question
is especially proximate in that JC now has cvs set up, and someone has to
decide who gets access.
Therefore in the spirit of arrogance which makes me so wonderful, let me
PROPOSE the following.
DevMud RFC #1 (James Wilson)
1. it has been amply demonstrated that the babbling din on the
mud-dev mailing list is conducive only to going round in circles
2. the various oracles and auguries and scriptures of our avowed
Open Source faith assure us that all OS projects need, among other things
clear and realistic goals
a real live system to play with and improve
an expectation of utility
3. expecting a phase for formal design without iterative cycles is
unrealistic based on the deep insight of this reporter
Let it be Resolved that
1. those who have proposed various designs should put their shoulders
to the wheel, and come up with full proofs of concept. These should
be checked into discrete cvs directories in a central place for public view,
and should be accompanied by design documents explaining what principles, if
any, were driving forces.
2. each proof of concept should be announced on mud-dev upon its
inception, including a basic description of the general direction the proof
3. After this initial announcement, any collaborators should
correspond via channels outside of mud-dev until such time as they have
COMPLETED the proof of concept, at which time it is expected that they will
make an announcement and describe what, if anything, they have accomplished.
4. If any of the proofs of concept appear to have any merit whatsoever,
it will at this point be clear due based on quality of code and design who
the core development team is, and what directions seem fruitful.
since I've been bold enough to call it an RFC, please comment.
If this looks like it's no good, I'll be happy to shut up if someone has a
More information about the MUD-Dev