[sldev] Why Linden Labs needs to let the community extend the client without asking for their IP

John Hurliman jhurliman at wsu.edu
Fri Apr 6 21:22:05 PDT 2007


Tim Shephard wrote:
> Is there a specific part you disagree with?
>
> a) LL is suffering from scalability issues

Propose new ways to reduce database load. Think of ways the client can 
do smarter caching, use bandwidth more efficiently, deal with unstable 
conditions more gracefully. The SL developers mailing list, this is the 
place to do it.

> b) LL is falling behind in the feature races as competitors gather

I wasn't aware that there are more featured solutions out there. Maybe 
we can start a new thread highlighting the "best of the metaverse" 
features out there and talk about bringing this innovation to SL.

> c) SL has a large developer community that could create the features 
> LL is not

I agree.

> d) That developer community needs realistic incentive to extend the 
> client

I went and read back through the sldev archives and I don't think this 
is an accurate picture of the developer community around OpenSL. Looking 
at the rest of the developer discussions going on here and in #opensl, 
and the bug reports and patches submitted to JIRA it seems that everyone 
else already has some sort of incentive to improve the client.

> e) Owning IP rights would give that incentive
> ergo..
> f) Give us IP rights to write plugins.

Because you want to sell proprietary plugins for Second Life. So write 
your GPL plugin API, get it accepted in to official client, and write 
your third party modules ala commercial drivers for the Linux kernel. 
Let me guess, no one will sign off on your business plan unless you can 
get it in writing that LL will actually accept your patches? Several 
people are already working on developing the plugin interface, with at 
least one corporate backer. Somehow they didn't require that Linden Labs 
appoint them as the new chief architect of client extensibility, or get 
a signature on a spec sheet that they can take to investors. Once a 
plugin architecture is in place you don't need to sign over your 
copyright to make plugins, just post them to your website and say have 
fun. LL has been working really hard with the community to try and make 
this interface happen, I'm not seeing this image of a company bent on 
taking all of your code away from you and giving nothing in return.

To address the subject and (I'm assuming) the main topic of this thread, 
they are already working with the community to get a plugin interface 
built that will let you extend the client without asking for your IP. 
They are even looking to hire full time employees for the position of 
"building extensibility interfaces for Second Life" right now. And if 
they weren't, there's nothing stopping you from just writing it 
yourself. If the users of Second Life determine that having a whole 
bunch of custom plugins for their client is more appealing than running 
the official version from secondlife.com then a fork could persuade LL 
to change their minds fairly quickly. Fortunately this isn't happening 
as we're all on the same side here.

>
> Would it help if I drew you a picture?

A flow chart of how a plugin architecture might tie in to the client 
source would be great. A diagram explaining how the current classes 
interact with each other would be another very helpful picture. Anything 
that has to do with development at all would be a shining beam of light 
right now. If it's a picture of your thoughts on Linden Labs' corporate 
management, a sketch describing your current mood when you log in to the 
grid, or a diagram of your get rich quick plan to develop the ultimate 
plugin for Second Life, I'll pass.

John Hurliman


More information about the SLDev mailing list