XStreet and me - a personal analysis

I have not yet made my mind up on the upcoming XStreet SL changes. I see where Linden Lab comes from with the announced changes, and I think this is not all bad. I also see where Linden Lab goes to with these changes, and I am not sure whether I like it. I heard many good arguments against the canges from residents and merchants. And I heard many good arguments for the changes, also from residents and merchants. What I am sure of is that the changes were certainly not a majority-wish, as the Lab wants us to believe. At least not a majority in the sense of the majority of people. Maybe a majority wish in terms of amounts sold...

In the process of making up my mind whether I am for or against the changes, I looked at my own XStreet SL listings. This has, in fact, been overdue, so that is a good thing that I now got forced to do it.

Regular Merchandise

The good news is - all of my items sell. Even the most expensive one - Plywood Man - sold 12 times this year, giving me 1508 L$ of revenue. Instead of the 5 L$ commission, there will be another 120 L$ per year to keep this item listed. However if I only sell 2 in the next year, I already make a small profit. Two other items, my Celtic Cross and my Dasher, are also in the "green zone" and will continue to generate a profit, even with the new charges. However the Lab will get 786 L$ share of those items (same amount of sales anticipated), instead of 182 L$ prior to the changes - so 604 L$ more for the Lab.

It gets critical with my 2-prim-couch. This items is based on a 5-prim freebie, which I trimmed down to look exactly the same but save 3 prims to clever prim parameter and texture repeat selection. I set that item at the more nominal price of 5 L$ and since I listed it back in the day 183 people thought these are 5 L$ well spent because it saved them 3 prims. Up to now, Linden Lab got no share of the sales of this couch. In the future they want 3 L$ for each sale and 10 L$ each month, so I need to sell 60 copies in order to break even. Unfortunately it only sold 53 times last year, and since it is not really stylish anymore, I will most likely delist it.

Promotional Items

The next two items are listed for 0 L$ - freebies. Those two items are actually a good example for promotional items as Linden Lab states. I do not give them away for free because I am such a nice person. I give them away for free to raise awareness of my in-world business and find new clients. Up to now, Linden Lab gave me free advertising - now they want me to pay for it. Of course I would have preferred to still have it for free, and I do not really buy the explanation that the running costs are so high. However 1188 L$ per year is easily affordable for my business.

There are two problems however:

1. Freebie listings will not be searchable anymore and can not be put into suitable categories anymore - they go into a special freebie category. This makes it basically unusable for me. Potential clients find my Language Kiosk in the "Business -> Signs" subcategory. They will certainly not look in a freebie category. And those who will look in a freebie category, are usually not the ones requesting my services. If it is a promotional tool, and if I have to pay 1188 L$ per year to keep it listed, then don't give me a worse service than before!
   
   
2. Even without the first item, I would not keep TWO items listed. Both have basically the same aim and effect, so I would only keep one of those. Sorry, LL, not 2 x 1188 L$ for you.

Another solution would be to set a price for those promotional items. If I set them at 1 L$ I can assign them to whatever subcategory I want. However I would still need to pay 3 L$ commission on them, so I lose 2 L$ per sale. With a projected amount of 200 sales a year the cost would be 12 * 10 L$ monthly fee + 200 * 2 L$ commission after sales = 520 L$ - or almost exactly 50% of the intended cost of a promotional item. Sounds like a no-brainer.

General Considerations

I mentioned in the beginning that I understand where Linden Lab comes from. XStreet SL is like the Wayback Machine for Second Life. There are thousands upon thousands of obscure items. Admittedly there are thousand upon thousand of outdated items like pre-sculpty-age shoes. The fact that listing items without cost was a blessing and a curse. There is a lot of - well - trash on Xstreet. There are countless grossly overpriced items. But also countless very good items, items from philantropes who give them away for free as community service, as well as items from content creators that never bothered with shops and just developed for fun. Many of those merchants have panicked in the meantime and pulled their stuff. Which is an immense loss - even from a istorical point of view.

A second consideration is that Second Life does not have an effective object search! The closest that comes to an object search in SL is in fact XStreet SL, exactly because of what I said in the last passage. To be honest, searching in XStreet is a pain, but at least you can do it.

