When words collide

I try not to engage or comment on disputes between people, but in this case I’ll make a small exception, as the faux pas is too good not to point out.

As I’ve mentioned, LordGregGreg departed Emerald over the weekend, and in doing so much of trust people have for the Viewer being kept “on-the-rails” followed him through the door.

His reasons for leaving were pretty clearly stated, and have been widely reported by supporters of Emerald and snipers alike.

Of course, there will always be two sides to every story – and then there is the truth, as the old cliche goes. But LordGregGreg – as many have stated – has never been anything other than straight and honest with people. As his blog shows, he’s been a consistent voice advocating people’s right to privacy and some security in what they are receiving through the Viewer or where the Viewer is redirecting them. He also has a deep technical understanding of the Viewer. For this reason, it is disappointing to see such a tawdry, accusative post appear on the Modular System’s blog regarding his departure.

It’s hard to see how raising legitimate concerns over the possible capture and/or transmission of private information that is not relevant to the user’s SL experience in terms of what they see or or and what the Viewer needs to be able to do in order for them to do so is an act intended to “deliberately try to bring the Team’s reputation into disrepute.” To try and gloss over the matter does little to redeem Modular Systems in the eyes of many.

That said, I could not help by smile and laugh at the closing attempt to dismiss LGG’s contributions to the project: Alas, part of being a success is having detractors, however we wish him well on his next legitimate venture.

“Legitimate venture”? Phox / Fractured / whoever wrote this, I suggest you go back and re-read that line carefully. You may think you’re very cleverly casting further aspersions on Lord GregGreg’s character; but that’s the danger when trying to engage in clever wordplay: one is all to often hoist by one’s own petard as one’s words collide – they have a habit of being read in ways other than originally intended.

I mean, are you really admitting the project LGG has just left – Emerald – is in fact an illegitimate venture?  Perhaps we should let the jury decide.

Out with the globe, in with the storm

Note: Following this post being published, Esbee Linden made a formal blog on the subject on August 17th

In his address at SLCC 2010, Philip made mention of “standardising” the viewer platform. At the time I was curious as to what this might mean and asked a speculative question or two. Later, during SLCC 2010, Q Linden (whom I hope makes a full recovery from his stroke) and others gave more insight into what is going to be happening, and Oz Linden posted an announcement on the opensource dev list (thanks to Argent Stonecutter for the link).

