[Opensim-dev] Leaving Project

[Morgaine]

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.