How would I have done it?

Accepting the assumption that XStreet SL needed changes at all, there still would be things I had made better:

1. Linden Lab claims that the changes were wanted by the majority of users. There are reports that this is somewhat of a euphemism. Fact is that those changes affect definitely way more merchants than got involved in the process. The proper way would have been to send a survey to all merchants on XStreet SL, and a second survey to all people who made at least one purchase in - say - the last 3 months on XStreet. This would be in my opinion the only way to get qualified feedback.
2. One approach would have been to automatically disable items that have not sold in a certain amount of time (6 or maybe even 12 months). That way, the "clutter" (as LL calls it) would be gradually removed. Merchants could manually reenable those listings - and maybe this would be a place where a monthly fee would apply.
3. A better distinction between promotional-freebies and philanthropic-freebies could be found. Someone whose whole XStreet inventory consists of 0 L$ items is certainly not promoting his regular merchandise with them. Someone who has 50 hairstyles on sale, and 50 associated demos is clearly promoting them, but is probably not in a position to pay 4950 L$ for all of them. Why not extend the functionality of XStreet with a "deliver demo" option? Maybe as charged-for option?

My bottom line

From my point of view it is not the end of the world as we know it. I can subscribe to some of the motivation behind it, but I think there would both have been better ways to get a true majority vote, as well as better ways to implement some changes.

I will not pull my items from XStreet SL, as it is still the major web platform. I will adjust my inventory to minimize cost and maximize effect - something every sensible merchant should do. Linden Lab will get more money from me - no way around that - but less than they probably thought they'd get.

I definitely got the motivation to seriously consider alternatives - but not to abandon XStreet SL. The alternatives will be used to widen my exposure and give additional revenue.

What is your take on the changes?

Transgender Day of Rememberance

The word Transgender defines a mixed bag, but is mostly used to describe those fellow humans among us, that see and experience themselves as one gender, but unfortunately their biological body does not match this gender. The available options to those people range from ignoring it and arranging themselves with a life in the wrong body to undergoing medical treatment and ultimately having sex reassignment surgery.

The important thing is that today, in 2009, they actually have a choice! We have not only made radical advances in the medical area, also society has become much more understanding and liberal, accepting not only the reality of those people, but also granting them the choice to live the life they want to live.

Some people however did not get a choice. Some people were killed, murdered, beaten to death, tortured, shot - because they were different! Because their murderers could not cope with that, because their killers could not accept the fact that people sometimes end up in the wrong body. So they took the right of choice from their victims, and chose death for them.

And there are others that could not live with the conflict anymore. Who felt obliged - for whatever reason - to keep up the appearance for their parents, their siblings, maybe their wives or husbands. Because they feared social repercussions, loss of job, loss of status. Because they did not know there are other ways. Because they could not afford them. Because they felt ashamed to ask for help. And saw no other way than to kill themselves.

Today, on the 20th of November, we think of those poor souls who got killed or took their own lives, simply because they were different. Today is Transgender Day of Rememberance.

Why inventory transactions fail, and what you can do about it

[SL blogs are shaken up by the questionnaire Pink Linden sent to Xstreet SL merchants. Among many other things, the survey asked whether merchants would pay a premium for guaranteed deliveries. As far as I know, this is the first time for Linden Lab to publicly admit that failed deliveries are a problem.]

Everything is an Instant Message. Not only if you send an IM to a friend, no, things like teleport requests, force teleports, teleport acceptance, teleport rejection, friend requests, friend acceptance, friend rejection, object IMs, busy response IMs and so on and so on. My friend Katharine Berry counted them once and came up with 40 different types of IM's in SL.

Inventory offers are - behind the scenes - IM's as well, and this is the reason why so many inventory transfers fail!

During our work on the Designer Showcase Network, Rika Watanabe and I encounterend a surprisingly high number of inventory transactions failing, and after some digging we found that this is a common problem for other delivery systems like Subscribe-o-Matic or even XStreet SL. There are a few scenarios, where failed transactions can happen:

Case 1 - Recipient is in "busy" mode

• Sender is an avatar
  Never fails, object (or notecard, texture, etc) can be found in "Trash" folder, sender gets a "... is busy" notice.
