[sldev] Voice=Proprietary

Tim Shephard tshephard at gmail.com
Tue Mar 13 11:45:52 PDT 2007

Communicate with code then.  Show us your commits.  We're not idiots here..

On 3/13/07, Dave Parks <davep at lindenlab.com> wrote:
> 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.  While we
> strive for transparency, we're not going to force internal developers to
> communicate everything they're working on to the community, but every
> developer has the option of doing so.  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.  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.
> 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.
> Which brings me to this: taking the stance of only adopting open source
> technologies creates an artificial limitation to advancing Second Life
> as a platform.  If a system exists that improves Second Life, whether or
> not that system is open plays a limited role in our decision making
> process when choosing whether or not to use it.  Second Life is a truly
> open platform, even for closed technologies.
> Faulting us every time we use a non-GPL or LGPL technology amounts to
> political zealotry and will only retard progress.  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.
> 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.
> Boroondas Gupte wrote:
> > Callum Lerwick schrieb:
> *snip*
> > That would be the old question of the cathedral and the bazaar
> > <http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar>. Linden
> > Lab will have to make clear where they see their open source efforts
> > on the scale between those extreme paradigms. They are of course free
> > to redefine that for every single part of the project. I has not to be
> > the same for the entire thing and also might change over time. Anyhow
> > I think it would help community developers a lot if the status quo
> > concerning this was known as well as LL's plans about where to go from
> > there.
> >
> > I don't know if LL has worked this out for themselves, yet. If not
> > they should now ;-)
> >
> > Boroondas
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev

More information about the SLDev mailing list