The Battle for the Desktop Begins!

So what does this all mean for LL? First, you have to realise that all those viewers together just have “a few thousands” of users. Most aren’t aware they exist. On the Macintosh Group, a recent conversation showed that almost everybody, with a handful of exceptions, never downloaded a non-LL viewer before (although these days, most have already been ported to Mac OS X). Rumours are spread that “the alternate viewers are so good because they send your credit card info and passwords to third parties”, and so they’re not used. Other rumours say that “I had a friend who had a third-party viewer and was promptly banned by LL” (in reality, the “friend” was using CopyBot to steal content and that’s why LL banned them — CopyBot is, for all purposes, a third-party viewer too). And finally, many people come from other virtual worlds, where non-official viewers are illegal and their creators pursued in courts of law. The concept that LL has created (and encouraged!) an open source community around the viewer code is totally alien to them and they can’t believe it’s true. So, with little publicity, it means that the absolute majority of all SL users never tried an alternate viewer, not even one from LL (ie. the release candidates, or the “beta” viewers).

This also means a very limited number of residents actually testing them, and, in general, most of them are technologically inclined. At the very least, they know how to go to the Preferences tab to tweak their settings — pretty much what LL expected users to do in 2002-2004, and that’s why Second Life, unlike most of the competing platforms, has so many tweaking options available. However, the vast majority of the residents don’t know how to do that. Half of them don’t even know how to read the Preferences tab, because they don’t speak English and might not have a translated version of the SL client.

So this means that the number of people effectively testing the alternate viewers is very small — about the same number of residents that existed in Second Life in mid-2004 or so. From LL’s point of view, it’s probably too small a test base to validate that all those patches are actually correctly applied.

Because that’s the only reason I can give for LL to repeatedly ignoring what others are doing to their code. After all, the major reason for releasing the code as open source was to make sure that they’d get free labour in reveiwing and fixing bugs. Which the many volunteers promptly did. But LL is reluctant to accept their code. Why?

The only answer I have is “because it’s not tested enough” — although it has been tested by several thousands of residents. Way more people than LL has in their internal quality assurance team, and very likely way more people that actually use the release candidates.

So… there is obviously a question of internal policy. In my mind, software requires exhaustive testing in the field, something that I believe to share with LL. Two techies running a series of tests on an empty sim will never uncover the kind of bugs that two clueless residents will find on the laggiest sim on the grid, surrounded by avatars and 2.2 billions of items on LL’s asset servers. Nothing like a “real experience” to figure out what’s wrong. But… the “real experience” presumes that bugs are fixed, patches are applied, and users are using the client, not engineers in a lab crossing items on a checklist!

I’d certainly encourage LL to review their internal processes, and at least for their Release Candidate series, be bold and experimenting, fully embrace the cartloads of bug fixes and patches that have been submitted in the past two years or so, and forget their “fears” about “unproperly tested code”. Open source software grows by testing it in the field. “Code fast, release often” is the old mantra that applies to this.

LL can, of course, have three approaches side-by-side. One will focus on the “main SLviewer” — an old, always-obsolete bit of code that nevertheless is reliable enough and that doesn’t change much over the years, and which gets a new release every year or two. That’s the one that ought to be the “Reliability Client” — no features, just field-tested bug fixes, nothing fancy. In parallel, develop the much-announced “SL Lite” client with all major features stripped down and as easy to use as IMVU. That’s also a good approach — that “SL Lite” might even get less releases. Since it probably won’t even have building tools or the scripting editor, it can be made so minimalistic that it’ll run on any computer. Graphics will be ugly, but that’s ok — so far as you can login and move around, that’s all it needs to do.

And then, on the other side of the Lab, have the team developing fast and furiously the bleeding edge of Second Life. Work to incorporate all those developments from the alternate viewers — plugins, performance, lighting effects, features, a detached UI — and release it as a single, LL-branded viewer. Do it often. Forget quality assurance tests — you can always do them once it’s time to launch an official “stable” release, but, during that time, experiment a lot. Releasing a new version every week ought to be the goal — LL managed to do that in 2005/6, with a much reduced number of developers in their teams, so there is no reason they cannot do the same. The trick is, of course, to do the “code hack and slashing” only on the Release Candidates. Then, after a year or so, push the code to the quality assurance team, and let them test it for half a year — and if it meets with their approval, release a new “stable” version. In the mean time, of course, once the code is “frozen” for evaluation by the QA team, development can start instantly on the next batch of release candidates. There is no need to wait!

My issue at this stage is not with LL being totally at odds with that approach. After all, if the team behind the Release Candidates are not allowed to work that way, volunteer residents will — and this means that “unfinished” code and bugs and performance patches will be handled by the open source community, not by LL. But it’s still a pity. Why should millions of SL residents be deprived of the pleasures of enjoying superfast performance and all sort of nifty tricks that way?

Unless, of course, it has all to do with the Big Announcement that is due by the end of the month, which will address the SL client and the open source development efforts behind it, but which sadly nobody is willing to even give us a clue about what it will be about…

Print PDF