[Opensim-dev] The Future of OpenSimulator

[Diva Canto]

It's really difficult to have a meaningful conversation about the future 
of OpenSimulator without understanding what OpenSimulator really is, 
from a technical perspective.

Dahlia and Misterblue already mentioned it, but I'll mention it 
again.OpenSimulator, as designed by this particular team of developers, 
is a framework or an application server, not a complete product. It's 
full of hooks so that people can create their own products while having 
a good jump start with a bunch of default application behavior. So, off 
the box, it looks like SL (plus a few goodies), as that seems to be the 
default behavior that most people are/were interested in, to leverage 
the existence of the SL viewers; but if you want, it can be made to look 
like something completely different.

The best analogy for what OpenSimulator is is this (courtesy of Apple):
https://developer.apple.com/library/mac/referencelibrary/GettingStarted/RoadMapOSX/books/IntegrateYourCodewiththeFrameworks/Art/house_framework.png

At its core, embodied in the dll OpenSim.Region.Framework, it's a 3d 
scene manager. That's about it; that's all that's hardcoded. The scene 
manager interacts with the rest of the software via a number of 
interfaces that are expected to be implemented in some way or another, 
and that are all dynamically loaded via an external specification 
(plugins). Most notably, there are interfaces for: user clients, 
physics, scripting, numerous backend resource services, data storage 
providers, and a generic interface for adding any kind of additional 
features to the scene manager (aka "Region Modules" given by the mono 
addin extension point /OpenSim/RegionModules). There is also an even 
lower-level generic interface that allows the injection of additional 
features at the server level (given by the mono addin extension point 
/OpenSim/Startup).

Just above that core, embodied by several other dynamically loaded dlls, 
there is the default application behavior of SL, with almost 
feature-full support for the LL protocol 
(OpenSim.Region.ClientStack.LindenUDP.dll and many others). This 
behavior can be replaced by providing other dlls that implement the same 
interfaces. So if you want to support any other client protocol, you 
can, by implementing the corresponding interface that the scene manager 
expects clients to have.

Using that Apple image of what a framework is, people can have lots of 
ideas for how their favorite house will look like. I have mine. But 
that's not what OpenSimulator is. OpenSimulator is the framework, plus 
the default "Linden house" that can be replaced entirely.

Having explained that, the conversation about the future of 
OpenSimulator is a conversation about the future of the framework and 
default application behavior that comes with it, not about any 
particular alternative "house." There can be separate conversations 
about alternative houses, but I doubt they will be of interest to the 
exact same team that has built, and is building, the framework.

So what kinds of topics should we talk about when discussing the future 
of the framework? Here are some:

1 - The APIs. Some APIs are already pretty solid and flexible, others 
are a complete mess. The client API, for example, is a fur ball, because 
it is meant to be a generic client API but so far we have had only one 
type of client. Unfortunately, it's hard to untangle that fur ball 
without having at least another type of client that comes in and 
challenges the assumptions made very early on.

2 - Leakage from the Linden application onto the core of the framework. 
The picture I painted is very compelling (I hope!) but the reality is 
just a little bit different. From early on, there was some leakage from 
the design of the Linden house onto the core of the framework. For 
example, the data structures we use for modeling 3d scenes are heavily 
influenced by how the Linden viewers expect things. It would be nice to 
drain the core from that influence. This will be a major undertaking, 
and I don't know who among us has time/motivation to do it, but I know 
that there have been designs and plans to do it, which unfortunately 
didn't pan out.

3 - Documentation of the framework. Community-led open source projects 
tend to fare really poorly on this, and OpenSimulator is no exception. 
The Wiki is a mess. The code has been the most reliable documentation so 
far (for me, at least), followed by asking questions on the IRC. This 
raises the bar for what kinds of people can develop addons for 
OpenSimulator; people who are comfortable with reading tons of code and 
asking questions to complete strangers eventually start to understand 
how the framework is architected; people who need to read English get 
frustrated and go away. Maybe not a bad entrance criteria for a while, 
but if we want more action on the kinds of houses people build, the bar 
needs to be lowered by providing documentation. I don't have a solution 
for this, because translating from C# to English is a boring job that no 
core developer is willing to do [for free], but I sure would love to see 
some action!

4 - The ease of finding and sharing alternative implementations of APIs 
from 3rd party developers. This one is pretty high up on my priority 
list and, in my view, it's the single major technical goal that needs to 
be achieved before we can tag 1.0. Without a package distribution system 
that connects providers and consumers, frameworks are of very little 
use; the only way we can help connect them is to add more things to the 
core package, which is alarming -- complexity of software grows 
exponentially with the number of modules, not linearly. I have been 
experimenting with the mono addins package manager for my own addons; 
I'll have more information of how that really fares on the next release, 
when some people will have to upgrade my addons using the package 
manager command line tool.

5 - The default "house." There is no question in my mind that this needs 
some repairs, and I am really happy with how much closer we have been 
working with viewer developers. Realistically, this evolution will be 
not be a radical departure from what SL is, it will be just a bunch of 
small improvements, hopefully leading to viewers that are a lot more 
secure and programmable. For radical departures, see above my 
description of OpenSimulator and the previous point 4 for how to connect 
these more radical "houses" to potential consumers.