Why Is Free MUD Development Lagging?
Thanks to Skotos for its editorial discussing why free, open-source MUD development is failing to advance swiftly. The author notes "The best [text-based MUD] efforts have been almost entirely closed-source... Free MUDs, by contrast, just haven't advanced very fast." He points to several possible factors, suggesting that "MUD information is indexed poorly, and many projects don't maintain a web site with even a basic description of what they're doing", and continues: "Another reason is licensing. The Diku license is poorly understood and shoddily enforced... LPMUDs aren't much better", before concluding: "There is no existing license that does for MUD servers what the GPL does for applications. That grudging spread of features has never happened for MUD servers the way it has for GPL-licensed applications and libraries."
I was really into the Battletech muse years ago, it had decent ANSI gfx, and was rather fun over a modem. I tried to find one in service for old times sake, all the links where dead.
But now, with all CPU/GPU power, there are good graphical type MOO's. Half the fun of MOO's where creating objects and chatting at the same time. There are a dozen opensource VR worlds on sourceforge, and some monthly subscription VR worlds that are rather fun.
Currently I'm playing Secondlife. It's quite a improvement. Of course, I still know people who play nethack and tradewars. So the classics do stay around.
The reason of course, is that the writers of these codebases tend to be college kids who do it as a hobby, and don't have the money to pursue legal action. The aforementioned Medievia is actually a huge racket, and according to some estimates they've made >$250K over the years by selling items to addicted players. See his link for more information, as well as this one.
Buy Steampunk Clothing Online!
I've had thoughts about this at one time or another. What happens if/when services for most people are done remotely. Thin clients, applications over internet, and so on? This may be the future of computing for most people, and the GPL doesn't cover it.
Where should I begin?
I recently resigned from my position in the management of a very large free-as-in-beer mud. I will not go into details or even mention the mud's name/genre or my alias. However, I would like to share some of my thoughts on MUDs. Please forgive the rambling style of this post, and please forgive me for posting as AC.
Mud developer coding style
In a mud there are typically no formal code reviews or automated regression tests. Testing is done by the players, and often even the most disciplined coder can be reduced to the mindset of "if it doesn't crash, it's not broken." This philosophy typically leads to ugly spaghetti code, and that's really not something most people want to show off or publish for public scrutiny. A lot of the coding done for a mud is in the form of one-time hacks. Personally I'm embarrased by some of the hacks I've made. :(
Open source and muds
Mud developers don't release their source code for various reasons including coder pride (see above), fears about the competition stealing features and a desire to keep the players from finding cheats/exploits by reading the source. Open source is primarily useful when the end user needs to be able to modify his/her personal copy of an application. However as other posters have mentioned, MUDs are run on the admin's server. Users only interact with the game via established web protocols, so asking a game to release its source code is actually like asking Google to show us its private OS and file system.
What is a mud?
From two steps sideways, the mud experience is really a lot like a shell account on a unix box. You connect via telnet/ssh and issue single-line commands to interact with the game. Moving from room to room is *a lot* like changing directories, and most of the other commands could actually be implemented with shell scripts. The more interactive features like combat and responsive NPCs would require a bit more glue, so you would probably have to modify the shell for those.
Taking two steps back, we see a user database with at least rudimentary access control, an extensible command parsing mechanism, a scripting language, a database for game content, a combat framework and means of processing user events. Note: Admins will likely want tools to modify the scripts and database content, a means of generating various game stats and some mechanisms for dealing with trouble users.
What parts of a mud should be private/unique?
For obvious reasons, the user database should be private. The content database also clearly belongs to the mud. This includes textual descriptions, vital statistics and special behaviors of all the objects, NPCs, rooms, custom quests and scripts.
So what does that leave for open source?
It excludes all of the content and leaves all of the framework -- the stuff that's generic enough for use in any MUD. If you're just looking for an open-source framework, check out Sourceforge. It looks like there are a few active mud projects there. I plan to post my framework there when it's done (don't hold your breath; I'm stalled at the point of only having a server, a command parser and a custom scripting language).
Some final thoughts
If you're looking for a complete open source game, you're probably confusing mudding with FPS or RTS games. Mud designers put in a lot of work to ensure consistency in the game. While we may be willing to give you a framework, you're on your own when it comes to the content.