Applications and Tools, Business in Virtual Worlds, Collaboration, Privacy and Protection, Second Life, Virtual World Platforms, Visualization in 3D

OpenSim: The Places We Could Go

Gwyneth Llewelyn slipped a New Years present under the door last night with a post on OpenSim that may well stand as one of the definitive “must-reads” for the year to come. Not being terrible technical (OK, not at ALL technical), I may be missing other summaries with more geeky goodness. What Gwyn has managed to accomplish is to take all the threads, posts, technical summaries, and her deep insight to create a readable, compelling and articulate summary of OpenSim.

In addition to explaining what OpenSim IS, Gwyn has provided a readable technical summary that can serve as a master document for making decisions on OpenSim deployment. She has very neatly summarized the history of OpenSim, explained the importance of modular versus monolithic code, and has gone deep in explaining the features, functions, pros, and cons of OpenSim virtual environments.

This should be required reading for, well, all of us. For the Lab (print out copies and give it to new employees), for residents of Second Life considering the leap to OpenSim-based worlds, for developers, for enterprise, and for anyone considering hosting their own OpenSim servers.

Finally, I have a better understanding of the different terms around deploying OpenSim hosts, including decisions around:

- Choice of physics
- Prim and avatar limits
- Coding language (LSL, Java, C++, etc.)
- Chat options and why IRC is so important
- Load balancing

She also reminds us that OpenSim is the technology, and hosted grids are the worlds, attempting to clear up the confusion that there is a choice between Second Life and OpenSim – there isn’t. It’s the choice between SL and a range of worlds based on the OpenSim platform.

Her post is also filled with useful links, including to Prokofy’s overview of the “user experience” and the various ‘worlds’.

Thank you Gwyn, for such an insightful, articulate post.

OpenSim and the Lab
Gwyn closes off her post by discussing the implications of OpenSim development to Linden Lab. Much of the focus on this has been and will be around open grid protocols and the ability to move between ‘worlds’. As Gwyn summarizes:

“The future is interconnection, and LL has been quite good at promoting that idea. They have always envisioned a metaverse of several interconnected grids, with LL at the core. However, it seems that they have underestimated what this actually means: the interconnected grids using LL’s protocols and looking just like SL are already there and have 30 or 40 thousand users. They will grow to the point where LL is running just one of the many SL-compatible grids, and the only one that is not interconnected, which is absolutely ironic.”

But I’m going to take slight issue here with the focus on interoperability. I’m not convinced that allowing or disallowing interoperability is going to make much of a difference to the success of the Linden Lab “Grid” (and I use that term very specifically, as compared to Second Life). It may have an impact on the success of the Second Life mainland, but that’s a different issue entirely.

What discussions of OpenSim as a competitive threat to Linden Lab neglect is that regardless of all the innovation and modularization and so on, Linden Lab isn’t JUST left with one big grid that may be disconnected from the many little mini Grids sprouting up on the OpenSim framework. The Lab is clearly moving in the direction of “grids in a box”, and by moving in this direction will offer an enterprise-grade solution whose technological underpinnings remain unclear.

If it’s true that the Lab is launching “separate servers” (as indicated through the discussions around Rivers Run Red’s Immersive Workspaces and Mark Kingdon’s comments indicating the same), then there is likely more under the hood than just plugging in another server in California. These servers are ‘ready to ship’ – which means that the technology has somehow been unplugged from the rest of the Grid architecture, which may also mean that the people who will soon be able to host their own “SL servers” may have far more control over how those servers are expressed.

Many of the features that Gwyn is enthusiastic about regarding OpenSim may have parallel “plug-ins” for the Lab’s “private simulator” plans. Options for voice? Sure, why not? Unplug the Lab’s solution and plug in your own. Estate-level control over prim and avatar limits? Again, why not? If it’s privately hosted it’s no longer part of the contiguous “mainland”.

But these are niggling points. The main thing to remember is that many of the current advantages of OpenSim as a user would describe them, (or a business) can be matched relatively easily by Linden Lab: firewalls, privately hosted, estate-level avatar and prim limit control, customized voice plug-ins, and integration with external systems.

This doesn’t deny that OpenSim may have a more thoughtful technology in the long run, because of its modularized approach, and may thus be more scalable and stable given time: on the other hand, those same features may lead to ‘user confusion’ – all of this teleporting from one “world” to the next, all of them based on OpenSim, and each with their own blend of physics, limits, permissions, rules, policies, and code – well, it may be a wonderful form of innovation but for the casual user it COULD also get pretty confusing. Time will tell.

