What Is "Stable"

NOTE: THIS PROPOSAL IS A WORK IN PROGRESS

One of the foundation objectives is to create a “stable” OpenSim distribution. To understand the objective, we must define “stable”. At a high level, a stable OpenSim distribution is one that meets a set of functionality, performance and robustness requirements. That is, the focus on a stable distribution is a focus on building useful applications on top of the distribution.

Some observations about stability.

• Stability requirements are determined by the set of applications that will be built on the platform. For the foundation these applications focus on education, science, and visualization.

• Stability requirements are not static. Over time the set of applications will change. At first, the platform might target acceptable performance for 50 interacting avatars. In later releases, the target may be raised to 100.

• Functionality, performance and robustness are often at odds with one another. Additional functionality increases complexity leading to decreased robustness. Clearly there is some minimal level of functionality required. However, the cost to deliver some level of stability bounds functionality, performance and robustness targets.

• The platform doesn't have to “do everything”. It needs to “do enough” to meet the requirements imposed by the target applications. This is a case where “perfect is the enemy of good enough” applies.

• Predictable platform behavior is important. Surprises in behavior of the platform are the most difficult to accommodate. Well-known (and documented) defects can be worked around either by correctly scoping the kinds of applications that can be run on the platform or finding ways to avoid the defect.

• Roadmaps are important. An application developer needs to plan for platform changes well in advance. Obviously changes in the platform behavior or API must be recoded. In addition, application behavior must be tested against the new platform as soon as possible.

• External API's matter a lot. This is what the applications are built on. Changes in the external API's will break applications and will cost you customers. API's must be documented and must not change without notice.

The roadmap is simply a document that captures a set of functionality, performance and robustness requirements based on target usages, and associates a date with their expected delivery. Each requirement is assigned a priority (e.g. mandatory, recommended, optional). Only work on recommended requirements when all mandatory requirements have been met.

Note that the roadmap can reasonably be composed of features that have already been implemented and demonstrated in experimental archives. The roadmap then consists of the set of features that will be rolled into a release and tested as a complete package.

Every requirement must come with a description of a test (or tests) that verify that it is met. Create test cases to capture the requirements. A requirement is not met until it passes the appropriate tests. Every release should come with information about the tests it passed and the tests it failed. Developers should never write the tests (at least not for their own code).

Decide what API's are internal and what API's are external. Document external (“user” visible) API's religiously. And do not change them unless there is a very good reason and notice has been given far in advance.

NOTE: this section is in a “brain dump” state…

Primary requirement for the first release would be ease of installation and management of region server and grid services.

• Tools
  • Installation and configuration tools
  • Region management tools
  • Automated software update service

• Testing
  • Build automated test cases for basic functionality; could re-purpose Intel's automated workloads for testing
  • Deploy test infrastructure, possibly three environments: production, weekly testing and feature testing)
  • Automated build infrastructure for daily/weekly builds

• Documentation
  • API's; must identify which API's we expect to be public and stable, probably includes region module API
  • Installation guide and configuration examples