OpenSim Needs an Installer

As I have discussed, Second Life has played the role of Prodigy in promoting virtual worlds to larger populations. Now with the growth of OpenSim, it is possible for anyone with a web server to host a virtual world, similar to the availability of low cost of web page hosting in the past. What was needed to reduce the cost of website hosting were scripted installers that allowed complete and secure web servers to be installed with a single click.

What is now needed is a standard of OpenSim packaging, management, and inter-grid connection that will allow individuals to install and run their own hypergrid connected sites even on shared web servers. This package management could be modeled after the refinement and ease of use found in the installation of other open source software, such as WordPress or Drupal. Many of the necessary pieces have already been written and just need to be scripted to install together. The final product will be a single package that can be installed by QuickInstall, or Fantastico De Luxe, the standard installers supplied by many ISPs. With this advancement, current web developers can then extend their services to include the personalization and customization of virtual worlds. For individuals and companies with websites, having their own virtual world can simply be an extension of their existing web presence.

Here are list of components that I feel will need to be bundled or written to make virtual worlds as universally accessible as web pages currently are.

  1. Currently OpenSim is written to run on Windows-based hosting. There is an existing component that has to be installed on a Linux-based server to allow OpenSim to run. This component is called Mono. In the short term, Mono needs to be part of a packaged installer. In the longer term, OpenSim needs to be rewritten to run natively on Linux-based servers without this emulation layer. This will be essential for the wider distribution of OpenSim and will reduce the memory and processor requirements needed to run in both private and public computing clouds.
  2. When installed, each virtual world should be provided with a stock virtual environment, including a virtual conference space, a virtual social space, and a virtual storefront. A virtual world owner can delete the areas that they don’t need and duplicate the stock buildings as needed. For most virtual world users, it is almost valueless to arrive to a completely barren space. Most websites today are built using templates, and so should virtual worlds.
  3. Every virtual world needs to come with a library of stock open source buildings, furniture, vehicles, avatars, clothing, and textures. Further, there needs to be a common repository for standard OpenSim objects. One limitation to new virtual world development is the requirement that every new world needs to create all of their standard objects for themselves.
  4. A standard inventory backup and restore tool needs to be included with every virtual world install. Users need to download their inventories to their personal computers for backup. As importantly, users need to be able to download virtual inventory from a variety of websites and upload them as needed to their virtual worlds. Limiting control of inventory only to in-world is part of the non-distributed virtual world model of Second Life.
  5. Virtual world owners need to have an easy to use virtual world control panel. This control panel will simplify the management of virtual grids for those who do not have the time or skill to manually edit the databases underlying their virtual world. The best control panel that I have seen has been distributed by PioneerX. To promote the growth of virtual worlds, there will need to be a free version of this control panel for virtual worlds that do not need to collect in-world rent.
  6. There needs to be a standard web browser-based viewer for virtual worlds. As I have discussed, Second Life has already beta tested one such browser-based viewer, which has worked well, and there are other companies that have working solutions. To make virtual worlds commonplace, it is essential that they become part of the standard web browser interface, not relegated to their own software installations like computer games. If a browser plug-in is required for virtual world viewing, this should be uploaded when the OpenSim world is installed.
  7. The standard package installer needs to provide voice communication. There are currently several licensed OpenSim voice installations, but there also need to be free versions available that are part of a fully Open Source install. If entirely open source versions of voice software are not available, there will need to be ground-up rewrites of OpenSim that include voice. The function of virtual world voice should be proximity based as it now functions in Second Life.
  8. OpenSim installations need to be provided with a stock website front end. For virtual worlds to be an extension of a user’s standard web browsing experience, the barriers between in-world and out-of-world communication need to be brought down. The best solution would be a plug-in integration with an existing and well-established Open Source Content Management System (CMS) like WordPress or Drupal. These plug-ins could include functions like avatar creation and the ability to see who is in-world from the website front-end. This front-end could also handle inventory backup and functions.
  9. Every grid needs to have hypergrid transport. Like every web page can hyperlink to every other page on the Internet, every virtual world needs to be able to link to every other grid. Like at the beginning of the Internet, currently there are quibbles about proprietary virtual content. As with websites, this content needs to password protected and the remainder of virtual world content needs to be freely available. Like with web sites, there needs to be a virtual world search engine that allows users to find the content that they are looking for. Ideally, a Google for virtual worlds could integrate with the enormous virtual world of Google Earth.
  10. As I have talked about elsewhere, user inventory needs to reside on individual user servers and not be associated with the individual grid. From a technical standpoint, this would mean that inventory would not be referenced from local SQL databases, but would be drawn from inventories stored on remote servers. This would also solve virtual world inventory licensing problems. All objects would be property of and served by the avatar owner, and would not be the responsibility of the specific grid. Owners of the grids would not be responsible for any inventory not on their server, allowing universal hypergrid transport without risk of copyright infringement.
  11. There needs to be a universal handling of currency. This is essential for all in-world transactions. Rather than creating universal currency specifically for OpenSim, virtual world transactions should use existing shopping carts, like PayPal and Google Checkout. This already existing infrastructure allows shoppers to visit various e-commerce web sites, collect items in their cart, and pay in one centralized location. This would avoid the issues of virtual world currency exchange and any transaction disputes could be handled using existing resolution mechanisms.
  12. Finally, with the completely open source rewrite of OpenSim, there should be a restructuring of the underlying databases so that the computational resources for the virtual world can be cloud-based. Using a cloud-based computing environment, OpenSim installs could use little resources when not in use and then have near infinite resources when needed. OpenSim needs to be restructured to function better on distributed systems and there needs to be standard controls incorporated in virtual worlds to link directly to commercial computational clouds.

I offer this laundry list to the OpenSim and Open Source community as the possible directions that virtual worlds can go.

Next Post