[sldev] Voice=Proprietary

[Boroondas Gupte]

Dave Parks schrieb:
> If you're asking for a formal, company wide policy as to how every 
> Linden Lab developer should approach the open source community, you're 
> not going to get one.  Linden isn't that kind of company.  [...]
I didn't meant to ask for a policy (and am happy to hear LL has none 
concerning this) but about LL's strategy, what I think I got the general 
answer for below: As expected (and appreciated) you put the product 
first. However, it would help us to know what that will mean to you for 
the single subprojects.
> For every Linden developer I know of, the choice has nothing to do 
> with control or a lack of respect, but in getting the job done with as 
> little overhead as possible.  By overhead, I mean time spent writing 
> communications like this e-mail that could be spent writing code.  
> It's just that simple.  Most developers would rather write code than 
> e-mail messages. 
Linden Lab is already communicating a lot about development steps it's 
going to take. When you're writing a blog entry about some planned new 
functionality, it won't cost you much time to include some short notice 
about its implications on the open source part (as far as you can 
anticipate them and as far they may not be obvious to people outside 
Linden Lab). On the contrary, telling the community what and where you'd 
like it to get its hands on will often save time for both sides. Partly, 
LL has done that already.
> I'm sure as the developer community around Second Life matures we'll 
> see the lines between the public jira and the private jira fade and 
> eventually disappear altogether for the purposes of bug and feature 
> tracking.
:-)
> If you get the feeling there's a cohort of developers at Linden 
> secretly working on code you never see and largely ignoring your 
> efforts to make changes to the viewer, you're right.  Most of our 
> internal developers are working on server side scaling issues, and it 
> would be silly to have them use the public jira for such things.  
> Worse, destructive, as many of the tasks they're working on outline 
> critical security flaws that exist on the grid today.
That's probably where the 'cathedral' model will be more appropriate. 
It's important for the community to understand this won't make SL 'less 
free' or 'less open source': The FSF themselves used to develop GCC and 
Emacs under that paradigm before ESR's paper. However it'll greatly help 
to know in advance at which parts of the viewer LL will be going along 
this model and at which it won't.
> We're very serious about keeping Second Life open, not just in source 
> form, but as a platform.  We have not to this date and never will do 
> anything that prevents a class of people from accessing Second Life.  
> Any outside service we rely on, any proprietary library that we 
> license, any hardware that we interface with will all adhere to an 
> open standard.  No exclusive deals, no monopolistic endeavors, no 
> artificial limitations.
And that's what I like about Linden Lab. And I guess that's why there 
are already this many of us here, willing to help you to "help [us] help 
[you] to create a new world."

        If you treat your beta-testers as if they're your most valuable
        resource, they will respond by becoming your most valuable resource.
        -- Eric S. Raymond, The Cathedral and the Bazaar

Linden Lab already has a much better culture of communicating with the 
clients and the community than most other companies. Us asking you to 
take that even a step further is only possible because you're already 
there where you are now.
> [...]
> You, the open source developer, have two good options:
> A) Do nothing, happily use the technology that's been given to you, 
> for it is good.
> B) Decide that the technology you've been given is not good, and try 
> to compete with it.
If Linden Labs is going to include a feature that you neither want to 
code yourself nor is available in open source (or if the open source 
implementation isn't good enough) you've got two options, too:
A) Use proprietary code that's good enough
B) See if the community can develop it or if it can improve existing 
solutions

But it won't make much sense to fist include the proprietary solution 
and then see if the community can compete with them afterwards, as this 
could often end up in having things done twice. Even worse, design 
decisions  taken to facilitate the inclusion of the proprietary code 
might hinder community efforts to create something that could even 
better fit the needs of SL. If you ask the community first, and it has 
to tell you it's either not able or not willing to implement what you 
need, you can still fall back to include the proprietary code.
> The point of keeping Second Life open is to encourage competition.  
> The point of competition is to encourage innovation.  If you think you 
> can do better than any proprietary technology we use, do it.  You have 
> my full support and attention.
>
Thanks. We sure will try.

Boroondas