I can't recall the last time I saw as big an earthquake roll through the SL community as the one that hit last Friday with Ebbe Linden's off-the-cuff comment about LL developing a next-generation SL that would not be constrained by compatibility with the existing one. Ever since the story broke, there's been a lot of panic and a lot of misinformation floating around.
Folks, SL is not in any danger of disappearing any time in the near future.
To begin with, the timeline is well out there. LL is just now ramping up hiring to develop SLTNG, as I'll call it (by analogy to Star Trek: The Next Generation, commonly referred to as STTNG). It will take those new folks a fair amount of time simply to learn where the bathrooms are, never mind become truly productive in building a new platform. The estimate I've seen is beta in late 2015, and release sometime in 2016. I think this is optimistic.
Then there's the time it'll take to ramp up the new service and get people to join and make things and in general make it a viable, going concern. This will not be trivial; I wouldn't be surprised if it wasn't really viable until Christmas 2017.
Until that happens, LL will need money. Guess where they're going to get it?
If you guessed SL, you're right. They have no other real source of income. Their other products either withered to begin with or else were killed outright. Oh, there's a possibility they may raise some venture capital, though I'm skeptical. Given LL's trajectory, that would be a risky play for a VC, and they're not looking for risk. They're looking for the next sure thing.
So this means that LL will continue to support and, where appropriate, enhance SL. SLTNG is a bet-the-company proposition. They're hiring a nontrivial bunch of people to take on a big challenge that will take years to pay off, and whether it will pay off at all is very much an open question. SL is profitable, and they need those profits to keep the doors open while they develop SLTNG.
This isn't the first time that a company has pre-announced a new product while depending on the original. The standard business-school example of this is referred to as the Osborne Effect, after Osborne Computer Corporation, which went bankrupt in 1983 after pre-announcing new computers sent sales of the existing machine into the tank.
I don't know if this is a case where Ebbe's comments were a slip of the tongue - though one doesn't get to be CEO of a corporation, especially one with as much social media experience as Ebbe, without understanding exactly how widely his words would be reported - or if this was a calculated announcement before a carefully selected audience. Either way, he's running the risk of triggering the Osborne Effect.
Folks, this is a bad thing for LL. The only thing that could make it worse is the user community bailing prematurely. Guess what's happening? You're doing exactly that!
LL's not about to kill off, or even cut back on, SL any time soon. They can't afford to. And there's another reason, too. His (SL) name is Oz Linden.
Yeah, people love to bash Oz, but I'm very happy that he was chosen as the technical director for SL. Folks, he believes in Second Life. Disagree with his approach all you want to, but you have to admit that everything he's done has been with the best interests of SL at the forefront of his mind. Further, he's a long-time advocate of open source, well before he ever got on SL, and SL needs open source now more than ever: if the technical team for SL is being pared back, they have to leverage the efforts of other folks even more now than they used to. That means working with TPV developers closely.
Oz is sticking his neck out one hell of a long way by taking this position. If SL goes in the tank, his job goes with it.
All of this means that the sky is not falling. It's not even clouding up. SLTNG won't even be anything to take a sneak peek at for at least another year, and that's highly optimistic. It won't be a serious competitor to SL for two years at an absolute minimum, three more realistically, and four is not outside the realm of possibility. It's also possible that SLTNG will flame out and not work at all, or not achieve the desired results.
Now, this does not mean that there's nothing to be done to help SL and its users in the meantime. SL's not the perfect service, as many (including I) have argued. But it's still the same great place to be it was Friday morning, before Ebbe teleported into Hippotropolis. It's still worthy of the same care, and the same effort, and the same support, that it was then.
Jess asked, in a post to the official Firestorm blog, for ideas for one big change that would help SL not only stay around, but grow and thrive. Everyone's got their own thoughts on the subject; here's mine.
Before we think about what needs fixing, we first need to define the problem. The biggest problem SL faces is a simple one: what's there to do inworld? Personally, I think the reason that people join SL, log in a few times, and then go away and do something else is that there's nothing interesting to do. The platform is interesting in and of itself for about 15 minutes. Then the user is going to want to do something fun.
There used to be lots of fun places to go and do things. They've steadily dropped from sight, one by one. It's not that their makers lost interest; rather, it's that they couldn't afford to keep them running. Big, fun builds, testing the limits of the capability of the platform, are expensive to run - because the price of sims in SL is high. Even folks who have full sims at a grandfathered US$195 a month each are still laying out a significant chunk of change for the privilege. I am at a total loss as to how the folks behind Calas Galadhon afford their 10 sims (or is it 8 now?). Most of these things are a labor of love, and that kind of love gets hideously expensive. It's still worse for folks who can't get the grandfather deal.
This also raises the barrier to entry for new folks with new experiences to build. Even a homestead at US$125 a month is expensive for what you get, and you have to either have a friend with a full sim to hang it off of or else rent from a land baron, as I do, and he has to make his money, driving the cost up further.
The long and the short of it is that tier is a major issue, if not the major issue. Everything else comes back to it. Yes, it's LL's major income (at least I'm pretty sure it is, though exchange fees on L$ purchases and Marketplace commissions can't be trivial). Cutting tier would represent a major hit to LL's bottom line. The flip side of it is that a sim just isn't that expensive for LL any more. Hardware power has gone up as costs have gone down, and they can run more full sims on a physical box than they could five years ago when the current prices were set. The $1000 setup fee is ridiculous, as well: if it takes more than one person filling in one web form and clicking OK to provision a new sim, I'll be stunned. So LL's costs have to have gone down, but tier has remained the same as content providers and folks who give SL the richness that makes it the place to be wither up and blow away.
LL needs to lower tier. Now. Especially now, as a statement that SL is here to stay.
Meanwhile, there's one other aspect of this whole business that troubles me more than a little bit. Ebbe has very carefully not said that there's a place for open source in SLTNG. I've asked repeatedly, in channels I know he's reading, and he hasn't said word one to even acknowledge my existence, let alone answer the question.
I think this says it all, really. There is no place for open source in SLTNG.
I can understand why LL might reach this conclusion. From their point of view, it has to be frustrating as hell to roll out a new feature and then have to depend on a volunteer team of open source programmers to update their software to make the feature have a decent chance of being used by the SL user community. In a real sense, they've lost a big measure of control over their platform. That's a situation no business wants to be in.
Still, this ignores the simple fact that, by and large, Lindens don't understand how the platform is really used by the folks who pay the money. If you need an example, you need look no farther than Viewer 2. $DEITY, what a hideous mess that was. It took us a solid year of effort to de-suck that. LL adopted a lot of our ideas, but their viewer is still a pain to use for anyone who's become accustomed to Firestorm.
TPV developers have expanded the platform in many ways, all of which have kept users around on the platform. I personally would not be here if not for RLV, and that's entirely an open source effort. (At least I can't see LL adopting it as part of the standard platform!) Throwing us under the bus cuts off an important source of improvements.
I'm not aware of any company that's made the transition from open source to closed source and survived. LL may be between a rock and a hard place, but keeping SLTNG closed source would be a big "fuck you" to a large part of the user community - and community is what LL has to have above all. Communities form around the places I discussed earlier, and communities are what keep people coming back even when they've explored all the fun places.
So far, what I'm seeing is that LL doesn't want communities, but disconnected consumers. That, more than anything, will kill SLTNG, and SL, and LL as a company.
No, the sky's not falling yet. It could, though, if LL doesn't handle this right. Fortunately, there's lots of time between now and then.
17 June 2014
Kludges in the name of compatibility
The verdict is in, and server-side appearance is a big win all around. Bake fails have dropped to being very rare and fairly easy to fix. One whole class of copybots has been rendered much less useful (those that copied system clothing). Rezzing is much faster, as are outfit changes.
Nevertheless, not all is rosy in SSA-land. Before SSA, the viewer had the ability to set the avatar's bounding box height. The bounding box is the box the server's physics engine uses to decide when the avatar is going to collide with something and take appropriate action. Adjusting the height had the effect of changing the center point of the avatar, and thus making it rise or sink vertically.
SSA changed that. Since all of the parts of the avatar's bounding box are determined by the shape and attachments the avatar's wearing, the SSA bake oven can figure it out all by itself. So it does. Since it's being done server-side, the viewer now has no ability to control it.
This removed a useful and popular feature. Many pre-SSA viewers had a control, like the one Firestorm called Z-offset, that let the user move her avatar up or down. This was useful for mundane things like not sinking into a chair, as well as compensating for some rather extreme clothing and the like.
It was also widely used to compensate for animations that were set up for one height of avatar, making them lift smaller avatars into the air and sinking larger avatars into the ground. This capability was automated in the RLV specification with the @adjustheight command.
When it was discovered during SSA testing that the Z-offset feature no longer worked, we raised the issue with the folks at LL. Nyx Linden went out of his way to implement a fix on his own time: the hover attribute on an avatar's shape layer. The fix works well for what it does, but it doesn't cover all of the use cases - and arguably the ones it doesn't cover are the most common ones.
Henri Beauchamp fixed the omission. Unfortunately, he did it in a really hackish way: he took the Z-offset specified with the control, or @adjustheight, and modified the shape the user is wearing. It works, to be sure, but it's a real kludge.
There are several problems, most notably that the shape must have modify permissions for the feature to work at all (else the SL permissions system is violated, a strict TPVP violation) and adjusting the height results in modifying an asset on the SL asset server. I find the latter most curious, since Henri resisted implementing the current outfit folder in CoolVL Viewer based on his unwillingness to depend on automatic asset updates from the viewer.
The Firestorm team discussed it internally, and decided not to implement this kludge. We felt it was just too problem-prone, as well as either being limited by the permissions system or else requiring a violation of it to be useful in many cases where the user has purchased a no-mod shape. As it happens, LL has said that shapes are not intellectual property and therefore not protected by the permissions system...but bypassing it on this basis makes us vaguely uncomfortable. (And yes, allowing shape import/export makes us a bit uncomfortable as well, but since the LL viewer does exporting without considering permissions...)
Marine Kelley now has a product, the Pretty Mummy set, that depends on @adjustheight to work properly. It looks really nifty, with several components, both fitted and unfitted rigged mesh, and has a lot of capability and a lot of complexity. However, it apparently does not work well if @adjustheight is broken. Marine's answer is to tell people to use her viewer or CoolVL Viewer, which have Henri's kludge in them. (She also tells people to use Singularity, but according to one developer, that viewer doesn't have the kludge - and won't implement it either, for the same reasons we won't. We're not sure why Singularity users can see the item properly, if in fact they can.) Further, the product seems to issue @adjustheight whenever the avatar is moving - several times a second. This is a recipe for corruption.
The right answer is not to kludge around the lack as Henri did, but rather to implement a proper Z-offset mechanism in SL that propagates through the SSA bake process. This will require LL to help out. What we don't know is why Nyx did it the way he did. We suspect, but do not know for sure, that a real fix was suggested and turned down internal to LL. If that's the case, then we may not be able to convince LL to implement it properly.
Until this is fixed right, we see no reason to implement Henri's kludge. We've come up with a tiny bit less kludgy solution internally, and may implement it if nothing better is possible (involving physics layers, which aren't protected assets). Still, the right answer is to get LL to do it right.
We're especially not going to implement Henri's kludge for the sake of compatibility with one product. Sorry, Marine.
Nevertheless, not all is rosy in SSA-land. Before SSA, the viewer had the ability to set the avatar's bounding box height. The bounding box is the box the server's physics engine uses to decide when the avatar is going to collide with something and take appropriate action. Adjusting the height had the effect of changing the center point of the avatar, and thus making it rise or sink vertically.
SSA changed that. Since all of the parts of the avatar's bounding box are determined by the shape and attachments the avatar's wearing, the SSA bake oven can figure it out all by itself. So it does. Since it's being done server-side, the viewer now has no ability to control it.
This removed a useful and popular feature. Many pre-SSA viewers had a control, like the one Firestorm called Z-offset, that let the user move her avatar up or down. This was useful for mundane things like not sinking into a chair, as well as compensating for some rather extreme clothing and the like.
It was also widely used to compensate for animations that were set up for one height of avatar, making them lift smaller avatars into the air and sinking larger avatars into the ground. This capability was automated in the RLV specification with the @adjustheight command.
When it was discovered during SSA testing that the Z-offset feature no longer worked, we raised the issue with the folks at LL. Nyx Linden went out of his way to implement a fix on his own time: the hover attribute on an avatar's shape layer. The fix works well for what it does, but it doesn't cover all of the use cases - and arguably the ones it doesn't cover are the most common ones.
Henri Beauchamp fixed the omission. Unfortunately, he did it in a really hackish way: he took the Z-offset specified with the control, or @adjustheight, and modified the shape the user is wearing. It works, to be sure, but it's a real kludge.
There are several problems, most notably that the shape must have modify permissions for the feature to work at all (else the SL permissions system is violated, a strict TPVP violation) and adjusting the height results in modifying an asset on the SL asset server. I find the latter most curious, since Henri resisted implementing the current outfit folder in CoolVL Viewer based on his unwillingness to depend on automatic asset updates from the viewer.
The Firestorm team discussed it internally, and decided not to implement this kludge. We felt it was just too problem-prone, as well as either being limited by the permissions system or else requiring a violation of it to be useful in many cases where the user has purchased a no-mod shape. As it happens, LL has said that shapes are not intellectual property and therefore not protected by the permissions system...but bypassing it on this basis makes us vaguely uncomfortable. (And yes, allowing shape import/export makes us a bit uncomfortable as well, but since the LL viewer does exporting without considering permissions...)
Marine Kelley now has a product, the Pretty Mummy set, that depends on @adjustheight to work properly. It looks really nifty, with several components, both fitted and unfitted rigged mesh, and has a lot of capability and a lot of complexity. However, it apparently does not work well if @adjustheight is broken. Marine's answer is to tell people to use her viewer or CoolVL Viewer, which have Henri's kludge in them. (She also tells people to use Singularity, but according to one developer, that viewer doesn't have the kludge - and won't implement it either, for the same reasons we won't. We're not sure why Singularity users can see the item properly, if in fact they can.) Further, the product seems to issue @adjustheight whenever the avatar is moving - several times a second. This is a recipe for corruption.
The right answer is not to kludge around the lack as Henri did, but rather to implement a proper Z-offset mechanism in SL that propagates through the SSA bake process. This will require LL to help out. What we don't know is why Nyx did it the way he did. We suspect, but do not know for sure, that a real fix was suggested and turned down internal to LL. If that's the case, then we may not be able to convince LL to implement it properly.
Until this is fixed right, we see no reason to implement Henri's kludge. We've come up with a tiny bit less kludgy solution internally, and may implement it if nothing better is possible (involving physics layers, which aren't protected assets). Still, the right answer is to get LL to do it right.
We're especially not going to implement Henri's kludge for the sake of compatibility with one product. Sorry, Marine.
Subscribe to:
Posts (Atom)