• Sender is a "Buy" object
  Never fails, bought merchandise goes to where it is supposed to go (its own folder or the matching system subdirectory)
• Sender is a scripted object (e.g. "Pay" object or "Touch" vendor or subscription system)
  Always fails! The scripted object uses llGiveInventory, which does not have any feedback functionality. A paid for-purchase will be irrecoverably lost, and what is even worse, the merchants transaction history will show no anomalies.

Case 2 - Avatar is offline - no capped IM'S

• Sender is an avatar
  Never fails, upon login of the recipient a blue box appears via which you can decide to accept or decline the delivery. An IM is generated "Xyz sent you inventory" - those IM's go to your offline email address if specified. Those IM's also count toward your IM cap.
  
• Sender is a "Buy" object
  Not possible when you are offline
• Sender is a scripted object (e.g. DSN dropbox, S-o-M or XStreet delivery)
  Never fails, upon login of the recipient a blue box appears via which you can decide to accept or decline the delivery. An IM is generated "Xyz sent you inventory" - those IM's go to your offline email address if specified. Those IM's also count toward your IM cap.

There is a limit to how many IM's an avatar can receive while being offline. I did not find an official statement as to how many IM's it takes to cap, several discussions on forums and the JIRA suggest that the cap will happen after 15 IMs. While you still get offline-IM's that you received something, what you actually find in your inventory is different:

Case 3 - Avatar is offline - IM cap limit reached

• Sender is an avatar
  Oddly enough those mostly work. Sometimes you get the blue box to accept, sometimes you don't get the blue box and the inventory offer goes straight to the matching folder. An offline-IM is being generated.
• Sender is a "Buy" object
  Can't happen when you are offline
• Sender is a scripted object (subscribe-o, XStreet dropbox, Deliverator, DSN, etc.)
  Always fails! While you receive an offline-IM, the objects are nowhere to be found and can't be recovered. What makes it even more annoying is that the transaction logs of the sending systems have no way of telling whether you actually receive the inventory offer, or not.

Inventory transfer success matrix
	Busy	Offline Non-capped	Offline Capped
Avatar sends	ok	ok	sometimes
Buy object	ok	n.a.	n.a.
Scripted Object	fails	ok	fails

The culprit in those failed cases is the unholy union of the llGiveInventory function in the LSL scripting language and the IM-based delivery system. The function only gets a recipient-ID and an inventory object, however it has no way to check whether the transaction was actually successful. It's basically a shot in the dark, and given the vulnerability with capped IM's as shown above, can only be described as incomplete.

In theory a script could check if the recipient is only, thus avoiding the capping problem. This approach has two drawbacks:

1. Scalability
   A script only delivering items when an avatar is actually online might end up with an immense backlog of deliveries and ultimately meet memory issues
2. Busy
   There is now way to find out whether an avatar is busy from within an LSL script

What can I do to avoid inventory transaction loss?

There are a few things each of us can do in order to ease the situation. In case of XStreet SL (or similar services) purchases, the easiest thing is to make sure you (or the recipient) are actually logged into SL and not-busy during the time of purchase.

For systems like DSN, Subscribe-o-Matic, Deliverator and other services that send you objects at a schedule you can't influence there is only one way to raise the success rate: avoid capped IM's!

A few methods:

• Leave "spammy" groups, e.g. groups with a lot of group notices
  A group like FashCon can easily reach your capping limit on a Saturday evening within 10 minutes because of the massive amount of group notices. In case you can't leave the group (e.g. because it is a land group), at least switch off group notices. The notices are still available in the groups archive for a while.
  
  
• Unsubscribe from lists with high activity
  I was signed up to some Subscribe-o-Matic systems where there was almost daily a new notice from the shop owner. While it is commendable that the merchant keeps such a close communication with their client base, this actually adds a lot to IM-capping. In fact lately I am very reluctant to subscribe to a SoM or Hippo-Group at all, and have unsubscribed from many as well.
  
  
