Phantasmal Site > DGD > Writing a Library > Releasing Code

Should You Release the Source to Your MUD Library?

This has been a hotly-debated topic for quite a long time throughout the MUD community. Obviously, at some level it's a matter of choice. But there has been a lot of good debate on the subject, and it's worth summarizing it to help avoid some of the repetition that usually dominates mailing-list discussion on the topic.

Reasons that Releasing is a Good Idea:

• You get to contribute to something much greater than just your own MUD
• DGD is severely lacking in functional, usable, and game-oriented mudlibs
• You could potentially benefit from those people that add new functionality to your source.
• Much bigger pool of users to draw from as far as tracking bugs and playtesting

Reasons that Releasing is a Bad Idea:

• Harder to find time for your own MUD due to MUDLib users asking for their own maintenance and changes
• You may lose all functional uniqueness due to numerous clones of your MUD
• Open to subjective public criticism on design paradigms (not really a problem, just an annoyance)

The 'Stock MUD' Argument

If you release a reasonably runnable MUD that people use, you'll find that the areas you supply are used as stock areas. It's not really avoidable. Is that a good or a bad thing?

If you distributed a library with no predefined 'areas' then you could largely avoid this. But is it bad to be recognizable in terms of the feel of the library? For players it's a good thing, since familiar means comfortable as a rule. However, it's not clear that beginner 'stock' areas are as valuable as say, a known, common set of commands.

Dworkin's suggestion is to release only part of your mudlib. Include the base classes, but not the actual rooms and objects. That way you won't have to fear the 100 identical clones. Just include a few example rooms with a few example monsters (adjust to whatever your mudlib actually contains). This suggestion can be annoying to initially set up since you'll need a release process that strips out the appropriate files. However, once you have it in place, it avoids other people cloning your MUD unless they can rewrite a *lot* of game-specific code.

"I'll Release When It Works" Syndrome

I know of more DGD MUD Libraries that have abandoned development, never released, than have ever been released in total for DGD. Of those libraries, all but two or three were going to release code as soon as it worked correctly. When they had a release that satisfied them, they were going to make sure everybody could use it. Not one of them ever released a line of code. Their good ideas, their starting MUD code, every line of text and code is gone.

John McKenna 'released' his "Inferno" MUD Library when I found it on an FTP server, almost by accident, and asked if I could link to it. He didn't send out links publicly, to my knowledge. He certainly didn't intend it to be broadly used. But by agreeing to let me link to it, he contributed more to the current DGD community than every one of the MUDLib efforts that were abandoned unreleased. More than all of them put together. And all he ever contributed was an example MUDLib, and not one that very many people look at.

If you're writing a MUD Library and you're planning to release code, please, please don't wait until it works. If you do, chances are very good that we'll never see a line of your code, ever. You might just contribute one decent subsystem of your MUD (Phantasmal's HelpD and I/O have both been used in other MUDs long before Phantasmal was playable). But even if that's all anybody ever sees, you've still contributed something. Are you really that dedicated to making sure all of your effort is lost forever?

Maintenance and Technical Support

Some people worry that if they release their MUD Library code, they'll have to provide technical support to all the people who want to use it. This is a valid concern. However, you'll find that you can always tell them to bugger off, particularly if you've written decent documentation. However, the success of your MUD Library in the world at large will absolutely depend on your willingness to provide support to developers who try to use it.

Dworkin says: use a DGD-like policy with regard to changes: make clear that you will be very happy with bugfixes, but will only include those "enhancements" that you yourself like.

Commentary From People Who Have Released

George Reese, author of the NightMare MUDLib (LPMUD, but not for DGD), has this to say:

Some text on this page is kidnapped, verbatim, from email by Dan Root. Other text is kidnapped from other people, but they're credited individually above.