February 1998
- OT: Following in the footsteps of JCL Alex Oren
- OT: Following in the footsteps of JCL Nathan Yospe
- OT: Following in the footsteps of JCL Richard Woolcock
- OT: Following in the footsteps of JCL Chris Gray
- OT: Following in the footsteps of JCL coder@ibm.net
- OT: Following in the footsteps of JCL Marc Eyrignoux
- Ada? Andrew C.M. McClintock
- Monthly FAQ posting Koster, Raph
- Monthly FAQ posting Adam Wiggins
- Monthly FAQ posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Chris Gray
- Monthly FAQ Posting Ling
- Monthly FAQ Posting J C Lawrence
- Monthly FAQ Posting J C Lawrence
- Monthly FAQ Posting Alex Oren
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting s001gmu@nova.wright.edu
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling Lo
- Monthly FAQ Posting Koster, Raph
- Monthly FAQ Posting Ling Lo
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting Marian Griffith
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting Ling Lo
- Databases Shawn Halpenny
- OT: This is a test coder@ibm.net
- OT: This is a test Alex Oren
- Clients and things [Was: OT: This is a test] Matt Chatterley
- Clients and things [Was: OT: This is a test] coder@ibm.net
- Clients and things [Was: OT: This is a test] Matt Chatterley
- MUD Development Digest Dr. Cat
- DBs and Events Greg Munt
- DBs and Events Nathan Yospe
- DBs and Events Greg Munt
- DBs and Events Nathan Yospe
- DBs and Events Felix A. Croes
- DBs and Events Jon A. Lambert
- DBs and Events coder@ibm.net
- DBs and Events s001gmu@nova.wright.edu
- DBs and Events Jon A. Lambert
- DBs and Events coder@ibm.net
- (subject missing) Ben Greear
- META: Unsubscribed users dur to bounces coder@ibm.net
- META: Unsubscribed users dur to bounces Adam Wiggins
- Source Code Release Greg Munt
- Source Code Release Ben Greear
- Source Code Release Greg Munt
- Source Code Release Ben Greear
- Source Code Release Greg Munt
- Source Code Release Richard Woolcock
- Source Code Release Ben Greear
- Source Code Release Chris Gray
- Source Code Release Greg Munt
This isn't a flame. Well, at least, I don't intend it to be one. There is
a lot of rambling, and probably more bad assumptions. This may or may not
be related to the ambiguity and 'fuzziness' of the subject matter.
On Wed, 11 Feb 1998, Richard Woolcock wrote:
> Greg Munt wrote:
>
> > I am wary of what will happen to my code - what it will be used to create
> > - once I have made it available to the general public.
>
> I'm also considering releasing some code, and have similar worries...
> The real difference is that there is already an (old) copy of my code
> which was stolen, and is floating around on the net. Even if I release
> my code, it was written when I was still learning C and some of it is
> very badly written.
>
> Could I really bring myself to drop such a mud on the mudding community?
> No...not normally - but at least it would be far better than the hacked-up
> mess floating around at the moment (which some people who have copies of
> are even selling, because I refuse to give out the code).
>
> At least if I did, it would be the first (to my knowledge) 'stock' leveless
> mud (merc2.1 based), which might at least bring a little variety to the
> stock scene.
Summary: you think that you should release crap code to the community,
because its 'less crap' than that which is currently circulating - and
does provide 'a little variety to the stock scene'.
Whilst this certainly does have its own merits, this also leads us into
evaluating muds based on their levels of constituent excrement. Perhaps we
should focus on reasons for releasing the code.
To "improve the community"? To "increase the quality of the average mud?"
To "develop the stagnating mud field"?
Define 'improvements'. Define 'quality'. Define your aims. By releasing
our code, are we trying to make things 'better'? (Define that too.) Or are
we simply trying to mix our crap with the crap that is already there, to
produce, not, as we might like to think, something 'better', or
'improved', or of more 'quality', but rather, something more akin to what
*we* want, what *we* look for in a mud, what *we* aspire to. Are we
looking to improve the community, or mould it into our own image?
Do we seek to advance, develop, improve - or do we seek to replace LP,
DIKU and Tiny with something of our own design? Is the dominance of a few
mud types good? If our mud replaced the big three, would we be
disappointed? Regretful? Egotistical and joyous?
From Keegan's JOMR paper, we know that unless a base becomes publicly
available (read: stock), it will wither, die and be forgotten. Do we
release code to prevent this happening? If so, why don't we want our code
to become forgotten?
Those scratch-authors among us, who deride the more popular uses of stock
code (*ahem*), now face a dilemma. The reasons that we write from scratch
are many. Not least is the unwillingness to adopt old, (what we consider
to be) bad designs. We seek to redress the balance by releasing our
scratch, 'better', 'improved' code. Assuming that our code (like the big
three) survives ten years, will be then look back in horror, in the
realisation that our work has become what we most despised about the
mudding field?
Let us now consider how stock code is used. Ignoring any possible hidden
agenda of egotism, we release our code. What do we want that code to be
used for? Arguably, we want it to make things 'better' - our own
definition of 'better'. What we consider the better attributes of a mud,
we would most certainly have put into our own. We are trying to propogate
our own ideas and wants to the community. Yet, when those, and only those,
very ideas and wants (i.e. the code that we release) are used, we deride
it, hate it, and sometimes (this is certainly true in Reese's case)
attempt to reverse the decision of releasing the code in the first place.
If we were pure egotists, we would want to see unmodified versions of our
code spread throughout the net. Wouldn't we? Perhaps, perhaps not. A
steady flow of uninspiring stock muds condemns the base to ridicule on
usenet (who claims that stock DIKU is a good piece of code?) - and
indirectly, condemns us to it, too.
So, we want our code to be used, certainly, but we want it to be the base
for improvements. Probably the most important question to ask, is: do the
people who download our code, share our goals, our vision of what the code
will be used for? In the vast majority of cases, the simple answer to this
question is a firm and definite NO. As has been remarked to me in email
recently (hi, Ling) as far as most people are concerned, there is no
'community', there is certainly no 'field'. They are 'in it for the fun
and not for life'. They have no interest in chasing things towards their
definition of 'better'. The simple fact is, they do not care. The big
three can dominate for the next ten years, too, it doesn't matter to them
in the slightest. Richard Bartle, the other half of Essex MUD, has stated
that he believes that there will be no 'field' until it becomes more
commercially-orientated - that free muds are themselves directly causing
the stagnation that I have become disgusted with, a disgust which I have
registered occassionally on usenet. That many of today's muds "are free,
and worth every penny." Today, anyone can run a mud. (Whether anyone
*should*, is a totally different matter.) A lot of the people who set up
these muds have been defined as 'clueless newbie morons'. But, without
them, would muds even exist?
We seem to have been conditioned into thinking that without
freely-available code, muds are doomed. In the free sector, this is
certainly the case. The free sector is doomed without free code, and
without the much-derided clueless morons to run them. The commercial
sector is (and possibly always was) in a better place to 'improve' the
so-called mudding field. Why? Because developers in the free sector have
no incentive to work at things, to improve, to create better shit. Those
who do work hard, to force improvements, are not really in the free sector
at all - they are in the commecial sector, simply with less (read: no)
resources.
This thread asks a question which has no real answer. It states what is
good, and what is bad, about releasing our code to the masses. But it does
not answer the question, "Am I adding any value, by releasing my code?"
--
Greg Munt, greg@uni-corn.demon.co.uk "I'm not bitter - just twisted."
http://www.uni-corn.demon.co.uk/ubiquity/ - Source Code Release coder@ibm.net
- Source Code Release Richard Woolcock
- Source Code Release Stephen Zepp
- Source Code Release Jon A. Lambert
- Source Code Release Greg Munt
- Source Code Release Jon A. Lambert
- Source Code Release Greg Munt
- Source Code Release Travis Casey
- Source Code Release Jon A. Lambert
- Source Code Release Jon A. Lambert
- [RESEARCH]MUD articles archive (fwd) Greg Munt
- Socket programming (Was: The impact of the web on muds) Jon Leonard
- Socket programming (was: The impact of the web on muds) Vadim Tkachenko
- Socket programming (was: The impact of the web on muds) Richard Woolcock
- byte-code anyone? Chris Gray
- byte-code anyone? Jon Leonard
- byte-code anyone? Chris Gray
- byte-code anyone? Jon Leonard
- byte-code anyone? Chris Gray
- user-centered design (was Clients) Mike Sellers
- OT: Linux g++ Greg Munt
- OT: Linux g++ Ben Greear
- OT: Linux g++ coder@ibm.net
- OT: Linux g++ Shawn Halpenny
- OT: Linux g++ Chris Gray
- OT: Clients Vadim Tkachenko
- OT: Clients Adam Wiggins
- OT: Clients coder@ibm.net
- META: OS wars coder@ibm.net
- META: OS wars Mike Sellers
- Clients Stephen Zepp
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) Adam Wiggins
- Moore's Law sucks (was: 3D graphics) Chris Gray
- Moore's Law sucks (was: 3D graphics) coder@ibm.net
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) Mike Sellers
- Moore's Law sucks (was: 3D graphics) Chris Gray
- Moore's Law sucks (was: 3D graphics) Ben Greear
- Moore's Law sucks (was: 3D graphics) Ling
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) coder@ibm.net
- Moore's Law sucks (was: 3D graphics) Alex Oren
- Version Control (was: DBs and Events) Vadim Tkachenko
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Vadim Tkachenko
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Jon A. Lambert
- Version Control (was: DBs and Events) s001gmu@nova.wright.edu
- Version Control (was: DBs and Events) Raph & Kristen Koster
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Felix A. Croes
- Net protocols for MUDing (was: Moore's Law sucks) Jon Leonard
- Net protocols for MUDing (was: Moore's Law sucks) coder@ibm.net
- Net protocols for MUDing (was: Moore's Law sucks) s001gmu@nova.wright.edu
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Caliban Tiresias Darklock
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Ben Greear
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) s001gmu@nova.wright.edu
- Net protocols for MUDing (was: Moore's Law sucks) Jon A. Lambert
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- VEIL (was: Clients) Brandon Gillespie
- LDMs (large dynamic maps) was Unique items Mike Sellers
- Describing the environment Stephen Zepp
- Describing the environment Richard Woolcock
- Back on the list Niklas Elmqvist
- Back on the list Chris Gray
- Back on the list coder@ibm.net
- Unique items The Eternal City
- Unique items coder@ibm.net
- Position sorting Adam Wiggins
- Position sorting coder@ibm.net
- Unique items coder@ibm.net
- Unique items Nathan F Yospe
- BOOK: Myer's Silverlock coder@ibm.net
- BOOK: Myer's Silverlock Chris Gray
- BOOK: Myer's Silverlock Adam Wiggins
- Dynamic Loading of Modules (was: Back on the list) Niklas Elmqvist
- Dynamic Loading of Modules (was: Back on the list) Vadim Tkachenko
- Dynamic Loading of Modules (was: Back on the list) J C Lawrence
- Dynamic Loading of Modules (was: Back on the list Jon A. Lambert
- Net protocols for MUDing s001gmu@nova.wright.edu
- Net protocols for MUDing Stephen Zepp
- Net protocols for MUDing Chris Gray
- Net protocols for MUDing Adam Wiggins
- Net protocols for MUDing J C Lawrence
- Net protocols for MUDing Shawn Halpenny
- Net protocols for MUDing J C Lawrence
- Net protocols for MUDing Chris Gray
- Dynamic Loading of Modules Niklas Elmqvist
- Senses (was: The MLI Project) s001gmu@nova.wright.edu
- bar-time (was The MLI Project) Mike Sellers
- 3D engines for MUDs (was: The MLI Project) Niklas Elmqvist
- 3D engines for MUDs (was: The MLI Project) J C Lawrence
- 3D engines for MUDs (was: The MLI Project) Michael Hohensee
- 3D engines for MUDs (was: The MLI Project) Miroslav Silovic
- 3D engines for MUDs (was: The MLI Project) Michael Hohensee
- Why not compile java into object code? Ben Greear
- Why not compile java into object code? Cynbe ru Taren
- Why not compile java into object code? Caliban Tiresias Darklock
- Why not compile java into object code? Nathan F Yospe
- Why not compile java into object code? Niklas Elmqvist
- Why not compile java into object code? Ben Greear
- Why not compile java into object code? Jon A. Lambert
- Why not compile java into object code? Travis Casey
- Why not compile java into object code? Chris Gray
- Tutorial: Comments on Hand-crafting a compiler Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part I: Introduction Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part II: Expression Parsing Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part I: Introductio Chris Gray
- Tutorial: Let's build a Compiler! - Part I: Introductio s001gmu@nova.wright.edu
- Tutorial: Let's build a Compiler! - Part I: Introductio coder@ibm.net
- MUD Development Digest Dr. Cat
- MUD Development Digest Koster, Raph
- MUD Development Digest Mike Sellers
- Tutorial: Let's build a Compiler! - Part III: More Expressions Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part IV: Interpreters Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part V: Control Constructs Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VI: Boolean Expressions Jon A. Lambert
- Tutorial: Let's build a Compiler! - Comments Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VII: Lexical Scanning Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VIII: A Little Philosophy Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part IX: A Top View Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part X: Introducing TINY Jon A. Lambert
- Compilers: Toy available for ftp Chris Gray