Instead, I am going to bring forward my thoughts on how it came to this. There’s definitely reasons why this week’s implosion occurred, and why it may not happen again. All these events are connected at a very high level.
But let’s start at the beginning.
We have a certain company, Linden Lab, who market a very unusual product: Second Life. This product is amazing, but it is also a very complex thing to deal with. In fact, it’s so complex that no one really knows how it should be set up.
The product, SL, is so complex that while it is amazing, relatively few people from the public are able to manage to successfully use it and stay using it. Everyone uses the standard viewer through which everyone experiences the product.
Advanced SL residents grow to want more from the viewer, as they’ve managed to learn many things about the environment, well beyond the basics. But they’re frustrated because they have only one option.
The Lab recognizes this need and responds by open sourcing the viewer code. They hope that the community will adopt the freely available viewer code to develop the advanced features that it wants, while leaving the Lab to put their limited resources against other problems and ventures.
The Lab focuses on growth. They believe that to attract more residents, they need to somehow simplify the experience so that it doesn’t scare people away. Indeed, the survival rate for new signups is abysmally low, perhaps as low as 1%. One of their simplification strategies is a less complex viewer. They begin a project to develop this new simplified viewer.
Several groups adopt the open sourced viewer code and begin tinkering. Some happen to be professional or near-professional developers, but others are not. Hackers and griefers also take a stab at making their own viewers - sometimes for nefarious purposes. A variety of viewer options emerge, all with differing features, support, release schedules and reliability. Some residents try them and begin to have opinions on their favorites, usually based on their particular needs.
One third party viewer (TPV), Emerald, becomes somewhat more popular than others, perhaps based on its frequent release of interesting and unusual features. This viewer is in fact the opposite of the Lab’s work: it’s a complex viewer including *more* features, not fewer. But these features are well-received by many long time residents in the community.
With popularity, more information comes to the surface about Emerald and the folks behind it. It turns out that several of them have known histories as griefers, some being suspended from SL in the past. It is further discovered that mysterious encrypted information is being sent from the viewer to Emerald’s server. The Emerald team does not reveal their real identities, thus making it very difficult to ascertain their level of responsibility.
Aside: it was at this point I concluded it was too risky (at least for me) to continue to use Emerald. Code written by anonymous former griefers, known to be sending unknown information to parts unknown, was simply too suspicious. I, and several others, deleted Emerald from our systems and changed our passwords in case they had been somehow recorded by Emerald. I feared an incident of some kind would occur at some point in the future and didn’t want to be part of it.
The Lab releases their new, simplified viewer: Viewer 2.0. Amidst fanfare, V2.0 included features intended to simplify things for new residents, but for existing residents it was too different, too simple and worse, beset with annoying bugs.
Viewer 2.0 becomes the default viewer - but because it doesn’t match resident’s needs, they flock to alternatives. Which one should they choose? Emerald was the most popular of the TPVs, and it’s usage grew significantly. Legitimate developers join the Emerald team, and it continued to be improved with additional features. Emerald gained many supporters as residents tune into its unique features.
Suddenly, there’s an incident.
The Emerald home screen was modified by one of its developers to perform an attack on a rival site, thus using the computers of all Emerald users for this activity. Poor judgement? Yes, indeed! Just as I had lost trust in Emerald months earlier, this incident resulted in a loss of trust by many former Emerald supporters. In fact, Linden Lab removed Emerald from its official list of TPVs.
The Emerald team breaks apart due to the incident and its aftermath, but reforms under new, hopefully more professional management. Time will tell if this is so, as trust is easy to lose but very hard to gain. Good luck to the new team!
But both problems still remain: existing residents need an advanced viewer and new residents need a basic, simplified viewer. Neither group is adequately served today, and Linden Lab needs to develop a strategy to address this critical issue before they will begin growing again.
virtual business, building virtual products and exploring the virtual world.
4 comments:
Oh PUH-LEASE, this line "The Emerald team does not reveal their real identities, thus making it very difficult to ascertain their level of responsibility." is complete BS. If you had a real name it would help you no better in ascertaining their responsibility. That's a complete trojan horse.
Even if real names somehow magically created accountability and responsibility (they don't, see, um, all of the rest of the world for reference), how prey tell would you verify that the "real name" they gave you was indeed their legal name?
It's all about trust. If I'm running code, ideally its from a public company who is subject to the laws of the land. In other words, if you have legal recourse against them, they are somewhat more trustworthy than say an individual. And an identified individual is more trustworthy than an anonymous individual. And an anonymous individual is more trustworthy than an anonymous individual who has a suspicious track record,etc. It's all relative. All I'm saying here is that for the Linden dollars going thru my account, I did not have sufficient trust in them to give them control by running their code.
Is one of the clearer posts i saw about all this issue with Emerald. As you... or many others, i was user of Emerald for long. That data incident you mention was not clear at all but i stopped using it because it was not as stable as i wanted and used a lot of memory.
Always supported Emerald as a resident action, as something made by a group of people, some of them friends who decided to leave the team with this last issue, but arrived a moment when was just... impossible to trust anymore.
The answer to Emerald is Imprudence. It has practically all of the same features and abilities of Emerald and the learning curve to adjust from one to the other is relatively small.
It also is the opposite of the Emerald situation in that the project is 100% transparent, right down to the development team.
Am I looking to pour fuel on the fire against Emerald? NO. I like Emerald but felt not only the wavering trust some time ago, but also that it feels bloated to me. A lot of code in there that I'd apparently not used by residents, which makes me wonder if there are "Easter eggs" available to the debs and their friends.
In my search for a decent replacement to Emerald, I found Imprudence, which is light weight and snappy, blazing fast performance compared to Emerald by a very long shot, and fully transparent... It is Emerald by another name and project.
Just my too sense.
Post a Comment