From a glitch to a storm

In recent days the apparent inability of Linden Lab to fix a small but rapidly growing bug in the SL Marketplace has led to real anger and frustration to building in the Secondlife Merchant Community. Recent posts have begun to promote the idea that Linden Lab simply do not have the resources to fix the issue and are relying to a dangerous degree on “self-help” solutions from the SL userbase.

There is a burgeoning body of evidence (mostly circumstantial admittedly) to suggest that this state of affairs is, in fact, true. Recent posts by Linden Lab in the form of “Commerce Team Linden” and Dakota Linden have been perfunctory to the point of being offensive.

I read a blog post which I am going to paste unapologetically which made me realise just how far Linden Lab are pushing their luck on this issue. I do not say that I agree with all the points made here, but it is clear that if this matter is not cleared up soon, Linden Lab are in for a nasty surprise.

For more direct information Go To:
http://tribes.tribe.net/secondlifemarketplaceproductsearch/thread/79e523ce-4ba5-4e67-9e59-b15bc68e4444#f141bacf-b435-4c9f-8d52-d2faecd7e3ab

“Service agreements protect companies from having to pay for losses due to honest mistakes and unforeseeable technical failures.
Service agreements do not protect companies from having to pay for losses due to gross wilful negligence or intentionally harmful acts.
LL’s service agreement would protect them from having to pay for accidents.
LL’s service agreement does not protect them from pretending to have accidents or pretending that technical failures are unforeseeable.
So let’s consider how accidental and unforeseeable the current collection of problems can possibly be.
1) It’s possible that it’s an accident that LL chose to secretly deploy “bugged” code on the day of the year on which it would potentiate the maximum damage to merchant confidence, 13 September.
Given that 16 September represents the peak day for birthdays, the maximum yield for a birthday-item-related listing enhancement of 7 days would be applied on 13 September. Thus, as a same-day bork (optimum for gift disruption), 13 September maximally destroys merchant utility for such an enhancement, and likely also affects the maximum number of merchants who buy enhancements for birthday items.
But birthdays are just the tip of the iceberg. Borking Halloween in December is obviously less effective than borking Christmas in October. But the build-up of merchant activity for 4th quarter sales promotions begins earlier. Items must be listed before they can be promoted, so, in addition to any other 4th-quarter items also being listed or promoted early, Halloween items will tend to start to be listed before the first 30-day enhancement period, which puts the early vulnerability date into September.
13 September would have borked a larger part of the 4th quarter had the rest of DD been deployed on that date (which it somewhat did in any case, as seen from the fact that the quarterly report has been withheld, and can’t be any better than the bad one before it). Specifically borking the 13th optimizes the additional destruction of birthday enhancements by producing unannounced same-day inteference with gift item processing during a 7-day peak period, corresponding to the length of the shortest enhancement, best fit to this annual peak.
Thus, 13 September is the most dangerous day of the year to risk borking the market.
The probability that it was chosen merely coincidentally approaches 1 in 365.
2) It’s possible that it’s an accident that LL chose the 2nd most destructive day to re-deploy the 13 September borks and to continue with the borking from there, (as if) in spite of the fact that they were seeing an effective repeat of the previous incident right from the start (which even they acknowledged by offering a comissions holiday later).

After an incomplete, but numerically effective bork of the whole 4th quarter, LL waited until 14 February to apply the next secret bugged deployment. Not the 13th. Not the 15th. As with the birthday peak, 14 February is a major date for gift processing. And, as with the birthday peak bork, the deployment was unannunced, in a repeat violation of Brooke’s earlier statement that DD code would not be deployed unannunced.
This incident borked St Patrick’s day much as 13 September borked Halloween, and set the stage for the more extended borking of Easter on 21 March, just as merchants were done counting their combined losses for 14 February and 17 March, much as the additional bork not provided in the 4th quarter would have done to various 4th-quarter holidays. In fact, the borking of the 14xxxxx cluster, a cluster of items listed essentially a year before the 13 September bork was clearly to have been deployed earlier, had the 13 September deployments been allowed to continue; thus “coincidentally” borking 4th-quarter items from both 2010 and 2011 at essentially the same time. And this, oddly, just at the same time of year when borking them would have done the most damage to merchant confidence.
Even without the borking of the 14xxxxx cluster, 14 February is the 2nd most dangerous day to deploy “bugged” marketplace code. Look at any other day of the calendar and consider what I describe, and it becomes clear that 14 February is second only to 13 September in terms of these dangers.

The probability that it was chosen merely coincidentally approaches 1 in 364.
The combined probability of these dates being chosen by coincidence is 1 in 365×364.
That is, it approaches: 1 in 132860.
To put it another way: this is a set of two bad date selection decisions we should expect such a company to make about once in every 132,860 calendar years, given no criteria at all.
Or, to put it another way: if LL had 66,429 employees and they were EACH asked to come up with one pair of 2 possible deployment dates for new marketplace code, probably NONE of them would come up with a more dangerous pair of dates.

So you can probably just print this and take it to your lawyer right now.
But why not consider the rest of the coincidences?

A) Transaction errors uniformly favor LL, not merchants or customers.

B) The specific timing of the listing of the 14xxxxx cluster, and the time at which the bork would have occurred, had it been allowed to proceed.

C) A mascot for DD which, based on height, color, species, markings, and behavior is a violation of the Care Bears trademark for Oopsy Bear. Why a bear? Why green? Why such a precise height? Etc.

D) “Other”. There’s plenty of “other”. Make your own list.

And not unforeseen. It was largeley foreseen and stated as foreseen on the Second Life Merchants Forum. Just take a look.
Most of all, that against which the service agreement does not protect LL is accountability for obvious fraud, expecially in terms fo fraudulently inducing people to participate in throwing their money away, regardless of where it goes or why.

(Summary…)

The Motive: get merchants to rent more land, increasing total LL revenues otherwise “lost” to marketing and sales not in-world.

The Means: destroy merchant confidence in sales not in-world, and possibly shut down all other options by pretending to fail at improving them.

The Opportunity: whoever suggested the dates 12 September and 14 February had the opportunity.

posted by:[removed (by me)]”

Now, that might be a paranoid rant to some, but it is quite logically put together and while it might smack of Conspiracy theorism, the alternative explanation of sheer incompetence is just as disturbing.
Someone, somewhere in the upper echelons of Linden Laboratories or Linden Research needs to get a grip of this situation before the US legal system gets involved. It is clear that this is one assault on The Lab that cannot be defused by hiding behind Secondlife’s ToS.

~ by Ayesha Askham-Ezvalt on April 15, 2012.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: