[Opensim-dev] Leaving Project
Impalah Shenzhou
impalah at gmail.com
Tue Nov 24 09:42:28 UTC 2009
Hi:
Morgaine, I agree with you except:
- 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.
How can I trust anyone who hasn't been authorized through a well known
trusting system? Well, if you mean systems like OpenID, forget my comments.
If not, can you explain that?
About the topic...
Except with the lack of huge, updated and good documentation, and having
into account that there are no money incomes (no business angels out of
here)... it's a miracle for the project to be still alive :-)
No complaints about opensim, no opinions about Blue Mars and the rest...
2009/11/24 Morgaine <morgaine.dinova at googlemail.com>
> 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.
>
> From a longer perspective, SL represents only the first step in the
> evolution of virtual worlds. It is no surprise that most Opensim developers
> wish to go beyond that first step, learning from past mistakes and finding
> better models for the future.
>
> I mentioned earlier our work at the IETF on new VW protocols, in which LL
> are a leading party --- see https://www.ietf.org/mailman/listinfo/ogpx ,
> the mailing list of the VWRAP working group. What may surprise you is that
> even Lindens know that the current SL is not a good model for the future,
> which is why the protocols being discussed go far beyond their legacy ones.
> Indeed, Lindens will be facing a huge rewrite if this work bears fruit.
> When even Lindens don't wish their future to be constrained by the current
> SL design because they know its many problems, this really highlights how
> bad it would be for the Opensim team to do so. :-)
>
> I hope that one or more of these issues resonates with you, and makes it a
> bit clearer why Opensim really cannot afford to align itself with SL. There
> is no future in looking backwards.
>
>
> Morgaine.
>
>
>
>
>
>
> =======================================
>
>
> On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> wrote:
>
>> Rock,
>>
>> I sympathize with you on many levels. I've also had my doubts
>> regarding the future of OpenSim, but I have also maintained some degree of
>> faith that things will pull through in the end.
>>
>> 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.
>>
>> For me, the enjoyment of OpenSim has come from my intense devotion to
>> building and skinning. In fact, for the last few months I've been working
>> on a full region that has many hundreds of skins, clothes, hair, furniture,
>> etc, etc, that I'd like to package up as an OAR and give out freely, since
>> repeatedly I've been told that instead of giving money to help further
>> OpenSim I'd do more proactively by giving content. So I plan to do just
>> that and give my money to other open source initiatives that matter to me.
>>
>> I have a passion for writing, and have thought many times that one of
>> the greatest powers OpenSim would gain is having simple, straightforward,
>> step-by-step instructions on how to download, compile, install, administer
>> and overall just plain operate the core applications. What kills me is that
>> everyone who does a search for OpenSim inevitably hits the
>> opensimulator.org site and that is where the massive roadblock presents
>> itself. It's useless for most and irrelevant to the few who consider
>> themselves OpenSim experts.
>>
>> Heck, even now on the configuration page it still displays info for
>> 0.6.6 including (months old) known bugs in setting up region xml files. If
>> there was appointed a volunteer whose sole job was to keep information on
>> opensimulator.org relevant that one task would resolve a mountain of
>> negativity right there. I sit here in front of my computers a good 10 to 12
>> hours a day.
>>
>> I would sincerely love to contribute to the OpenSim project,
>> especially in documentation support. But the thing holding me back is
>> communication. If I cannot get a straight answer on who to GIVE money to in
>> order to help, then I stand little chance of getting clear, straight answers
>> from developers when asking about issues I need to consider and incorporate
>> in documentation.
>>
>> If communication is a hurdle we can all overcome, with a genuine and
>> heart-felt effort to relay information, motives, and plans with one another,
>> then I'd sincerely appreciate having the opportunity to personally
>> contribute. I'm not a programmer today, but have a degree in programming
>> fro the 90's (so much has changed my degree is practically useless in that
>> regard). But I do know how to explain things and relay information in
>> simple terms. But only if my own questions will be answered with more than
>> "look it up or figure it out yourself" as my answer.
>>
>> If any of you would appreciate my help, feel free to let me know at
>> any time and I'll do what I can.
>>
>> - Len W. Brown
>> lenwbrown at gmail.com
>>
>>
>> On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers <
>> Colin.Withers at eumetsat.int> wrote:
>>
>>> Hi guys,
>>>
>>> I have decided to leave the Opensim project. You will probably not even
>>> notice if I leave, as not being a programmer my only inputs were the writing
>>> of the step-by-step tutorials (
>>> http://chapter-and-metaverse.blogspot.com/ ), the drafts of the OpenSim
>>> User Manual on the Forge, and helping out in the IRC channels, for
>>> newcomers.
>>>
>>> You may find my reasons for leaving Opensim interesting though (and
>>> please do not construe any of my reasons as an attack on anyone).
>>>
>>> 1. The Platform
>>> I raised this several times in the past in IRC, and made posts on my blog
>>> about the product lifecycle of the platform (
>>> http://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html). I believe that the platforms underpinning both Second Life and Opensim
>>> are quite long in the tooth now, and I questioned how much product lifecycle
>>> there was left, particularly given that Opensim is now nearing 3 years of
>>> development, is still in Alpha, and if the current release of 0.6.7 is any
>>> indicator, then still only around two thirds into the development cycle.
>>> With the (inevitable) coming of much superior platforms, such as Blue Mars
>>> and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now
>>> UDK (for creating sandboxes, standalones, and open grids), then I fear that
>>> Opensim has missed the boat as far as the remaining lifecycle of the
>>> platform is concerned. When you show people what is possible with these
>>> engines (for example this avatar editor for the forthcom
>>> ing APB (using the Unreal Engine):
>>> http://www.youtube.com/watch?v=icR3LtEMvZI or this city:
>>> http://www.youtube.com/watch?v=hmLzNbPXMDg (using the CryEngine), then
>>> neither SL not Opensim stands comparison.
>>>
>>> 2. Lack of Support for Currency in Opensim
>>> I felt the impact of this when I first made the switch from SL to
>>> Opensim. I had a thriving RP sim in SL (over 50 people, mainly female) and
>>> they all agreed to follow me over to my Opensim and the OSGrid. However,
>>> within a month they had all left, citing the same reason, the lack of places
>>> to shop, to buy the quality stuff they wanted (skins, hair, clothes etc), as
>>> a quality appearance, and the fun of shopping is what all the females placed
>>> high on their requirements from a Virtual World. They drifted back to Second
>>> Life, and the guys followed them. I have always believed that the lack of
>>> support for currency in the core was a mistake, but that is just my opinion.
>>>
>>> 3. Marketing
>>> I have also raised this issue several times, and blogged about it. It is
>>> far from clear just who an eventually released Opensim is actually aimed at.
>>> I think that any company that is interested in a firewalled corporate
>>> solution to collaboration and prototyping will already be looking at the
>>> Enterprise solution that is currently available from Second Life; that any
>>> indie group that is thinking of running a themed grid will need an economy
>>> to stay viable; and any individual who is looking for a private sandbox
>>> solution for their SL work will need full compatibility (which is not the
>>> case with the OS version of LSL diverging from the SL LSL). So, just who is
>>> the platform aimed at? I was also very disappointed in the view of one of
>>> the core devs who said that 'marketing is a null concept for us'.
>>>
>>> I am currently designing and creating cities for Blue Mars, and involved
>>> in a team for proving the UDK as a platform for the design and creation of
>>> Virtual Worlds (as opposed to purely games), and with so much documentation
>>> available for these mature engines (particularly for the UDK, Blue Mars lags
>>> behind somewhat in that department, but have hired extra staff to put that
>>> right), I am achieving the productivity I want, building the worlds that I
>>> want, with stable crash-free platforms.
>>>
>>> However, I do wish the Opensim team the very best in their endeavours,
>>> and I sincerely hope their goals are eventually achieved.
>>>
>>> If anyone would like to take over the Opensim Tutorials pages at
>>> http://chapter-and-metaverse.blogspot.com/ and
>>> http://chapter-and-metaverse2.blogspot.com/ (they will need some
>>> updating following several changes) then I am more than willing to pass the
>>> posts over, and of course the Opensim User Manual is there in the Forge for
>>> anyone to develop further.
>>>
>>> Best Regards and Good Luck
>>>
>>> Rock
>>>
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20091124/68d95683/attachment-0001.html>
More information about the Opensim-dev
mailing list