Traditional software engineering can be characterized by the idea that things can be planned and designed in advance and then implemented according to detailed specifications. Clearly, most MOOs are not built up this way. They are never finished. However, the questions of (1) what has to be there before users are invited to join and of (2) what can be done to insure and master growth and change have to be asked in an early stage. The danger in MOO mangement is that the MOO wizards and other important ``players'' view the MOO from their perspective. In fact, the complexity of the MOO is rather a result of all users perspectives (or more precisely of what they do (build, interact, etc.) in the MOO.
Central planning can be done in similar ways as it is done in large social bodies. Note however, that the phenomenology of a MOO world is rather open (topology, means of navigation and communication, etc.) Elements needed are:
This list clearly shows that planning is as much concerned with social issues (the MOO is a living thing) as with building and adding code. A larger quotation from Lucasfilm habitat corroborates this opinion:
``Again and again we found that activities based on often unconscious assumptions about player behavior had completely unexpected outcomes (when they were not simply outright failures). It was clear that we were not in control. The more people we involved in something, the less in control we were. We could influence things, we could set up interesting situations, we could provide opportunities for things to happen, but we could not dictate the outcome. Social engineering is, at best, an inexact science (or, as some wag once said, in the most carefully constructed experiment under the most carefully controlled conditions, the organism will do whatever it damn well pleases).Propelled by these experiences, we shifted into a style of operations in which we let the players themselves drive the direction of the design. This proved far more effective. Instead of trying to push the community in the direction we thought it should go, an exercise rather like herding mice, we tried to observe what people were doing and aid them in it. We became facilitators as much as we were designers and implementors. This often meant adding new features and new regions to the system at a frantic pace, but almost all of what we added was used and appreciated, since it was well matched to people's needs and desires. We, as the experts on how the system worked, could often suggest new activities for people to try or ways of doing things that people might not have thought of. In this way we were able to have considerable influence on the system's development in spite of the fact that we didn't really hold the steering wheel & more influence, in fact, than we had had when we were operating under the illusion that we controlled everything.
Indeed, the challenges posed by large systems are prompting some researchers to question the centralized, planning dominated attitude that we have criticized here, and to propose alternative approaches based on evolutionary and market principles [16-18]. These principles appear applicable to complex systems of all types, not merely those involving interacting human beings.'' ([Morningstar et Farmer, 1990, lines 613ff.,]).
In a more recent paper ([Farmer et al., 1994, lines 296ff.,]) the authors of habitat emphasize the need of planning for change again:
``Communities must be able to grow and transform. Many emerging electronic communities die for lack of the ability to adapt to change. Just as companies and small organizations go through serious growth pains and often disintegrate when they can't adapt, so too have early Cyberspace colonies. This type of adapt-or-die transfor- mation occurs eventually in every growing virtual com- munity we've experienced. A successful system will plan for it. Plan for growth. Plan for change. Sense of place is critical to the growth of community, as people adopt the emerging culture as part of their own.''
Anyhow, despite the fact that most of the planning should be rather spent on ``how to meet user's needs'' in accordance to the theme, a few things (both MOO objects and related rules) are essential in early stages, like: