[Opensim-dev] Leaving Project

[Kyle]

What she said! Thank you Morgaine for clarifying this for all of us.  In my
opinion this discussion was appropriate here to understand roadmap and
documentation efforts.  Thanks for caring to let the rest of the community
hear about your very smart opinions.  More talk like this will bring the
community together wherever it occurs.

 

From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Morgaine
Sent: Monday, November 23, 2009 6:04 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Leaving Project

 

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> wrote:

 

For me the shock came when I was abruptly informed that "OpenSim is not
Second Life, is not intended to be like Second Life, nor ever will."  I
still haven't the foggiest idea what this developer had smoked for them to
so strongly assert that incredibly false statement.



Len, let me give you an alternative perspective on that quote to help you
see the reasons for it.  I'm not on the Opensim team, but after five years
in SL, two years in AWG, and a year of working on future VW protocols in our
IETF group, I have some background to know why Opensim needs to distance
itself from SL:

*	SL's statically tiled resource architecture is badly non-scalable,
because most resource usage in VWs cannot be statically mapped (demand moves
around).  The inability to assign resources dynamically in SL results in
huge overload in busy places and gross wastage in idle areas.  It also
limits the number of participants in events and the bandwidth of their
interaction, as well as the size and complexity of everything in a region.
This architecture is fundamental to SL, yet it is a recipe for failure.  As
long as Opensim adheres to the SL model, Opensim will be similarly
non-scalable.

 

*	The LSL scripting language is linguistically weak, semantically
obscure, and lacking in the glue that could allow components to cooperate
effectively.  As a result, individual scripts are quite underpowered and
inefficient, and multi-script constructions do not scale well in complexity
because the overheads of cooperation are so large.  That's a bad restriction
on progress which Opensim needs to leave behind.

 

*	LSL scripts are not scalable in power or size, and this will
continue to be true even after SL allows C# and other CLR languages to be
used.  There is no possibility of using more CPU power for scripting than is
available in one single simulator in SL.  That is not a good foundation upon
which to build an ambitious future of clever components.

 

*	SL's simulation environment is non-portable, having evolved over
time into a plethora of special cases that will not be accurately replicable
anywhere else.  In effect this means that there will never be effective
interop with SL's scripted objects.  It would not be a useful goal to seek
compatibility with what could realistically be described as an "ill-defined
mess".

 

*	SL's object and type systems are non-extensible, so compatibility
with SL means living in the past, and worse, living in a past defined
entirely by one slow-moving company.  Tying the capabilities of Opensim to
that millstone would be a disaster --- it would ensure the death of Opensim
versus any extensible alternative that may appear.  Developing new
extensible forms of world data beyond SL's original set is a must for
Opensim's survival as a modern VW platform.

 

*	SL's viewer has deep knowledge of SL semantics because the client
and server were designed for each other rather than designed as endpoints of
a standard protocol.  This has the very bad consequence that future VW
viewers would need to know about SL specifics in order to interoperate with
SL, which is a poor approach that doesn't scale to metaverse-wide diversity.
Opensim needs to leave world-specific kludges behind if it has ambitions to
underpin a highly diverse metaverse of worlds, and this means leaving the SL
viewer behind.

 

*	SL's constructed objects are non-hierarchical, which means that
creators cannot use objects created by others as subcomponents.  This
restriction completely blocks the hierarchical engineering process that is
the basis of progress in RL.  In SL you always have to build from "raw
materials", so it is not possible to ride on the shoulders of giants, nor
harness a huge pyramid of people skills.  Even Philip and Cory Linden
admitted that this was a mistake -- see
https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy .  We don't want
to live with their mistake.

 

*	SL is based on highly centralized concepts of identity, storage and
control, which come together to create either a walled garden or a prison
planet, depending on one's perspective.  Whatever one's worldview, the end
result is badly non-scalable in those three areas.  SL suffers hugely from
that non-scalability despite the relatively small size of the service at
this early stage.  Opensim needs decentralized / distributed mechanisms for
identity, storage and control if it is to scale for Internet-wide adoption.

 

*	From a futurist angle, Second Life has very narrow horizons and
barely pays lip service to the virtual aspect of "virtual worlds".  Nobody
could claim that a Flatland of square land tiles all featuring the same
Earth-like look and physics pushes the envelope of the imagination.  To
boldly go where Lindens did not go before (topologically and geographically
or spatially) will be one of the most appreciated developments in Opensim.
SL's obsession with RL is an unwanted constraint in VWs, and we need to go
beyond it.



That is not the full list of problems with SL, but hopefully it serves to
illustrate some of the concerns that VW developers have to consider in the
light of the SL legacy.  While Linden Lab deserves much applause for their
vision and for their work in creating Second Life, many years have now
passed, and lessons have been learned.  Compatibility with SL must not be
the end goal of Opensim because of issues like those highlighted above.