Re-Emergence

Following all the shenanigans with Emerald, including the complete break in any credibility the Modular System’s group had, it is good to see that LordGregGreg Back has not given up entirely.

He’s now offering Emergence – a Viewer based solely on the last “safe” (as in not wee-wee’d all over by others in the Emerald camp) code for Emerald. I’ve downloaded it, and so far I’ve found it to be a more than acceptable replacement for Emerald, and one that – on the machine I’m currently using while away on vacation – is at least as fast as Emerald .1636,the last version of Emerald I ever installed.

I’ll probably take time to write-up more when I’m back home – there are some nice levels of transparency in things like the installer (at least to my uneducated eyes), and LGG has, I think, tweaked a couple of other functions.

For now, if you want to continued running SL in an Emerald form, but don’t want to have to face the trust issues – why not give LGG’s Emergence a try…?

Fractured credibility

I am Fractured Crystal. I have a long history of doing stupid things… so begins the latest in a round of Emerald-related blog posts. This is nothing new, Emerald has been the subject of heated blogging since its inception – with just about all of the allegations relating to its malicious intent remaining a matter of – well, malicious intent on the part of many of those making the various claims against it.

All this changed, however, when none other than LordGregGreg Back (LGG) went on record citing concerns about what was happening within the Emerald “team” – with people’s actions not exactly measuring up to their words.

The response from Emerald was the usual dismissive rebuttal – albeit thinly coating a tawdry attempt to suggest it was LGG himself who was at fault. And so the house of cards began to fall, with evidence coming to light that Emerald – and by extension, each and every one of us who has used Emerald has, utterly unwittingly – been the cause of at least one Denial of Service attack on another user.

While efforts were made to deflect / play down the situation – particularly through various postings within the SL forums, investigations quickly showed that the allegations relating to the DoSS to appear to accurate – so much so that Linden Lab issued a statement on Emerald, both in the official blog, and via e-mail to users.

Modular Systems have responded to the situation, both through Fractured Crystal’s comments and another self-serving blog posting.

I use the term “self-serving” deliberately – because while both posts have the veneer of apology, both are couched in terms of self-justification (particularly the latter of the two links above), in which the underlying tone seems to be, “Me bad but it’s really OK, as he bad to.”

Well sorry, this just isn’t good enough; it’s akin to saying, “Yes, I mugged him, but it’s really OK as he’s mugged others.” In short, it is vigilantism.

Fractured Crystal’s “apology” is side-barred with the old truism power corrupts; absolute power corrupts absolutely. And while the tag may have been offered as a means of excusing his actions, the fact now remains that whatever the outcome of discussions between Modular Systems and Linden Lab, the former’s reputation is now not so much tarnished as it is fractured. What’s more, it will remain so for as long as this individual and those who share his world view remain involved in the “team” in any capacity whatsoever. For those of us what have had our trust so casually thrown aside, the time has come to move elsewhere in order to access Secondlife – be it Viewer 2, Viewer1.23.5 or any of the Viewers still credible part of LL’s Third Party Viewer Policy.

Naming and displaying

Hot on the heels of Philip Rosedale’s appearance at SLCC, Jack Linden brings us further news on the new Display Names option Philip mentioned.

On the whole, I find this a very good move; that people have been forced to select a predetermined last name for Second life – and have been unable to do anything about it (or indeed their first name, should they subsequently wish) – has been something of an annoyance. It also has to be said things like the lack of unicode capability with names, or the inability of partnered couples to share a common last name has caused endless grumbles. Similarly, and while I don’t engage in the same myself, I’m sure those that like to be Klingons, Romulans or orcs or elves  – or the whole rainbow of creatures / races / breeds that live within Second Life will welcome the ability to be more than just Joe Smith with a fancy helmet and a big sword / blaster gun / whatever.

Even so, despite the positives, it’s interesting LL have been careful to lay out the justification for the new (Viewer 2 based) feature alongside the announcement – almost as if they’re anticipating a backlash at the move and want to be able to point fingers back at the community as to why it has been done.

Good as it potentially is, it is not without concerns – many of which are raised in the comments that follow the announcement.

From a personal perspective, I’d question the “convenience” of some aspects of the new system, such as the find that Display Names will take precedence over “user names” (your current avatar name) in things like Friends /Contacts lists. Given that the user name is the constant that underpins an Avatar’s identity, I would have thought it more sensible not to change functionality so that Display Names are show in preference. Those who find a lot of their Friends and Contacts using this feature – even with changes limited to once a week – are going to find trawling through their lists to find if Joe Smith is now H’uspank’l chithulyTa, Sorovin Paladin, Howling Vishniac or Amy Anne Martha Fleetwood this week somewhat tiresome.

