|
|
Second Life releases client as open sourceJanuary 8th, 2007 |
They’ve been talking about it for years, and now here it is: the Second Life client is now under the GPL. This has big implications for the improvement of the client performance, usability, and distribution. Congrats on taking this step, guys!

You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.



































[...] Bloggers January 8, 2007 19:22 Second Life releases client as open source They’ve been talking about it for years, and now here it is: the Second Life client is now under the GPL. This has big implications for the improvement of the client performance, usability, and distribution. Congrats on taking this step, guys! Source: Raph's Koster Website [...]
[...] So while Second Life still has a ways to go on the openness front, IMO, it is a pretty bold first step and opens the system to a lot of exciting new prospects. I join Raph Koster amongst many others in congratulating them for making this step. [...]
[...] Argument on Raph Koster about SL going open source. [...]
[...] While I add my voice to Cory Doctorow, Raph Koster, and of course many others in commending Linden Lab for taking the plunge, neither a minimum of two months before public source control nor forcing everyone to suffer through a miserable build process for an entire week by not immediately incorporating patches which were available within hours bodes well in terms of fostering active development. Second Life has a ton of scaling issues to work through given the growth in residents we’ve been seeing recently — we can not allow their being understaffed (for what is indeed an unbelievably daunting task) to preclude the community from collaborating to extend their SecondLife experience in any way they desire. This is Your World, Your Browser. [...]
[...] OpenSL: Your World, Your Source I’ve received a good number of inquiries about the OpenSL project (OpenSecondLife.org) and its goals, and wanted to comment further on the implications of open sourcing the SL client in response to Allison Randal’s questioning the need for a community-based OpenSL browser project. First, I want to stress that OpenSL is not an attempt to fork (and certainly not, then, for “fork’s sake”) from Linden’s client. In fact, explicitly to ensure that LL can bring in functionality from OpenSL, we require that all patches are submitted via our patch submission system are authoritatively associated with a Second Life avatar. This allows contributors to the community’s code base to preserve the anonymity of their real life identity, while LL (who has this information on file) can maintain the list they’re requiring of a legal (”real life”) signatures so that they can pick and choose from OpenSL’s code those changes that (a) they see as appropriate for their official viewer, and (b) are contributed by individuals for whom they have signed agreements. As News.com observes, Programmers must sign a contributor agreement to submit code. By signing the contribution agreement, a programmer agrees to assign joint copyright to Linden Lab and grant Linden Lab and anyone who receives the code a patent license relating to use of the code. With Linden Lab owning copyright, it will be permitted to change licensing terms if it desires. But this isn’t about semantics. Much more importantly, I ultimately agree with Dawn Foster, who blogs optimistically about the ultimate effects the release of the client code under GPL: By releasing the client software under open source, residents can modify their client experience, while Linden Lab continues to provide the server side code, which is where they make their revenue. Linden Lab is providing a more flexible environment for users, which should translate to additional users, and at the same time, they continue to have the revenue stream required to keep Second Life in business. This is absolutely true. That said, by Friday there remained only a handful of residents in #openSL (of already roughly 50 in the channel that evening) who had succeeded at suffering through the process as posted on the SL wiki, eager to share their Visual Studio Express / 2005 solution files and appropriately patched code, packaged with dependencies, so that anyone could open and immediately build out of the box. The resulting diffs were too large for even temporary code sharing mechanisms such as cl1p — there was no good way to do this. Developers’ requests about a public repository in #openSL or during the town hall regarding the open source client were told plans were still in the works, but no decision would be implemented within a minimum of two months. A JIRA had been setup which allowed neither the ability to include patch files nor view other pending patches. Even throughout the weekend (when most open source hobbyists finally have time to finally play with their projects and code), nearly all conversation in #openSL was limited to individuals entering with questions on how to get through the fairly intricate build process, rather than discussion of the true potential of an open source SL client. The burgeoning OpenSL community was nonetheless emerging therein, it simply lacked tools to effectively communicate — let alone coordinate efforts to collaborate and to distribute the results. This was not quite, then, the creation of an open source project; it was a fix-it-yerself system that allows LL to pick-and-choose which patches submitted by residents (who are required to sign and submit paperwork in order to include code in LL’s browser) and periodically post a large archive of what had officially been accepted to the “community browser” that one would have to build oneself. While I add my voice to Cory Doctorow, Raph Koster, and of course many others in commending Linden Lab for taking the plunge, neither a minimum of two months before public source control nor forcing everyone to suffer through a miserable build process for an entire week by not immediately incorporating patches which were available within hours bodes well in terms of fostering active development. Second Life has a ton of scaling issues to work through given the growth in residents we’ve been seeing recently — we can not allow their being understaffed (for what is indeed an unbelievably daunting task) to preclude the community from collaborating to extend their SecondLife experience in any way they desire. This is Your World, Your Browser. Where did the word browser come from? I don’t just like 3pointD because Mark’s coverage is authoritative and inclusive — I also love that the name alone is a great play on the role into which I believe the metaverse shall (and is) evolving; the web (1.0) was a system of making information available to everyone, the web 2.0 is a series of sites embracing and leveraging the social connectivity afforded by the internet … embodied in the form of the web 1.0. But the true implications of this connectivity manifested in 3-D virtual worlds — web 3.0 — are far more significant than either of these. To limit the manner in which you experience these shared virtual spaces — the browser — to a single, official version is unwise. Just look at the list of extensions available for Firefox — and imagine having that degree of control over your experience in-world. So, where’s an SDK or even just an API for extensions when you need one, so that people can start making these krazy-kool plugins? This is one of the problems the OpenSL project seeks to solve: constructing a plug-in framework which facilitates development of modifications to the client such that developers need not build and distribute an entire version of SecondLife just to share their efforts. We will be evaluating the best way to do this in #opensl on EFnet (load .NET/mono assemblies vs. Java bytecode, security, … you name it), so if you have any thoughts on the matter, please come join the discussion or visit our wiki. OpenSecondLife.org also hopes to help other projects to be explored by developers that would be separate efforts from the client, yet share the code (and, transitively, the GPL). For example, after creating continuous integration tools, I teleported over to SheepLabs to script a quick object in-world that would check in periodically and light up to indicate the latest OpenSL build status. When my hotel’s internet b0rked a bit ago, after pestering the front desk several times, my inability to work on LSL projects using a simple, offline IDE (or potentially built out with auto-complete, compile & test offline, offer documentation or hyperlink to functions’ LSL wiki entries, much like php) now that the code is available bothered me. The potential for offline build tools is also huge, but is also an undertaking in itself. Finally, Siva over at Sun has succeeded at building OpenSL on Solaris, and — barring any objections by Sun — has indicated an interest in helping OpenSL to add Solaris to the list of supported platforms (Windows, OS X and Linux). These are indeed exciting times — we’re approaching user created content viewed via a user created tool, and the resulting synergy will produce some wonderful new experiences and opportunities. [...]