Hi guys, I haven't been posting on this subject at all on sldev though, of course, it is of prime importance, especially if my health is in line (thanks Melinda for your concern, I just got a complete physical and my heart is in no danger of immediate arrest... :) )
There are a couple of things I wanted to say though on all this matter: one on Open Source in general, and one on Snowglobe in particular, which is the theme of that thread. On Open Source: Open Sourcing code is by its very nature a call to others developers to do and try new, interesting, innovative things. Things that we, LL, don't have the resource to tackle, markets too small or too niche for LL to focus on, use cases that we can't reach because we can't know everything. That's what we want to enable. This is not a competition of "our viewer" against "your viewer" and we don't feel embarrassed or ashamed that someone else comes up with other interesting ideas. Challenged? May be, sometimes. But challenge is good. Thinking about it, this flurry of features tried and tested in the open gives us market selection/validation better than any market study could ever give us. What's not to like? On Snowglobe now: even if we open source the viewer, there's no particular reason for LL to actively develop something in close collaboration with a community of developers. We could just throw regular source tree out there and let people do their stuff and that's what we've been doing prior to Snowglobe (and still do with the viewer trunk). The objective of Snowglobe was different, it was to establish a project where LL and a community of interested devs would engage and collaborate on some projects. Those projects are chosen among the deep core structure of the viewer (so far: texture fetching for performance, plugin architecture) because this is where wide collaboration is the most fruitful. Those changes are tricky, require extensive testing (for which we are grateful) and benefit from having their code read and tweaked by a community of developers. http-texture got plenty of great fixes that way (the curl crasher fix comes to mind). We welcome developers creating new viewers with specific user targets or use cases in mind. Why not? There's no reason to have a one size fit all tool to access a world as rich as SL. That's the whole point of having an open source viewer in the first place: we want everybody to use SL for every possible use case of IW activity and if that means that they need a specific viewer for it, the open source code is there for them to do just that. That's the point. So in conclusion, we love to see other alternative viewers. This is great. May a thousand roses bloom! What we don't want though is for those viewers to break the ToS and act as giant griefing machines. That's the specific narrow point of that new policy discussion. As for Snowglobe, it won't stop once viewer 2.0 is out and, as Melinda mentioned, we'll merge (or more than likely re-base, I've been thinking about it lately...) when time is right. Cheers, - Merov On Mon, Oct 26, 2009 at 8:26 PM, Melinda Green <[email protected]>wrote: > Maya Remblai wrote: > > Garmin Kawaguichi wrote: > > > >> After reading that and seeing the produced work and published > >> Snowglobe 1.0, and knowing Second Life 2.0 RC is for the next weeks, > >> I've some questions : > >> > > That right there is the only thing that really got my attention. :P > > > > Seriously though, I'm wondering about these things myself. I wasn't in > > on the Snowglobe project from the start, so I actually didn't know that > > the original intent was to integrate Snowglobe's features with the main > > viewer. I'm wondering now if that's no longer the plan, since LL hasn't > > made any indication that Snowglobe is anything but a developer's toy. > > Sure they made it available to the general public, but other than that > > they haven't said what they plan to do with it, unless I missed > something. > > > > Maya > > The main intent was to both improve on the clumsy open-source patching > process and to safely experiment with allowing OS contributors to make > live changes to a part the code base. If this goes really well, then I'd > expect them to start allowing live commits even closer to the trunk. > > I wouldn't think about viewer 2.0 as a new product and Snowglobe as a > dead-end. Instead, I'd just look at 2.0 as the trunk diverging from > Snowglobe until (hopefully) merging back in a few months. Just how > that's going to happen without giving poor Merov a heart attack is > anyone's guess. > > -Melinda > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