• Reduce offline-messaging objects
  Many scripted objects can send their owner various status information, for example security orbs if someone has trespassed on your naughty skybox. Usually those devices use the llInstantMessage function which - right - sends an instant message that would add to capping if you are offline. With llEmail exists a slightly more complex mechanism, that instead of sending an IM sends an actual email to an actual off-world email address. A script could even be designed to detect whether the recipient of a notice is online and use llInstantMessage or offline and in that case use llEmail. This should become a level of expectation to scripters to help avoid capping IM's.
  
  
• Ask your friends to cooperate
  Many people send IM's or objects to friends who are offline. The intentions are meant well, however those IM's and transactions also add to each person's IM cap count.

Anything else that can be done?

Yes, there is, alas not by you or me. There is quite a lot that can be done by Linden Lab, and it is up to us to raise awareness.

• Create an alternative to llGiveInventory
  What is needed is a way to get some feedback if the inventory transfer has actually succeeded. Yes, this is far from trivial and requires many, many behind-the-scenes changes, but don't tell me it can't be done! The most drastic change that needs to happen is ...
• Get rid of the IM-based transaction system
  ... because then object transfers can be operations within the database itself (instead of database -> IM system -> database). The detour through the IM system is probably only to give the recipient a notification. Otherwise it would be a simple copy or move operation in the asset server database.

In the recent survey, Pink Linden asked whether merchants would welcome a system that guarantees delivery. Yes, of course we would, but not at a 15% premium. Inventory transfer is a basic functionality of SL, and to say it bluntly - it is broken! Fix it! Asking a premium for guaranteed delivery strikes me as - well - unethical. I think it is Linden Lab's obligation to fix the functionality that is there, and not ask money for a workaround.

I actually wonder what Pink Linden has in mind? The llGiveInventory function, and the problems I described here, can't be selectively fixed. Either they work for everybody, or they keep being broken. So a certified delivery is most likely just a method to request a redelivery, and then it gets complicated when transferable items get sold (hat tip to Rika for that thoug).

Anyways, please, Linden Lab, fix llGiveInventory and the assorted functionality now!

And everybody else, please vote on this JIRA which deals with the issue.

Thanks!

LabGraal - celtic Live Music in SL

The other day I was bored in SL and did some map-hopping: pulling up the map, reduce the zoom level, and check for sims that either look interesting, have an interesting name or have a number of green dots on them. After some sobering experiences, and actually close before I gave up, I found the sim of Glendalough, whose name and map-image captured my attention.

After teleporting there I found myself in a beautiful Irish-themed setting, with an incredible amount of wild vegetation, the ruin of an abbey, right enough a pub, a solemn cemetery and loads and loads of beautifully designed corners and places and many hidden corners. You can see that a lot of care has been taken to make this place as authentic as can be, and to make it beautiful with a love for detail.

Near the pub was a stage announcing the concert of a band using some celtic symbols, but the poster said Saturday and it was Sunday. I regretted this a bit since celtic folk, celtic rock and celtic fusion is the kind of music I like very much, but the sim had enough beauty so I did not mind longer.

However, suddenly, an announcement was made that the concert is about to start soon - whether it was a repeat or they rescheduled it was not mentioned - and I went to the stage area where the band assembled themselves. And a minute later a bagpipe made its war cry across the sim.

The act I was fortunate to attend was a celtic band from - of all places - Italy. I knew that France - especially Brittany - has a vivid celtic scene, but Italy was new to me. The band LabGraal (LABORATORIO MUSICALE DEL GRAAL) is a "real life" band who has released 6 CD's by now. They have dedicated a portion of their website to their Second Life involvement. Anyhow, the music was very energetic and driven, the lead singer had a lovely accent and lead nicely from song to song, but what was most amazing is that they actually had a stage show!

I attended concerts - both of solo acts as well as of bands - in SL before, and none of them had a stage show. The musicians usually loop through the very same animations - which is especially confusing in the pauses between songs. Not so LabGraal - the musicians moved on the stage, they changed instruments, they used appropriate animations during solos - and they even clapped their hands above their heads during an especially exciting solo of one of the players.

All in all it was an amazing evening, the sim was packed with well over 30 avatars, and I had a great time. My dear friend Nissa, who joined me after a while, was quite surprised as well. It was her first live music event in SL - and it probably got her hooked.