The title won’t make any sense for native English speakers, who have the equivalent saying: “tempest in a tea pot”. The meaning is the same: “making a fuss about nothing important”.
But sometimes we fail to see what is important and what is not. I’d like to invite you to view Linden Lab’s formal announcement of Project Snowstorm, which I mentioned on an earlier article:
http://www.ustream.tv/recorded/8948405
Why Project Snowstorm?
Turning the clock back a few years, most people don’t remember when Philip announced that the Second Life Viewer would become open source. It was the first good news of the year of 2007, and actually it was quite unexpected. LL had been tweaking the code to be able to release it as open source since mid-2005, and, considering that so many Linden projects get abandoned, people were slowly losing their hope this would ever come out.
The reception was mixed, of course. Prokofy Neva, for instance, as SL’s most vocal anti-open-source attacker, has always been against it for ideological reasons. The libopenmetaverse team of course was excited, since it meant actually confirming the most tricky and murky aspects of the Second Life Protocol, which lead to a big improvement in how ‘bots could be developed to mimic all functionality in the viewer without actually requiring a viewer. And the OpenSimulator project got a huge boost from the work done by the libopenmetaverse team, now they had a library that they could work with.
Viewer developers received the news with less excitement. The code base is huge, very badly documented, and very tricky to follow. Bits of code are in it that nobody — not even at the ‘Lab! — knew what they do, except that by removing them, the viewer would stop working (for example, nobody really remembers how the appearance setting sliders actually work). Lots of unfinished and never released projects are still bundled with the viewer code, but they remain unfinished. So, actually patching the code and fixing bugs — or adding new features — took some time, although brave Nicholaz was the first doing so.
It also quickly became obvious that LL would never patch back their own code in due time, which became a major source of frustration for the developers. The JIRA is full of patches that would fix most of the major glitches in SL; some of them are over 2 years old, and were never considered by Linden Lab. Some are just a single line of code.
Developers thus gave up on Linden Lab, and just developed their own viewers instead, the most popular of which is clearly Emerald. I’ll skip the recent drama around Emerald for now, because things are quickly getting out of hand at Modular Systems, and just patiently wait for that storm to pass, too. The point is that non-LL development mostly meant abandoning LL’s own distribution channels for the viewers and just start a project with all of LL’s code and add some fixes and features to it.
In three years, nobody has yet a fully-functional viewer that replicates all functions of the LL viewer but doesn’t use a single line of LL’s code, even though all the source code is available. Instead, we have a plethora of viewers, all sharing over 99.9% of the code, and just having a few extra bits — which make all the difference. While some features have slowly migrated to all third-party viewers, few, if any, were ever implemented on LL’s own “main” viewer.
Philip’s response to that was Snowglobe, back when he left the role of CEO. His idea is that Snowglobe could be a way to integrate all those developers in a common viewer which would be developed in parallel to the main viewer. As soon as a few features would be successfully deployed in Snowglobe, they could be migrated back to the main trunk, where they would go through some quality assurance testing, and released as part of the main viewer. HTTP texture download are a good example, as well as the new rendering engine which ultimately was released as SL Viewer 2.0.
Still, this approach didn’t work that well. Independent developers had a hard time to add features and patches to Snowglobe, although the process was apparently a bit more easy. While Snowglobe enjoys the status of being one of the fastest viewers ever, most of the independently contributed code never made it to the main viewer. In a sense, Snowglobe was the “playground” of Linden Lab, where they could implement nifty ideas they had, and release it to a wider audience that way, without compromising the main viewer.
Over the years, however, the strategy started to break apart. Absolutely new concepts (like the now-abandoned Open Grid Protocol) were implemented on specially-designed “Alpha” or “Beta” Viewers, which were little upgraded afterwards. A few features implemented on those might have trickled down to Snowglobe, but never made it to the main viewer. Internally, for example, LL has been experimenting with meshes for a long time — at least some 18 months — but not a single line of that code was previewed on Snowglobe or any other Linden viewer.
Most Linden developers started their job downloading the latest code of the main viewer, and just tweaking it to suit the purposes of their work in progress. That’s how Ventrella made the amazing avatar puppeteering videos years ago; Babbage Linden also used to have his own version of the viewer for his complex Mono-related projects (who knows, perhaps he even had a working C# compiler instead of LSL inside his viewer…). And of course we all have seen videos showing shadows, years before they were released, as well as fully-working meshes. All these projects exist separately from the main codebase. Since they never were integrated back into the main viewer code, they quickly become obsolete. Then the people behind those projects get fired, and LL is left with code that is impossible to port back on the latest batch of viewers. All the work gets wasted. Over, and over, and over again.
We really don’t know how many different and mutually incompatible viewers exist at Linden Lab these days. But Philip was quite happy to reinforce during the SLCC — twice! — that they have 175 developers in 15+ teams working for Linden Lab. I can very well imagine that there are, at least, 15 active internal viewers, all of them running code that is incompatible with each other — and with the main viewer. A few of those projects might eventually be integrated into the main code after a year or two. Most will be dropped.
Clearly this has to be stopped. Thus, well, Project Snowstorm. Philip reinforced on the above video what its ultimate purpose is: having a single code base for all projects at Linden Lab. Using an unified model, all LL developers will contribute to that code, and using versioning tools, they will be able to fork a project to work on a specific area, but easily integrate the changes back on the main viewer. In fact, Philip told us that there would be no more separation between the “main viewer” and “development versions”. There will be just one codebase. Every now and then, when LL “feels” that the codebase is stable, it becomes automatically the “main viewer”.
Independent developers can also see their patches actually going somewhere. Of course LL isn’t relinquishing control. The whole purpose of the Scrum software engineering methodology is to make sure the software complies with LL’s wishes and roadmaps, while still allowing external participants to work on things. The good news is that even if those contributed patches are not “approved for release”, they will not get lost. LL developers, discussing what goes into the viewer and what stays out of it, can suddenly decide that a patch developed a few generations ago might be allowed to be pulled back in. The underlying tools that support the versioning system allow this to happen with a minimum of pain and fuss.
Now, I personally am not a big fan of agile computing as a methodology. I’m happy to discuss the reasons why I prefer a more goal-oriented project where developers are, well, employees following a roadmap, and not teams of independent, creative people that just happen to spread themselves thin in all directions, and management just hopes that some of those things might actually become useful. Still, agile computing is the fashionable software development methodology of the day, and Scrum is just one of the possible solutions for that. The good news for us residents is that at the very least we get overall roadmaps, and bi-weekly goals that have to be achieved by LL’s Snowstorm Team. That’s good, we can watch the progress, and be happy that LL is actually doing something. We can also add requests for features and bug fixes, and see them being prioritised by LL. That’s all good. The best news, however, is that all the other teams will have to contribute their code to a single source.
From now on, there will be no “lost code” at Linden Lab. And I personally think that this is the greatest thing about Project Snowstorm. The ability for the community to contribute code to it is secondary. Nevertheless, third-party viewer developers will very likely fork code off Snowstorm, meaning that as soon as new features are developed by LL, TPVs can also immediately implement them with a single recompile. With proper versioning management, this would mean that a TPV based on Snowstorm could have meshes an hour or so (well, the time it takes for a full compile!) after LL releases them — plus all the extra features they have developed for their particular flavour of TPV.
The huge differences in performance between the TPVs come from the original code base they used for their viewers. Imprudence, for instance, uses Snowglobe 1.X to achieve extreme performance; others prefer to use the “main viewer” codebase, and are, at best, as fast as SL 1.23.
There is, however, a catch. Project Snowstorm is obviously based on the 2.X viewer code, since that’s the one allowing this kind of methodology to be applied. Why? Because it’s modular. The problem is that TPV developers share with all the other residents the utter hate of the SL 2.X user interface, and they are not yet familiar enough with the code to simply remove the UI and use a new one. In fact, nobody is playing around with the UI — under 1.X, it’s too tightly integrated with the code to be able to completely remove it, and 2.X is “too new”. The few people I know that are playing with the 2.X UI are Kirsten and Katharine Barry, but they’re just adding functionality and minimising the impact of the worst design features, but not eliminating them and replacing them by something else.
With this announcement, LL has also made clear that they would stop development of the 1.X codebase. We don’t know what that means for Snowglobe 1.5, which was announced as the next iteration, but I would bet that all of it will be dropped, very soon.
Financially, this is LL’s best choice. No company can afford to waste all their time with gazillions of incompatible “internal” versions. 2.X’s major problem is just the user interface, all the rest is far more streamlined modular code — it’s pointless to keep hammering at the old 1.X code to improve it. It would be like Microsoft continuing the effort of bringing more modern features to Windows XP (Second Life’s 1.X code base is probably as old as Windows XP), even though Windows XP is still the favourite version of Microsoft’s operating system. Even though Microsoft has no choice but to continue to support Windows XP (and even 98…) with security patches and some extra, new functionality, Linden Lab has far less developer resources, and, although with some delay, it seems clear that they will stop their support to anything before 2.0. Financially, it’s simply nonsense to do otherwise.
Of course, in the mean time, they’re stuck with a user interface that only 10-12% of all residents actually like. That’s not good enough. Some work is already developed on Project Snowstorm to at least make the sidebar more bearable, but that’s just the start — the whole Build interface and the way profiles and groups are now handled has to go through several iterations until a majority of users is happy with it.
Meanwhile, I wonder if some TPV doesn’t simply scrap the 2.X UI, develops a 1.X “clone”, but implements it on top of the 2.X code. That would be the wisest approach for supporting a “retro” look which would please a large number of residents. Unfortunately, as said, in the past three years of the open source client, nobody ever managed to completely replace the interface with something new… and it’s not likely that even under 2.X, which is allegedly so much easier to change, such a dramatic move will come quickly.
