[sldev] What is the real future of Snowglobe?

[Philippe (Merov) Bossut]

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 <melinda at superliminal.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091026/18020589/attachment.htm