by corylinden
What an amazing first day for the Open Source viewer! With over 1500 people downloading the source, a compile already showing up on Flickr, and a successful bug fix submission, we are off to a good start. However, this is clearly only the beginning. We all have a lot to learn about what it means to have an Open Source viewer out there and there will certainly be bumps along the road. Open Sourcing the viewer is also simply a first step along the path of making Second Life more open and available to everyone.
Rather than chewing up time at the town hall with canned answers, it seemed to make more sense to respond to those in the blog comments first. See you at 3pm PST today.
Remember that the official Second Life viewer will always be available at the Second Life website. You don’t have to do anything with the Open Source viewer to continue logging on as you do now!
Open Sourcing the client does not impact continued development of Mono or other planned improvements to LSL. Although Mono is also an Open Source project, that code will be running on the server, not the client. As has been previously discussed, part of the reason for going to Mono and the Common Language Runtime is to eventually allow more flexibility in scripting language choice.
We recognize that we are currently light on documentation. We will be working though Q1/Q2 to share better documentation as it becomes available. We will also be making additional blog posts about various subsystems in the viewer. While we are open to changes in various parts of the client, fair warning about several major changes that are currently in testing that we hope to release in Q1:
* Multithreading in the client for rendering and texture decodes. This offers a significantly smoother experience and speed improvements on multi-core/multi-processor systems. The message handling, texture decoding, and texture management portions of the viewer have changes a fair amount to accommodate these changes.
* Full support for Vertex Buffer Objects. This provides a performance boost to rendering but has required substantial changes to how geometry and objects are handled on the viewer.
* HTTP texture downloads will allow more reliable and smoother texture downloads but impact the message system.
More broadly, per earlier posts, we’re in the process of moving off of the message template entirely. This will take time, but will result in a far more flexible system better able to accommodate a heterogeneous set of viewer and simulator versions. This, when combined with capabilities, is a major step towards not having to perform monolithic releases of the viewer and servers. Until those projects are released, the official viewer and simulators will regularly go out of sync with the Open Source release. We will make every effort to keep the Open Source version matched up, but we aren’t guaranteeing it. Instead, there will always be a test grid available for the current Open Source version to connect to.
This, of course, raises the question of why release the code now? Several reasons.
First, the Second Life community is the largest and most talented group of designers and developers to ever come together around one project. The sooner we released the code, the sooner the members of the community with an interest in coding would be able to begin building expertise in the code base. Will everyone who will eventually improve the viewer write code this month or this year? Of course not! However, for those with the knowledge and interest, now is the opportunity to get ahead of the curve and capitalize on the experience.
Second, there are enough opportunities in areas not rapidly changing for this to be a huge win for all of us. From optimizations in libJPEG or minor UI bug fixes to improving the build system or playing with how the chat floaters work, many parts of the code are relatively easy to poke around in and open to quick fixes. Annoyed that parcels can’t stream DivX movies? Play around with their embeddable client and then submit the changes!
Third, security. While many of you raised question about security, the reality is that Open Source will result in a more secure viewer and Second Life for everyone. Will exploits be found as a result of code examination? Almost certainly, but the odds are far higher than the person discovering the bug is someone working to make Second Life better. Would those exploits have been found by reverse engineering in order to crack the client? Yes, but with a far smaller chance that the exploit will be made public. Also, as part of the preparation for Open Source, we conducted a security audit and took other precautions to mitigate the security risks.
Fourth, as we continue to scale the Second Life development team — and thank you to the many folks who have helped to get our hiring pipeline humming again — Open Source becomes a great way for potential developers to demonstrate their skill and creativity with our code. Moreover, it makes it even easier for remote developers to become part of Linden Lab. The possibility space for Second Life is enormous, so the more development horsepower we can apply to it — whether working for Linden Lab or now — the faster we all can take Second Life from where it is today into the future.
Several questions were raised regarding security, both in terms of malicious clients and Intellectual Property. Both of these issues are dealt with fairly extensively on the Open Source FAQ, but let me just make a couple of comments. First of all, just like you would be unlikely to use a custom build of Firefox to make purchases on Amazon, Linden Lab will continue to distribute official releases of the Second Life viewer from secondlife.com. Those viewers, and all the code in them, will be screened and tested and any submitted patches carefully examined before inclusion in the main code. Regarding IP, an Open Source viewer in no way reduces your IP rights or claims under DMCA or other relevant law. While it continues to be true that any data that is displayed on the client can be duplicated, it also continues to be true that any such copying may be infringing. I’ve spoken about copying before and I won’t duplicate myself here other than to say that engaging in an arms race in DRM that we will lose is not a good use of development time and effort. We are making changes to allow better meta data and, in fact, much of the groundwork for that has been a critical part of enabling this Open Source release. More discussion on this topic is on the FAQ.
The procedure for submitting patches is described on the submission page. Our prioritization for accepting patches will vary over time but we are most likely to accept small, discrete bug fixes or optimizations. For larger features, please be sure to take advantage of the Second Life JIRA tool to discuss the project. Whether or not it will be accepted will depend on how much it benefits SL residents in general, the risks associated with the feature, and many other factors. However, the best early uses of the Open Source code will be to make the existing viewer work better.
The Second Life viewer is not yet in an open SVN repository, although that will change in the future.
In terms of what should be worked on first, again the best options are find small things that bug you and fix them! After all, if something is annoying you, the odds are high that many thousands of other people are also annoyed. Bug fixes are our highest priority to accept as well, so this will also give you the best chance of making changes that make it into the official viewer.
There was some concern that open sourcing would impact the Mac OS X or Linux ports in a negative way. I actually expect Open Source to be an enormous benefit to both platforms as they both already strongly tied to Open Source. Plus, now if a specific feature isn’t working on your platform of choice, you’ll have the opportunity to go in and add it!
The reverse engineering work of the libsecondlife crew has already enabled the possibility of someone building compatible simulators, so nothing in the Open Source release changes that. The value of Second Life is the community and innovation within it, so my hope is that time and energy will be better spent on improving the viewer while we solve the myriad technical and security issues around making more of Second Life Open Source.
We just finished one Second Life book and I’m sure the publisher will be thrilled to hear that there is interest in a more technical one!
I will be publishing a road map for Second Life in the next month or so that will outline the anticipated changes to both the viewer and the servers to enable this. It is important for Second Life residents to have as much flexibility as possible in how they use Second Life and what they use it for and we have an excellent set of designs to enable that. But, that is a topic for another day.
0 comments:
Post a Comment