[sldev] About Linden Lab has not "completely accepted open source
robla at lindenlab.com
Wed Feb 28 15:30:02 PST 2007
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.
On 2/28/07 12:23 PM, Christian Westbrook wrote:
>> Nope! The current First Look is just for texture pipeline improvements.
> 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-
> 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?
> 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.
>> 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
>>>>> 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:
> Click here to unsubscribe or manage your list subscription:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070228/3ac06700/signature-0001.pgp
More information about the SLDev