Q’s opening of the SLCC presentation was somewhat enlightening, in that it confirmed many people’s views that Viewer 2.x proceeded along a development path that was simply far too rapid. In fact he candidly admits that it was developed and rolled out to meet a given schedule, rather than when it was “ready” (in November, for example, a meeting was held in which the “to do” list of outstanding work on the Viewer was cut down to a list of things that could be done in the remaining time frame prior to the release of the Viewer.

He also admits that Linden Lab erred when preparing the ground for Viewer 2, in that they didn’t create sufficient use cases to reflect how the Viewer is actually used in-world (that LL needed to “invent” user types in order to build the use cases in the first place also surprised me. After all, what are we out here, if not users?). The upshot of this is an admission that the overall capabilities of Viewer 2 are too narrowly focused.

This may sound like a “well, duh!” statement – but I think it fair to say that such an admission from the development team is somewhat refreshing. It’s not often the Lab or its employees own up to mistakes, and Q’s comments do add up to a strong admission of  having erred, and a hint that the lesson has been learned internally, “For marketing reasons we felt we wanted to keep it secret and we wanted to release it in a kind-of ‘ta-da!’…I think you won’t be seeing any more of that sort of behaviour from us any more! Yes, I hear the applause, thank you!”

Following this, Esbee went over the new methodology for Viewer development – Project Snowstorm, which has the core aim of rapid, effective deployment of new features and functionality. Essentially, and as hinted at by Philip, this will be achieved through meeting three goals:

  • Weekly, visible progress on the Viewer – which not so much is focused on weekly releases per se (although that is something Philip indicated he’d like to see), but more a case of making the development process more visible too all, including users being able to attend development meetings
  • Improving the user experience – hitting Philip’s requirements of Fast, Easy, Fun (a slogan I *still* loathe, but there you go)
  • Revitalising the open-source community

It is this last point that is the most interesting and – if carried through  – marks a radical change in Viewer development; one that would seem to have many potential benefits – and not just for Linden Lab.

The core of this new approach is that Viewer development will be somewhat streamlined, with LL themselves working on specific elements of the Viewer while leaving things open so that third-party developers can engage directly with the LL team and take on development of a given aspect or function within the Viewer, and developers with existing fixes or functions that could benefit the Viewer can deposit their work with the team for potential integration into the Viewer.

This effectively means the end of Snowglobe, the open source “version” of the Viewer code.  To quote Oz Linden, “The main Linden Viewer is now completely open source…the source code is available on a public repository…NOW!” What is more is that this repository is to be the central “integration repository” where all code from Linden Labs will go prior to integration into the Viewer.

Alongside of this is the re-licensing of the code from GPL to LGPL – which, if I am understanding things correctly, means that it will be both easier to incorporate the Viewer code into other Viewers (I assume those that can be used on OSGrids and the like) and – particularly from LL’s point of view – will make the licensing of the code for use in “closed” third-party Viewers significantly easier, potentially attracting other professional organisations towards developing their own Viewer systems without the “stigma” of being associated with open source code. Again, given LL’s stated desire to drive SL onto more mobile platforms – tools such as the iPhone, Droid, the iPad, etc. – this would seem to be a good move, as it will allow third-party organisations with the expertise LL lacks to develop the kind of functionality such tools will require if people are to use to them to access SL and use it for more than just chat and IM.

It’s not just developers who have the chance to be more directly engaged with Viewer development either. AS Esbee said, users will be able to get involved as well: iterative releases will be available bi-weekly or us to use and feed back upon, and even daily releases, or “project releases” covering specific features under development will be made available and user feedback encouraged.

From a non-technical perspective, this does seem to be a logical approach, and in some respects, it is a shame that, when they opened the Viewer code to the community, LL didn’t show foresight and put these measures in place then. Of course, the devil will be in the details – and there is much that will serve as either proof of the pudding or still needs to be addressed  / clarified. In listening to the presentation, a number of points occurred to me, some of which were echoed by others in the Q&A session.

One issue that springs to mind is who will, in the final analysis, determine what is “right” for integration into the Viewer, and will other agendas overrule the core goals – such as making SL Fast, Easy, Fun? “Linden knows best” has been very much a part of the Lab’s culture and has been seen time and again, particularly with the arbitrary closure of JIRAs or the turning of a deaf ear to valid user requests.  With the best will in the world, cultural behaviour is the hardest thing to fix in an organisation.

An extension of this concern comes down to user input actually being heard and acted upon. Q openly admitted at the start of the presentation that LL erred with Viewer 2 in not creating enough user cases on which to model the viewer. Now they seem to be swinging to the opposition end of the pendulum swing: seeking too much user input. There are – as Q and Esbee acknowledge – many diverse uses for SL, and as such diverse sets of users have diverse needs. Some are going to apposite in their aims, others opposite. How are filters going to be applied to stop all these calls simply swamping Snowstorm with the result that the individual internal dev teams beyond them simply cherry-pick or (again) turn a deaf ear?

So where does this leave the current crop of TPVs? Oz was pretty unequivocal on the matter: the Viewer 1 code base will not be developed any further by Linden Lab (Q also touched on the need to depreciate 1.23 in the future, simply due to security issues). Therefore, with the Viewer 2 code base becoming publicly accessible, the view seems to be that TPVs will be encouraged to continue – as well as give input to the new project – but will be expected to migrate to the Viewer 2 code base.  Certainly, there doesn’t seem a move on hand to proactively “shut down”  TPV development, but it is going to be interesting to see how this moves forward and who engages through Snowstorm as is intended, and who simply continue to work on their own Viewers utilising the now-available Viewer 2 code.

Overall, this move strikes me as positive. *IF* LL can carry through on this with the necessary internal cultural changes and if we all, developers and interested residents alike, engage with Snowstorm and LL constructively, positively and openly on our own part, then there is no reason why this project should give birth to something very worthwhile and which benefits us all.