[sldev] [POLICY] OpenSL considered harmful?

[Lawson English]

Kelly Linden wrote:
> Joshy Squashy wrote:
>> OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source 
>> alpha Second Life server framework.  It is extremely crippled, with 
>> limited scripting options and a large number of missing features; 
>> however, it is functional.
>>
>> The laboratory at my college has been doing research using synthetic 
>> worlds in education software projects and software engineering 
>> projects for some time.  We have been following development of OpenSL 
>> for some time, as we are very excited with the possibilities of 
>> having access to the source code for both the client and server 
>> (particularly in situations when the SL server should also be some 
>> other type of server).
>>
>> Though OpenSL isn't much at the moment, we are approaching the point 
>> where we plan to try OpenSL servers for some very simple projects.  
>> However, some colleagues disagree that we should consider OpenSL, 
>> claiming they are reverse-engineering Second Life's message protocols 
>> and that having the potential for hosting "free" Second Life servers 
>> is a threat to Linden Labs so Linden Labs will either shut down 
>> OpenSL or release client versions that render OpenSL unusable.
>>
>> While I don't know Linden Labs opinion on the subject, I would think 
>> that such claims don't amount to much.  Releasing a client version 
>> that renders OpenSL unusable can't really happen because the client 
>> is open source so it's a trivial matter to remove the code that 
>> prevents interoperability.  However, shutting down OpenSL I see as 
>> conceivable but unlikely; the OpenSL server is so crippled that one 
>> would need very specific reasons as to why it would be desirable to 
>> use it, and Linden Labs hasn't taken action yet.  I simply don't see 
>> Linden Labs as considering this to be a threat, particularly 
>> considering their substantial existing userbase and that my 
>> understanding is that they've been toying with the idea of releasing 
>> the server code outright themselves for some time already.
>>
>> Still, my colleagues and I would be very interested in hearing Linden 
>> Labs direction in dealing with those involved in developing 3rd party 
>> Second Life server frameworks.
>>
>> ~Squash Otoro
> As others have pointed out, we are working with OpenSim (along with 
> other people) in the AWG groups on standards of interoperability.   
> >From the wiki page:
> "AWG's mission is to develop the protocols that will open up the 
> Second Life Grid from something operated solely by Linden Lab to where 
> others can run parts of the grid."
> I think someone linked it already, but more info on AWG here:
> https://wiki.secondlife.com/wiki/Architecture_Working_Group
>
> I am sure the AWG group, and myself personally, would be interested in 
> any reasoning for using OpenSim over SL - what you mean by "when the 
> SL server should also be some other type of server" etc.  Your 
> requirements probably aren't entirely unique and I'm sure the group 
> could benefit from hearing them.
>
> As for OpenSim specifically, we don't have the means to block access 
> to them (due to the open source client as mentioned), nor do I think 
> we have the desire to.  I can't offer any official statement about 
> OpenSim or our future interactions with them, but I think our work 
> with AWG speaks clearly towards our intent.
OpenSim and libsecondlife are already acknowledged as being alternate 
implementations of the [soon-to-be-open] grid.

https://wiki.secondlife.com/wiki/AWG_Implementations


As far as why people might want to use them goes... Well, the most 
obvious reason is simply immediacy. The issues with open sourcing the 
server code are apparently quite complex or so comments by various 
Lindens suggest, while OpenSim and the libsecondlife people are far more 
nimble organizations than Linden Lab, being smaller, and not driven by 
quarterly-profits so they can change what they are doing and where they 
are heading far faster and easier than LL  Also, they can customize 
their own code far faster than the unreleased code from LL (obviously) 
and if the issues with the client source are anything to go by, 
customizing the server code will be exceedingly difficult, even 
impossible, past a certain point.,

It is quite literally easier to rewrite the client from scratch than to 
customize it in certain ways, and the same thing will no doubt be true 
of the server code as well so using OpenSim and libsl will be the method 
of choice for creating specialized software based on the SL platform for 
quite some time. The AW Groupies modular client project may eventually 
become an alternative on the client side, but we don't have any way of 
producing that on the server side without doing the reverse engineering 
thing, which OpenSim is already doing.


Lawson