The idea that IMs will be logged under Display Names is similarly questionable. Business owners rely on IMs to trace conversations, record information and feedback about / from customers, etc. Right now all IM exchanges with a customer tend to end up in the same .TXT file – so over time it is easy to build up a history of correspondence with repeat customers, information that can be used in a variety of useful ways. With Display Names things could get very muddled. Given the transient nature of Display Names, some business owners potentially have a nice little task of ascertaining whom their most recent conversation was with (or who actually sent an IM that went to e-mail while they were offline), then having to prat around copying the info to the relevant IM log.

I’m not convinced by all of the “con” arguments put forward in the responses to the announcement; those familiar with Second Life and the antics a minority like to get up to will inevitably make sure that the option to display “user names” beneath Display Names is checked at all times. However, the potential for bilking the unwary does increase somewhat – though not enough to make this a no-go idea.

That said, I do find it objectionable that anyone can use my name as a display name. I’ve invested time and effort into my Second Life, and I regard “Inara Pey” very much as a part of my identity (to the point I now use the name outside of SL in the likes of Blue Mars and elsewhere); ergo, I’d be somewhat affronted at the thought of someone using it because they think it “cute” – leave alone creating any mischief while doing so.

Torley and others do their best to field questions raised in the commentary (although Amanda’s admonishment to Anne O’Toole on the subject of the use of all lower case in the “user name” is more than a little patronising), but it is interesting to note that there is a continued silence around the subject of scripted tools that log resident names.

These – such as security orbs – rely on a specific name being entered by an operator. It would appear that those maintaining such tools – say for access control to areas, etc., could find themselves constantly updating things or issuing “rules” users aren’t going to find popular.

It is going to be interesting to see how the “beta” period goes with the new feature – and how many will actually recognise / see it, given the size of the Viewer 2 user base compared with the 1.23.5 user base (where Display Names won’t be visible).  This in itself may cause problems where feedback is concerned, as issues such as those raised here may be simply discounted by LL purely because a “minority” seem to find them a problem.

Overall, Display Names add a flexibility to Second Life that has been missing for far too long; nevertheless it is not something that should be rolled out with a bang and accepted as “working”. LL have put a lot of emphasis on listening to feedback going forward; one hope that they’ve already started listening now and will work with us to make sure that Display Names is the cool feature they predict and we’ve wanted to see.

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.

Grid “merger”: precipitating the identity link?

I’ve been bouncing around looking at reactions to the announced “grid merger” in SL – or more correctly, allowing 16 and 17 year-olds onto the Main grid – both here and elsewhere. Specifically, I’ve been looking at people’s thoughts on the potential additional risks such a move forces adult users of Second Life to face.

In the thread linked to above, Cabbage Acanthus and Derek Torvalar hit on two of my major concerns respectively, the matter of public perception and the legal ramifications people might face as a result in-world activities (the latter of which will clearly vary depending on one’s nation of residence), or which might equally cause panic / confusion.

In the same thread, Carole Franizzi touches on the core element of both of these concerns: that of identity. As it stands, we simply have absolutely no way of vetting for ourselves that whoever we are dealing with in Second Life are who they claim to be (i.e. of a given gender and over a certain age).

Until now, this hasn’t been an issue, and when LL themselves have tried to slide things towards a more direct linking of SL and RL identities, there has been an enormous – and in some ways, justified – push back against such moves. But allowing minors into the Main grid clearly changes things; particularly as much of the direct legal onus for verifying who we are dealing with on-line fall on each of us individually – as Derek’s quote from Canadian law illustrates.

It is true that since Wallace’s faux pas on the subject of such linking, LL have been careful to caveat any potential moves towards it as being something users will be able to at least opt out of, and Mark Kingdon went out of his way to expressly state as much on numerous occasions.

But will this now remain the case? Could it be that as minors are allowed into the Main grid LL will find the adult population (and by that term, I mean all of us using SL, rather than any given segment of the community)  potentially more willing to see RL information being displayed alongside SL information, if it helps verify people are indeed who they say they are?

I’m not for a moment suggesting this is in any way why the “merger” is happening – but one has to admit, in looking at the broader implications, it could have some “interesting” knock-on effects, intended or not.