[sldev] About Linden Lab has not "completely accepted open source development"

Tim Shephard tshephard at gmail.com
Fri Mar 2 07:18:37 PST 2007


Rob Said:

" One thing that will help is for us to have contributor agreements
from everyone who is
contributing code and substantial ideas to the conversation (which so
far, we don't).  Quite frankly, I should probably advise /against/
having our developers listen to anyone who hasn't signed an agreement,
since it would be really bad to come up with a design, and then have
someone claim it was their idea and they didn't license it to us.
Perhaps it might make sense to actually have a separate mailing list
where only those who actually sign contributor agreements can post,
and make it clear that mailing list postings are contributions."

I obviously can't speak for anyone else here, but I would be very
motivated to sign such a contribution agreement if a Plugin Exception
license were to be made sooner rather than later.

On 2/28/07, Rob Lanphier <robla at lindenlab.com> wrote:
> Christian,
>
> I take extremely strong issue with the statement "LL is not [yet?] an
> organization that has completely accepted open source development".
>
> We're an organization who is working out the kinks in the process.
> We're very pleasantly surprised with how quickly people have been able
> to get up to speed with the code, but as many non-coding customers have
> pointed out, we have many very important things to work on that have
> nothing to do with our new open source initiative.  As we scale up our
> team to deal with the long list of challenges we face, we'll get better
> at collaborating with the community, in part because we'll now be hiring
> from a pool of people who know they'll be working for an open source
> company, and in part because we'll likely be hiring people who start off
> as community contributors.
>
> One thing that's very well established in open source culture is that
> it's typically a meritocracy, not a democracy.  We can't listen to
> everyone with an email account; we have to pick and choose who we
> respond to.  I haven't been very good at the filtering process to date,
> but one thing I'm going to be looking at in determining who to listen to
> is who is actually contributing patches and trying to build a
> relationship with our dev team in a valuable way (with code that fixes
> problems).  How many patches have you contributed?  Looking through
> Jira, I don't see a bug report, let alone anything with a patch attached.
>
> This codebase took years and millions of dollars to build, and we've put
> it out under an open source license at time when we didn't have to.
> While we realize that there's a lot of work we have to do to get things
> working the way we all want it to, I'm having a difficult time mustering
> an apology.  We posted more than a patch; we posted the product.
>
> I'm not saying we're above reproach, or that we aren't grateful for the
> flood of patches that have come in, or that we don't want to see
> criticism.  Just understand that we had to disrupt quite a bit of our
> operations just to publish the code.  We're doing more, but big part of
> my job is to make sure this initiative is successful both in-and-of
> itself, /and/ more importantly, doesn't kill Linden Lab in the process.
> So, beyond the nudging I've done, I'm not inclined to tell our
> development staff "stop working on grid stability, we need plugins".
> Please be patient.
>
> As to the elephant in the room, which are the many outstanding legal
> questions on the list.  Sorry, we've got very good reasons why those are
> taking longer than everyone would like, most of which I can't get into
> on this list yet.  I would /love/ to resolve these issues, but not being
> a lawyer, I can't do it alone.  What's more, these aren't strictly legal
> issues, some of them have pretty profound business implications that we
> need to explore.  As we staff up in this area, we'll be able to do more
> here.  Once again, please be patient.
>
> Sorry if I'm coming off as harsh, but as people who have worked with me
> a while know, I try to be a fair broker.  I can very forcefully make
> arguments for the community within Linden Lab once I'm convinced that
> there's an argument to be made.  I've actively encouraged more
> involvement by Linden Lab developers on this mailing list, and I'm
> emphasizing transparency right now over collaboration, because I think
> that's the first step.  I'm trying to get them to share their priorities
> with you, not change their priorities to match yours.
>
> I have some half-baked ideas for making the plugin conversation go more
> smoothly, but I still need to sort out some loose ends.  One thing that
> will help is for us to have contributor agreements from everyone who is
> contributing code and substantial ideas to the conversation (which so
> far, we don't).  Quite frankly, I should probably advise /against/
> having our developers listen to anyone who hasn't signed an agreement,
> since it would be really bad to come up with a design, and then have
> someone claim it was their idea and they didn't license it to us.
> Perhaps it might make sense to actually have a separate mailing list
> where only those who actually sign contributor agreements can post, and
> make it clear that mailing list postings are contributions.
>
> Rob
>
> On 2/28/07 12:23 PM, Christian Westbrook wrote:
> >> Nope!  The current First Look is just for texture pipeline improvements.
> >>
> >> -RYaN
> >
> > Richard,
> >
> > Thanks for the heads up on LLFloater and the mutability of the code
> > in general.  I can't deny this is a little alarming but is certainly
> > worth hearing, yet I think it sheds light on a larger issue, also
> > illuminated somewhat by the discussion yesterday about attempting to
> > protect plugin developers from changes via abstraction:  it's very
> > difficult (some might say impossible) to develop meaningful  code on
> > a codebase that is changing with only vague hints as to how it will
> > be changing.  I understand and appreciate that LL is not [yet?] an
> > organization that has completely accepted open source development,
> > but firmly believe that there is a happier medium between a closed,
> > proprietary software company and an open source platform -- happier
> > for LL, the community, and third party/independent developers -- to
> > which LL must move for any of these discussions about plugins, etc.,
> > to bear fruit.
> >
> > It's been a full month since the last code drop of the "real" viewer
> > source code.  First Look has been pushed out with some regularity
> > throughout February, but was first done so with the caveat that it was an
> > experimental branch that should not be incorporated into our trunk.
> > It sure seems like all LL devs are working on FL -- when did this
> > change?  Without any transparency, this feels like a simple bait-and-
> > switch.
> >
> > Please consider this a call to the LL dev team to come out and play!
> > Even cognizant that some features like lip sync/VoIP will remain in-
> > house only, there is a huge disparity between dropping code (at any
> > interval) and developing *with* the community.  How can we all help
> > push the metaversal envelope without compromising LL's business plan?
> >
> > Regards,
> >
> > Christian
> >
> > On Feb 27, 2007, at 12:58 PM, Richard Nelson wrote:
> >
> >> Just jumping in here to comment on LLFloater stability.  In general,
> >> we can't guarantee that our UI class interfaces will remain stable.
> >> For example, we recently changed LLFloaters and LLPanels to implement
> >> LLUICtrl in order to sanitize our keyboard focus model and let them
> >> participate fully in focus management (LLView's can't delegate
> >> keyboard focus, they can only contain LLUICtrls, or widgets).  We've
> >> also made many changes in the move over to XML-driven UI.  These
> >> changes are not complete, and we will continue to tease out
> >> architectural abstractions and refactor our UI code based on use
> >> cases as they arise.
> >>
> >> That said, most changes can be considered extensions to existing
> >> functionality, implemented in the base class, with no extra burden on
> >> derived classes.  There are still large architectural decisions to be
> >> made, though.
> >>
> >> Richard
> >>
> >>
> >> On Tue, 27 Feb 2007 09:32:17 -0800, Rob Lanphier
> >> <robla at lindenlab.com> wrote:
> >>
> >>>
> >>>>> Basically there would be an instance of LLFloaterPluginProxy for
> >>>>> every
> >>>>> plugin floater created.
> >>>>
> >>>> I initially rejected the derivation idea, as a class derived from the
> >>>> floater class meant that this class would change any time the
> >>>> floater did.
> >>>
> >>> OK, that concern makes sense.   However, looking through the code,
> >>> llFloater seems likely to be very resistant to change.   If it does
> >>> change, it would likely impact a very significant amount of code and
> >>> therefore would only occur when absolutely necessary.
> >>>
> >>> Perhaps a linden can comment..
> >>>
> >> _______________________________________________
> >> Click here to unsubscribe or manage your list subscription:
> >> /index.html
> >>
> >>
> >
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> > /index.html
>
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
>


More information about the SLDev mailing list