On Sun, Mar 14, 2010 at 11:32 AM, Ryan McDougall <sempu...@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. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
