[opensource-dev] Fwd: Request for comments about llSetAgentEnvironment / SVC-5520

Soft Linden soft at lindenlab.com
Sun Mar 14 12:13:57 PDT 2010


On Sun, Mar 14, 2010 at 11:32 AM, Ryan McDougall <sempuki1 at gmail.com> wrote:
>
> LL unilaterally designs and implements code behind closed doors, where
> it is accepted and merged then deployed -- all without any outside
> participation. In the linux kernel, design is discussed in the open,
> occasionally implemented behind closed doors, then discussed again for
> inclusion in Linus's kernel.
>
> The only nod to "open" is the GPL source, this impotent mailing list,

The only nod to open source is the open source?


> and an equally ignored wiki. The community is "poisoned" from the
> cognitive dissonance caused by not yet realizing they don't even
> exist.
>
> Let's face facts here: LL as an organization doesn't know how to do
> open source, and those who even *like* open source are limited to a
> handful stalwarts like Soft who mostly end up regretting their forays
> here. Community contributions, beyond some free labor donated to a
> for-profit company as bug fixes, will never be relevant.

This is wrong. Lip sync, mini map features, additional language
support, the first pass on flexible sculpties (not yet out in the main
viewer, but not dropped), double-click teleport, 64-bit build support,
stand-alone build support, strong debit permission warnings, the list
goes on. Many non-bug-fix changes have come from the community. I
agree that the process has been painful and slow, and not as many
patches have come in as most would wish, though. That's the reason
Snowglobe was created. Much faster iteration and proving of patches.
Don't call that a failure before you've seen the last bits of the
viewer 2.0 development cycle put to rest.

What I'm trying really hard to get across here is that keeping
discussions civil, focused and constructive will help foster community
involvement. Q is working really hard to make sure that a feature held
in the dark for business reasons will never hold the rest of the
project hostage again. I can't see a reason why another Viewer 2.0
style dev cycle will happen again.

We're also working on restructuring the project so we're working in
peer code bases rather than doing one-way exports and manual patch
imports. That's going to make us better still about bringing outside
work in. But these efforts are going to be wasted if the teams are
still put off of working with the community because of the garbage
hostility that's been a frequent part of the list since very early on.


> Open source is a meritocracy where those who make the code, make the
> decisions. Since the code of contributors is not welcome (outside of
> free QA), decision-makers are nowhere to be found, and what you're
> left with is whingers, bike-shedders, and blow-hards ruminating the
> same stale cud thread-in and thread-out. When will the lobster
> quadrille end?

For a good example: Read back on the list for the kind of responses
the render team was happening in the open. The render branches were
published continuously, and the developers were quite public-facing
for most of a year.

The result? There were some morsels of great feedback, almost none of
them via this list. But there was also an overwhelming volume of
griping about not supporting year-old video cards, people crediting
other projects for Linden work, grousing about that not being the most
important thing to work on, grief about the state of Windlight,
insistence that we abandon our own engine entirely, stumping for other
projects, folks from this list blogging Runitai's comments out of
context, on and on.

Tons of counterproductive chaos when someone wasn't getting his way,
some good QA feedback, a couple good tech suggestions, and almost zero
code contributions. That's what we've gotten when the decision makers
are out in the open - you can't say it hasn't been done.

The render guys still want to get their work out and in the open
again, because they happen to be fairly bad ass and have thick skins.
They think the QA and bits of good feedback are worth more than the
cost of that chaos.

Other teams will be able to make that choice again now, just as they
could before Viewer 2.0. Work in the open with community involvement,
or merge branches after working in the dark? There's a lot that
members of this list can do to influence just how many teams make an
open choice.


> Even monkeys learn after repetition.


More information about the opensource-dev mailing list