[Opensim-dev] Leaving Project
James Stallings II
james.stallings at gmail.com
Mon Nov 23 23:29:21 UTC 2009
Bravo, Morgaine. Well done indeed. :)
Cheers
On Mon, Nov 23, 2009 at 5:12 PM, Kyle <create at reactiongrid.com> wrote:
> 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.
>
> 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
>
>
>
> No virus found in this incoming message.
>
> Checked by AVG - www.avg.com
> Version: 9.0.709 / Virus Database: 270.14.78/2521 - Release Date: 11/23/09
> 14:45:00
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
--
===================================
http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/pub/5/770/a49
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20091123/824d8cb7/attachment-0001.html>
More information about the Opensim-dev
mailing list