[sldev] Plugin API Architecture for Second Life

[Ben Byer]

On Feb 14, 2007, at 2:25 PM, Rob Lanphier wrote:

> On 2/13/07 3:11 PM, Ben Byer wrote:
>> @ Linden Lab:
>>
>> It sounds like splitting chunks of the viewer code into
>> dynamically-loaded chunks is a win-win situation:
>>
>> * Plugins could then link against that code
>> * Dynamic chunks could be updated without disturbing the rest of the
>> viewer
>> * The same mechanisms could be used to create plugins
>> * Infrequently-used functions (estate manager, etc?) could defer
>> loading until they're actually needed.
>>
>> Given that I can't sign a code-contribution agreement, how can I help
>> with this effort?
>
> That definitely puts a damper on things in general.  If you can't  
> agree
> to contribute code or ideas to this effort, then I think writing  
> plugins
> against whatever we come up with/reporting bugs is the next step.=20
> However, even using the bug tracker or wiki requires agreement to the
> contribution agreement there.
>
> I suppose I need to turn the question around.  How do you feel you can
> best help?  Also, what about the contribution agreement is  
> disagreeable?

I didn't say that I couldn't agree to contribute code or ideas to the  
effort, or that I wouldn't do so; I said that I can't sign the  
"Second Life Viewer Contribution Agreement".

I work for a fairly large organization doing professional software  
development, mostly on open-source projects.  Contributing to BSD- 
licensed codebases has historically been acceptable, but anything for  
which I would have to sign a release would require our Legal  
department's review of the document, as well as executive approval.   
Once you've gotten a handful of busy people involved in this  
decision, it becomes a risk / benefit assessment -- what is the  
benefit of allowing Ben to hack away on some "game" vs. the potential  
risk of signing some legal document which could have some unforeseen  
consequence?

Stepping back to the present, "minor" contributions are fine -- small  
patches, build fixes, bug reports, etc, are fine.  (Basically, things  
that don't rise to the level of being "worth" something, taken  
individually.)  I wouldn't be surprised if you hesitate to take my  
word on that, but it doesn't bother my conscience.

Historically, I've been very involved in the libsecondlife project,  
and helped start opensecondlife.org.  I've written some code for  
libsecondlife, but if you go looking for it, you won't find it --  
it's all been rewritten, which is fine with me.  Much of it is like  
the plugin code I posted on the wiki; slightly crude, slightly  
hurried, generally intended to show a possible approach rather than  
be a final solution.

Beyond some trivial non-trivial coding, I've done a lot of  
infrastructure work -- for libsecondlife, I set up the SVN repo and  
moved it 3 times; I wrote the cron script that used to pull out the  
message template and keywords file using gdb so that we could keep  
libsecondlife compatible with the main grid whenever a new version of  
the viewer was released.  (Yes, #libsl, I know it's currently  
busted.  Sorry!)

More recently, I helped set up opensecondlife.org; I set up the SVN  
tree there so that people would have a place to collaborate on code  
that was not yet mature enough to be submitted back upstream to  
Linden Lab; I set up git and Mercurial repos in the hopes that people  
might start using those while we waited for an official LL SVN. I set  
up OpenGrok to give 3rd-party devs a better way to grep through the  
massive amount of source.  I helped write build scripts to make it  
more practical to build and rebuild official releases of the  
SecondLife viewer.  We threw the releases and build scripts into SVN  
to make it easier to collect the pieces together, and started working  
on a "tinderbox"-like continuous integration solution, to speed up  
development.  Since Mercurial never caught on, I started helping  
resync our trunk with every new Linden release, but eventually left  
that thankless, painful task to people more qualified.

Apparently everyone thinks that was a waste of time; I'm told FOSSL  
was started because OpenSL was too hard to build (?) and with the  
intent to "minimize divergence from the Linden Labs code to ease  
merging and patching".  (Best of luck with that.)
Linden Lab seems to see it as at best a waste of effort that could be  
better spent writing up bugs and patches and wiki entries (*), or at  
worst some sort of threat-to-fork; really, it was / has been / will  
be an attempt to fill in the cracks and provide services that aren't  
practical for Linden to provide to the community.  Or maybe I'm just  
tilting at windmills.

Ben

(*) I guess I actually can't do any of that.  Oops.