The Tao of OpenSim April 11, 2009Posted by justincc in opensim, opensim-dev, opinion, virtual-environments, virtual-worlds.
In today’s long and rambling post I want to address two topics which have come up for me recently. The first is the assumption that OpenSim is just trying to be a cheaper Second Life. The second is the idea that OpenSim development is something that will inevitably be provided by other people and companies. I think that both of these are wrong, and here’s why 🙂
OpenSim doesn’t aim to be a Second Life clone
From the outside, I think that it’s easy to get the impression that we’re trying to produce a Second Life clone. We implement the LSL language and many of its functions, we provide an environment which is used with Second Life clients, we provide a ‘grid’ architecture with many regions relying a set of centralized services (asset, inventory, etc.).
But the real aim of OpenSim is to go beyond this to provide a general 3D ‘virtual environment’ platform. As well as the classic ‘grid’ configuration, we provide a ‘standalone’ configuration where the entire system is run on a single machine, which is more suitable for some types of virtual environment applications. We also have an experimental ‘hypergrid‘ mode where individual OpenSim installations can be hooked up to each other whilst retaining their own asset and inventory services.
Another aspect to our general platform goal is to enable the use within OpenSim of different client protocols or even different virtual environment types such as VastPark. Most of this support will come from plugin modules. But inevitably it will also require extensive support in the core project code.
Making the necessary changes won’t be easy. OpenSim has grown up around the Second Life client and inevitably reflects the Second Life architecture. For instance, the Second Life client references a user’s profile via that user’s Universally Unique Identifier (UUID), as assigned by the server. But another client protocol may identify a user profile via a unique URL instead. Even such a seemingly small difference has big ramifications – the server code uses UUIDs to reference user profiles right down to the database layers and all this needs to be made more generic. Larger differences would be more difficult yet. Nonetheless, I believe that the generic platform goal is an extremely good one, since it can take OpenSim beyond a single niche and make the code useful in many more situations.
OpenSim is driven by the many, not the few
One reason that we can maintain such a goal is that unlike some other open source virtual world/environment projects, there is no single company behind OpenSim. There’s not even a single group of companies – just like the Linux kernel, our contributors are wonderfully diverse, ranging from paid and volunteer development from IBM through to single contributors employed at startups and people who contribute just for the (masochistic 🙂 fun of it. And contribution rates are heavily skewed towards the individuals.
Partly also because the project isn’t backed by a single company, we don’t follow the common practice of releasing GPL code whilst retaining the right to also license that code commercially. Instead, all of our code is available under the BSD license for anybody to use as they see fit (including incorporation into proprietary paid-for products).
This situation can be seen as both a strength and a weakness. It means that roadmaps and release schedules are harder to come by – nobody has enough developers or central authority to guarantee that dates and features points are met. It means that there’s no legal mechanism for ensuring that development comes back to the community (which can be seen both as a good and a bad thing). It means that the development team is not ‘professionally’ managed by a set of executives focussed keenly on the customer.
But the flip side of this is that OpenSim really is driven by the development community – anyone can submit a patch to any area of the code. Such patches are subject to review on a voluntary basis by core developers and this is far from a perfect process – different developers may have different views on the same patch, and occasionally patches languish. However, it does mean that potentially anyone can influence the project – there should never be any conflict because of an internal commercial interest. And even features which aren’t suitable for the core distribution should be implementable using the module system, either now or in the future as that mechanism improves.
This purely community driven model also means that often things get done in OpenSim only if someone has a particular interest or idea that they want to pursue. This might sound like a bad thing, but it has got us where we are today. So if you’re able to write code and there’s some feature that you think should be in the core OpenSim codebase, or you see some bug that should be fixed, then please jump in! There’s no guarantee that it will be easy – the more radical the feature, the more difficult it is to get it in (this actually tends to act as a stablising influence). But without such a contribution it may be a long time until that feature or bug fix gets done – it may even never get done at all.
Having said all this, I do recognize that this means of steering OpenSim doesn’t directly account for the many talented people out there who don’t happen to be developers. That certainly doesn’t mean that there is an absence of influence from them – conversation about problems or desired features drives the common debate and so affects the code that eventually gets written. Is this enough? I think that’s actually a very complex question and I honestly don’t know, though I do think that the base of user influence will broaden as time goes on, either in OpenSim directly or in downstream projects that use OpenSim as a component.