OpenSim: Where We Can Go
What excites me about OpenSim isn’t that it may end up being a “slightly better cheaper” Second Life. What excites me is that it can allow innovation that simply isn’t possible on the Grid. Now, maybe some of these things have been done, or thought about, or simply won’t be practical. I have faith that OpenSim will be more than a ‘better engineered’ SL and be able to take innovation paths of its own. But here are a few of the things I’d like to see to convince me, or that I think are otherwise needed:

Policy Framework
I’ve blogged about this in the past. And here’s the typical response: OpenSim is like Apache. OpenSim is a technology, not a world. Policy comes from worlds, therefore, policy is the domain of the people who host those worlds not the code that allows them.

OK, you know what? Cut the crap. This attitude is a total abdication of the opportunity to innovate. You mention policy and immediately people think you mean ‘content protection’ (which is one HUGE component) and then want to wash their hands of it.

Give me a break. This is narrow-minded, feeble, and shows a stunning lack of imagination.

Raph Koster thought long and hard about content protection, avatar rights and commerce before he started coding Metaplace. HE gets it – what, are you better than Raph Koster??? His coding decisions and architecture were informed by thoughts about policy and community. The OpenSim developers have lost an incredibly meaningful opportunity to contribute to the place of virtual worlds in the wider domains of knowledge and meaning by generally ignoring these discussions, slamming people who bring them up, or defending themselves with all kinds of linear arguments about what code will or will not allow.

So what’s the solution? On my wish list: a thoughtful discussion of these issues in which everyone agrees to a multi-step process:

1. Determine the domains for policy: simply come up with definitions of what domains may play a role in the expression of virtual worlds based on OpenSim or other platforms. These domains would probably include identity, commerce, intellectual property, content protection, governance, etc. Surely we can all agree on what the domains might be.
2. Determine the range of options, regardless of what technology allows or doesn’t allow, within each of these domains. Again, surely we can agree on what the range might look like.
3. Do a gap analysis between the range of options and what is currently possible. For example, absolute content protection may not be currently possible. But identify how wide the gap is.
4. Identify, broadly, the opportunity costs for the gaps. If the gap could be closed, what opportunities would that open up? If the gap wasn’t closed, what negative consequences might follow? Try to think long-term as well as short-term: how might this look a year from now, 5 years from now?
5. Brainstorm solutions to the gaps. Brainstorm them from the perspective of “If we were building this from scratch” and also from “If we were adding to what we have”.

It’s step four and five, I imagine, where the fist fights might break out. But surely by taking the first few steps we could come to some broad consensus of where some of the issues and opportunities lie, and you might get some focus on the things with the highest opportunity.

A World without Avatars
One of the things I’d like to see is whether OpenSim can be deployed without avatars and to understand what options might look like for viewers and navigation.

Now, that might sound odd: what’s a virtual world without avatars? But there’s so much innovation happening in the fields of design, architecture, and visualization that I can’t help wondering whether virtual world technologies aren’t missing a significant opportunity.

Take the virtual factory floor:

“The Coperion Group is planning and producing plants and systems for the plastics industry. The presentation at Coperion’s booth at K Fair in Dusseldorf consisted of Fraunhofer IGD’s multi-touch table and an impressive 8-meter wide high definition projection mirroring the table’s image. With this application Coperion demonstrated their core-competencies to the markets and complex processes in a plant for bulk material handling via Virtual Reality. InstantPlayer and InstantCluster were used to render the interactive real time 3D visualisation.”

I can think of a dozen use cases where the ability to access the 3D content of SL or OpenSim for the purposes of product modeling, design collaboration, etc. doesn’t require avatars at all. It’s unclear to me whether you could host an OS server, remove avatars, and end up with something that’s faster, or that could be done in a browser, like Adam’s Frisby’s Xenki:

Microtransactions
I hesitate to put the word commerce. Every time commerce is mentioned on one of the OpenSim or developer lists, it’s as if you yell “fire” in a brothel: you’re spoiling their fun and you’re welcome to take it outside.

Commerce is a thorny issue. But it’s a thorny issue on the wider Web: OpenSim may not be the place to solve it, but this will certainly be the year where we start to see really innovative work done on micropayments, whether on the Web in general, or as a test in OpenSim in particular.

Frankly, I think that Linden Lab would be better off trying to solve this issue and turn the Linden into a proper micropayment service for deployment across multiple platforms than to worry about teleports, which they’ve put a hold on in any case.

HTML On a Prim
I’ll race you: whoever gets true clickable HTML on a prim first, wins.

23 Comments

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.