LL's Third Party Viewer Policy changes: Screw you, developers!

LL today announced, in a very contentious meeting, four new sections for the Third Party Viewer Policy. From the posting on the SL blog/forum:

Here are the new sections of the policy:
2.a.iii : You must not provide any feature that circumvents any privacy protection option made available through a Linden Lab viewer or any Second Life service.
2.i : You must not display any information regarding the computer system, software, or network connection of any other Second Life user.
2.j : You must not include any information regarding the computer system, software, or network connection of the user in any messages sent to other viewers, except when explicitly elected by the user of your viewer.
2.k : You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer.

Taken together, these changes are a big fat "screw you!" to TPV developers, with one exception.

The first outlaws true online status as shown by Phoenix. In the process, LL will break function used for other reasons then being eeeeevil: the llRequestAgentData() LSL function I used in this post to show a user's true online status will now only work for the owner of the scripted item and the creator of the script - or so we were told. Since the creator of a script is lost when the script is placed in a prim, that doesn't make much sense. If the Lab provides a way for legitimate users of the data to deal with their needs some other way, that's great; on balance, it's a win, though it's going to break thousands of items inworld.

The other three are simply LL telling TPVDs how the cow eats the cabbage.

The second bans the viewer tag system used by every TPV except for CoolVL. The stated reason is to protect the user's privacy, with an aside about people being bullied into switching. The politest term I can use to comment on that reasoning is that it's bullshit. What it's really about is LL not wanting people to know that their viewer is used by a minority of the user base, and that there are other viewers out there that are much more popular because they fail to suck.

The third is similar. There was some question as to whether turning on RLV was sufficient opt in to enable the @version reply message, which includes the name and version of the viewer; Oz said it would be. It also permits the use of the feature that shows whether a user is using Phoenix or Firestorm in the support groups, if they opt in (currently, that setting is opt-out). So yeah, they threw us a bone. Even so, the effect of these two is to greatly diminish the effects of the overwhelming majority of users running something other than the official viewer - which is exactly what LL wants. Their thinking, which they won't admit to but is blindingly obvious to anyone who looks, is that they hope to keep people from migrating away from their viewer.

The last is the worst. It prohibits TPVs from developing features for Second Life that won't instantly appear the same on the official viewer. Many of the features that users have requested most - multi-attach, avatar physics, parcel Windlight to name three - started out as features that TPVs introduced. They were all proposed to LL before they were introduced, and got shot down in flames; LL's use of the first two features came two years after they were introduced. The third doesn't exist yet in the official viewer, even though LL asked us not to introduce it before they did - and that was fifteen months ago.

Now they want us to submit proposals to them through the official process, then work with them to develop them in the official viewer, and only when the official viewer can show them can we roll them out in the TPV. Let's see...they can squash the feature entirely, after taking however long they damned well please to even look at the proposal; if they do accept it, you can't develop it in your own viewer, but only in the craptacular official viewer; and they can roll the feature out in the official viewer immediately when it's done, but we have to wait for that before rolling out our own.

This puts LL completely in control of our development cycle if we do have a new feature that's somehow survived the gauntlet. Worse, it's not symmetrical: the Lab can develop new things in secret, and spring them on an unsuspecting grid, leaving TPVs to catch up as best we can - and Oz said today they would continue doing that.

This limits TPVs to working in the UI, leaving actual improvements to the SL platform entirely at the mercy of LL. Tell me why we're supposed to be other than thoroughly pissed off at this?

The last paragraph is ripe with possibility for unintended consequences. Oz said that RLV would not be banned under that policy, and that parcel Windlight was getting a free pass - but only until LL got off its ass and released their version. I'm not holding my breath for that one. Look how long we've been waiting already. I'll also not believe that they'll do other than develop it in secret, without our participation, and then demand we remove it immediately, without giving us time to adapt the feature for our viewers, until it actually happens - and then only when it's a fait accompli. Oz also swears up and down that the process will be different. I'll believe that only when I see it, preferably several times.

No, we're not happy with the changes in the TPVP. We're stuck with them anyway. Fuck you too, LL.

When it is acceptable for a TPV to borrow a feature from another viewer?

Oz Linden asked, in the email announcing the agenda for this week's Third Party Viewer Developers' meeting:

Some viewer developers have historically taken the position that any open source is automatically fair game to use at any time. This has sometimes lead to some changes being used either before the originator considered them ready for general use, or to other bad feelings.

I have asked that Linden Lab changes, even when in public repositories, not be used by TPVs before they are merged to viewer-development, and in the case of new features not before they are in a released viewer (though that differencer is normally very small).

• When is it appropriate to import a feature developed outside your viewer?
• Should TPVs explicitly get permission?
• Should there be a protocol for this?

I'll preface my comments by saying that Phoenix and Firestorm aren't the first open source projects I've been involved in. I've been the manager of another project with several thousand users for 12 years now, and dealing with open source for longer than that.

The key to remember here is that the open source world is a gift economy, and it runs not on money, but on public credit for work. People work on open source software first and foremost to scratch their own itches, but they release their work in the expectation that they'll get credit for it. Eric Raymond explored this pretty thoroughly in his essay Homesteading the Noosphere. It's well worth a read.

I, personally, go far out of my way to ensure that whoever develops a feature gets full credit for it. I think that's true of the Firestorm team, even if it's not so much in other viewer development efforts. I think it should be. In the open source world, using someone else's feature without crediting them is as close to theft as there is.

The water gets murkier when LL enters the picture. After all, LL doesn't run on credit for its work. I can't speak to the actual motivations for their decision to open source the viewer in the first place, but for a corporation, it usually revolves around leveraging the open source community to improve their product through new code and bugfixes. The model certainly works, as many companies demonstrate every day.

Even so, it's not unreasonable for LL to expect credit for its work. There are things LL can do that no TPV can simply because they require server-side support, and those features can be pretty substantial. It would be unreasonable for Firestorm to claim credit for mesh, after all.

Credit isn't just in the eyes of the TPV developer community, though. We're a tiny, tiny minority of the users of SL. It also goes for the broader community of users, as well, especially since barely a third of them use LL-supplied viewers. They don't know the machinations behind the scenes that lead to the viewers they use. They just know what comes out with which new feature first.

We've been burned by this. Kirsten released her viewer with pie menu support before the release of Firestorm that had it. Guess who got credit for it in the public eye? Not Zi Ree, who wrote it, or Firestorm.

This led Jessica Lyon to propose an informal gentlemen's agreement among TPV developers and LL that nobody would jump the gun and release a new feature before the viewer in which it was developed was released without their permission. Most TPV developers signed on, as did LL. It seems to be working, though there's not a lot of data yet to say that for certain.

In general, I think it's inappropriate for one viewer to import a feature from another viewer unless it's in a publicly available release, or permission has been granted, and appropriate credit given - and not just in release notes or the like, but in the release announcement as well. "This release has feature X, developed by the Firestorm team", for example.

I know of no good way to formalize it, however. Any attempt will simply cause bureaucracy and annoyance, and not bind anyone who wouldn't already be willing to follow such a policy.

This discussion assumes that sharing flows both ways. There are some viewer development teams that have taken steps to limit or stop others from importing their features. One team licenses its viewer under the GPL, which prevents importing their code as a practical matter by any viewer that wishes to remain LGPL-licensed. (That team has other issues with legality, but that's outside the scope of this discussion.) Others simply don't commit the code to their public repository until it's ready for release. This defeats the purpose of a public repository in that it makes it much harder for people to trace the development history of the code until it's already in common use.

LL has changed its policy, too, and now will not make code for new features publicly available until they are ready for release in the official viewer. I believe this is a major mistake, as it both limits uptake of the feature - possibly to the point that it will never see significant uptake, as with media on a prim - and makes it more difficult for others to wring it out before it hits the grid. The stated reasons ring a bit hollow, but so far LL has been resistant to the idea of changing the policy. I hope that a resolution to the issue of credit will be enough inducement for it to be revisited.

This discussion applies only to code for new or improved features. Bugfixes are a separate issue. The overriding goal of every viewer developer is (or, at least, should be, IMAO) to improve the user's experience in Second Life. Bugs do not improve that experience; fixing them does.

We have waited, in the past, for bug fixes to be merged to viewer-development before releasing them ourselves. This put LL in control of the Firestorm release schedule, and when the bugfix took a back seat to new feature development, it left our users hanging. I'm not going to try to dictate LL's development priorities, but by the same token, I don't think it's fair for users to be left dealing with serious bugs while we wait for LL.

I believe that bug fixes are fair game, and should be shared widely, fully, and rapidly upon discovery and verification. This does not mean that credit should not be given, of course.

To sum up: I think the existing gentlemen's agreement for features is the right approach. I don't think there's any good way to enforce it, especially as a policy matter. Every honest, ethical viewer development team should have no trouble following it. Those that do not probably can't be stopped, except by reputation. Bugfixes are fair game whenever discovered and made publicly available in any form.

The game has changed

It's been quite a while since I've written a post. I've been keeping my head down working on Firestorm. But, as before, I'm annoyed to the point of feeling it's time I spoke out again.

There's been a lot of words, a lot of arguments, and a lot of hate and discontent over the Phoenix team's announcement that, with the mesh release, we have ended major development efforts on the Phoenix viewer.

Come on, people. This should be a surprise to exactly nobody.

We've been saying ever since the release of Phoenix 1185, months ago, that we were concentrating on Firestorm. We haven't changed our tune one bit, and we're not going to. The reasons haven't changed. The only thing that has changed is that we thought it wasn't going to be possible to put a mesh renderer in a version 1 codebase...and Henri Beauchamp proved us wrong.

I think Henri Beauchamp is a great guy, and an outstanding programmer. The same goes for Siana Gearz and Shyotl Kuhr of the Singularity viewer. They are clearly dedicated to keeping version 1 viewers alive, but I think they've bitten off more than they can chew, long-term.

All Second Life graphical viewers are based on one of the official Second Life viewers. Emerald 1632 was based on 1.23. Phoenix is based on Snowglobe 1.5, as are CoolVL and Singularity. Imprudence is based on Snowglobe 1.4. Firestorm is based, currently, on Second Life 3.1; we'll rebase it on 3.2 as part of the next release, most likely.

The problem here is that, as Linden Lab updates the viewer, and updates Second Life to add or change features, they're only updating one code base: the one Firestorm is built on. That means that anyone maintaining a viewer based on something else has to do a lot more work to incorporate those new changes, or else do without entirely. Since those changes often mean the difference between the viewer being able to do something critical - like load inventory from the server - and not, that means that the maintainer has to do that extra work.

Meanwhile, the Firestorm team can just import the code and update those parts of it that it's modified, a much easier task. Henri and Shyotl and Siana took the same amount of time to put mesh in their viewers as it took the Firestorm team to update from 2.5.2 to 3.1.

This problem will only get worse as time goes on, and the result can only be that the version 1-based viewers become more and more a tissue of hacks and scar tissue and duct tape and chewing gum.

Quite frankly, I've got better things to do with my time. I'm a Second Life user. Yes, I'm a viewer developer, and I've sunk an immense amount of time into the code. But the main reason I do it, as satisfying as it is to help the SL user community, is that I want a viewer that fails to suck.

Firestorm is that viewer. It will continue to be that viewer. At some point, version 1-based viewers will not be.

Make no mistake. At some point, sooner rather than later, LL will start turning off the services that version 1 viewers depend on. The version 1 search, profile, texture, and inventory interfaces all run on separate systems, with separate services behind them, and there's nothing in it for LL to provide those services forever. They soak up resources: administrator resources, power, network bandwidth, computer servers. LL has every reason in the world to want to turn them off.

Not only that, but LL wants - needs - to add function to the platform. They're not telling us about their plans. (A serious mistake; we can't adopt their new shiny if we don't know about it.) Even so, it's obvious that there's new stuff coming that will need viewer support. We have limited resources, and Henri, Siana, and Shyotl even more so. We can either dedicate those limited resources to moving with the platform and fixing those things that continue to annoy users, or else we can dedicate them to wrapping more duct tape and baling wire around the version 1 codebase.

I choose to concentrate on making the viewer fail to suck even more, rather than propping up a dying codebase.

If you use and enjoy Firestorm, great! We put an immense amount of work into it, and that's really all the thanks we need.

If you haven't tried Firestorm, all I ask is that you give it an honest evaluation. Put your (quite understandable; I share it too) loathing for the Viewer 2/3 interface aside. We've spent a year de-sucking it. Give it a good, honest try. Then, if you can't stick with it, tell us why - specifically, in detail.

If you refuse to consider using Firestorm because it's based on Viewer 2...well, quite frankly, I've got no more time for you. I'm busy making Firestorm even better, and I'm getting to the point where telling me that there's no way that Firestorm will ever be usable is nothing more to me than uninformed insulting blather. I know better. Compare Firestorm to Viewer 3.1 and you'll see just how much we've done. I can't stand Viewer 3 either. You know what? When I run Phoenix these days, it feels old and clunky.

Here it is. You'll have a choice at some point in the not too distant future. You can either switch to Viewer 3, switch to Firestorm, or get off of Second Life. You won't have the option of sticking to a version 1-based viewer.

As for us, we'll keep working on making Firestorm something you'll want to switch to when that day comes. That means we don't have resources to spend on Phoenix any more.

Phoenix was the best viewer on the grid for quite a while. Those days are past. Lead, follow, or get flattened by the stampede. Your choice.

Answering the ProKook, 2 of 2: BDSM is loving and consensual, not a cult

My last post dealt with Prokofy Neva's complaints about open source software. I'll turn now to his complaints about BDSM.

He and I have crossed swords about this before, on the old SL forums (before the current "community" website, a community where you're welcome only if you toe the LL line). From what I can decipher of his argument, it comes down to a refusal to believe that BDSM can be anything but violent and exploitative.

I guess he's never heard of the bedrock principle of BDSM. It's called SSC: safe, sane, and consensual. Any activity must meet all three requirements to be considered acceptable in the BDSM world. In practice, what is safe and sane is left up to the people involved, but the point is that they're both considered necessary and those involved must agree that what they're about to do is both. Consensual is the third part of that, and it underlies everything. Without it, it's just abuse. Some folks adhere to a slightly different principle, RACK: risk-aware consensual kink. It works out the same in practice, though, and both are recognized as valid.

Those who adhere to either philosophy have a shared commitment to only doing what is agreed on in advance, and strictly respecting limits set by anyone involved on what's permissible, and making sure to take care of their partner before, during, and after. Failing to follow any or all of this will get you ostracized from the BDSM community in very short order.

Fundamentally, it comes down to a basic principle: If two adults in possession of their faculties consent, then it's none of my $DEITY->damned business - and none of Prokofy's, either - what they do.

Now, he may have a complaint when he says "um, *you* get the fuck out of the public space with your fucking *cult*." It goes back to being about consent: if you're subjecting someone else to watching you whip your slave and they didn't consent to that, then you're violating their right to consent or not.

This isn't as cut and dried as it appears. What's "public"? If I were to rez one of my pieces of bondage furniture in the middle of Help Island, lock a slave into it, strip all her clothes off, and whip her until she made a big puddle of sexual juices on the ground, it would obviously be over the line. But there are many public spaces that are explicitly BDSM-friendly. I have a public playroom full of my furniture, and the public is invited to use it all. Obviously, if you walk in there, you should expect to see the kind of activity I just described, and if you're shocked by it, it's your own fault - and you have no right to demand any recourse other than the right to turn around and teleport the hell right back out.

It doesn't have to go to that extreme, either. There are many clubs in SL, for example, that are explicitly BDSM-friendly. If you go to an event at the Rubber Room, you shouldn't be surprised to see that kind of thing going on, and you have no complaint coming when it does.

I can't tell from Prokofy's ravings whether he merely objects to BDSM outside of that kind of space, or whether he objects to it in SL, period. If the former, then he's got a legitimate complaint. If the latter, then he can kindly fuck off, for this is no different from demanding that gay men and lesbians crawl back into their closet - a demand society is rejecting more and more as the years pass.

From his comments, I suspect it's the latter. Strange that someone bellowing about freedom wants to deny others the freedom to be who they are.

Answering the ProKook, 1 of 2: No, open source isn't communist

Prokofy Neva is a deranged kook. As long as I've known of him, he's had very little to say that has made any sense whatsoever to anyone in even minimal possession of the facts, let alone advancing an informed dialogue. I know of almost nobody who gives him any credence.

He tweeted, a month or so ago,

@damnedgoodesign please point me to a prominent SL furry who is in business, making a profit, and stumping for capitalist policies in SL

My good RL friend Avril Korman, known inworld as Axi Kurmin (and no, I'm not revealing anything she doesn't publicize herself), replied:

@Prokofy I can, but you wont like it. If you want to discuss Real World Politics with @tonyasouther, go ahead. You'll be very surprised.

I rose to the bait. This led to being called a techcommunist who undermines livelihoods and promoting a dangerous cult, that of BDSM. The latest blast was no less than eight tweets, one right after the other.

I refuse to argue this topic 140 characters at a time. As anyone who's read this blog knows, I argue exhaustively, using lots of words and examples and facts, and Twitter doesn't fit my discussion style at all. Hence this post and the next: this one will deal with Prokofy's irrational hatred of open source, and the next will deal with his irrational hatred of BDSM.

I've argued before that open sourcing the viewer is nothing but good for Second Life and Linden Lab. That argument hasn't changed in the seven months since I made it; if anything, it's gotten stronger, because without it, the users of Second Life would be condemned to use a viewer they demonstrably hate. Instead, they're getting a choice, and in Firestorm, hopefully a viewer they love while still allowing Linden Lab to move the platform forward.

Prokofy's argument, insofar as I can make any sense out of it at all, is that "OS undermines business & livlihood everywhere". That argument gets made by people like Bill Gates and Steve Ballmer and Larry Ellison, because open source does undermine their business and livelihood. In the wider world, however, it's demonstrably false.

The simple fact is that, were it not for open source software, I wouldn't be writing this and you wouldn't be reading it. The Internet is powered by open source software. Every last bit of the software infrastructure that makes the Internet work, from the Domain Name System to the Apache web server to the Firefox web browser to the various email servers and clients, either is only used in open source form or else was pioneered and is dominated by open source choices.

I don't know of anyone who thinks the Internet does anything other than create livelihoods and markets on an unprecedented scale.

As I've mentioned before, I'm honored to be able to count Open Source guru Eric S. Raymond as a personal friend. Not only is he an open source developer, he's also a thinker about open source itself and an evangelist for the whole idea. He was one of the founders of the Open Source Initiative and its first president.

Eric is also a libertarian who has said that communism is the greatest evil ever perpetrated. I would strongly recommend that, should you ever have the opportunity - say, at an SF con, which he and his wife Cathy frequent - you not call him a communist, software or otherwise, to his face.

There's a fundamental reason that open source isn't communist: it's entirely voluntary. Don't want to join the revolution? Don't open source your software. It really is that simple. And if you do, nobody but the rabid Stallmanites will argue with you. You see, it's about choice, something that is antithetical to communism. (The Stallmanites want to deny you the choice to buy closed source software, but I've been arguing against them for two decades.)

I chose to open source my furniture script engine for two simple reasons. First, I have long direct experience with the open source development model, and know first hand how well it works. Second, I want to improve the BDSM ecosystem in Second Life.

I know very well that open source development has many benefits, starting with Raymond's Law: "Given a sufficient number of eyes, all bugs are shallow". I've seen this in action more times than I can count. It works for countless open source projects, often attracting developers and assistance from companies that use the software in their products. I'm the manager for an open source project with about 40 developers and tens of thousands of users, and it wouldn't be where it is today if it weren't for being open source.

The second reason is no less important. I take my cue here from the OpenCollar project. They provide a free, open source collar scripting system that has been incorporated into a wide range of devices, not just collars but many other things. My furniture scripting efforts started out from an OpenCollar-provided free script. I've since totally rewritten it, but the basic idea is still valid: having the scripts be open source lets people who understand BDSM furniture design but not scripting make their ideas real - and sell them to others, if they wish. That makes the pie bigger for us all.

If open source undermined businesses, then it certainly wouldn't be used by them, let alone be the basis for corporations large and small. Just ask Red Hat or Mozilla. It's certainly not undermining mine. I choose to compete in the marketplace based on my ideas and my designs, not my script engine.

"Compete". "Marketplace". "Choose". Those are not words a communist would use, let alone embrace.

Am I undermining the market for BDSM furniture in SL? Hardly. Not only do I not sell very much to begin with - I'm not ThinkKink, by any stretch of the imagination - I've enabled others to enter it and sell things. That's an improvement, not a detriment. Even though there are plenty of free OpenCollar-based collars, there are also people selling others. Amethyst and Mars and MoDesign and Dominatech still sell plenty of control devices, and they're not complaining about OpenCollar.

How do they do it? They compete with OpenCollar. They provide better products to their customers, at least as far as their customers see things, at a price that's justifiable for that improvement. They don't try to drive OpenCollar out of existence by complaining about it. They roll up their sleeves and do it better.

So no, open source isn't communist, and it doesn't undermine business. It improves business by freeing it to compete on what really matters to customers: features and price. That's not anti-business. It's pro-business. Yes, some businesses will have to adapt - but that's true of any business anywhere, any time. A business that does not adapt to changing conditions dies. The real reason that Microsoft is so anti-open-source is simply that they cannot conceive of a way to adapt.

Prokofy is arguing the Microsoft side of history. Events are showing that that's the losing side. I wonder if his phone is Android or Windows 7?

Tried fixing VWR-25479, but had a little problem...

After discussing with Arrehn Oberlander last night, I came up with a workaround for VWR-25479. Unfortunately, it didn't work as expected, because the server tries to be helpful.

I've opened SVC-6943 to address the server side of the workaround. I don't know how far it'll get, but I felt I needed to at least raise the issue and get LL's promise not to break 1.23 without an announcement on the record.

LL breaks 1.23 and 1.x TPVs. Film at 11.

Linden Lab has, for the past several months, promised faithfully that they would not break Viewer 1.23, and version 1-based TPVs, until they had made a formal decision to do so.

Last week, they broke that promise.

Viewer 2 version 2.6.3 adds a neat new feature: avatar physics. The feature that gave Emerald, way back when, its biggest boost in users and vaulted it to the top of the heap is breast physics: the ability to make a female avatar's breasts bounce. There are lots of problems with the Emerald implementation, which was carried forward to Phoenix unchanged, but it's there and used. Don't believe me? Just wait till it breaks in one way or another, and see how many complaints surface in Phoenix Viewer Support.

LL implemented the feature themselves, and got it right. This is still a source of endless amusement to me. They put it in the control of the user whose avatar is being shown, and made it work right, and also made more than breasts bounce. All in all, it'a good thing. Even if I still get a giggle out of it.

The problem is that they changed the way that the avatar's description is sent to the viewer. The network message they use to do that hasn't been changed in ages. They needed to extend it to add the new physics descriptions, so the viewer can show it properly. Unfortunately, both 1.23 and Snowglobe are too picky about the contents of that message, and reject it entirely rather than simply ignore the parts they don't recognize. This is also true of every popular TPV out there, all of which are based on Snowglobe 1.5.

Honest mistake, right? Wrong.

Dan Linden's comment on the LL JIRA describing the problem, VWR-25479, is telling:

Dan Linden added a comment - 27/Apr/11 12:49 PM

This is a known incompatibility with 3rd party viewers. We are not going to commit to fixing this.

A known incompatibility? Really? Then why was it rolled out without using the communications channel specifically set up for LL to let TPV developers know of this exact kind of problem?

But it's worse than that. It affects 1.23, too - and it won't be fixed.

How does this affect 1.23 users, and those of V1-based viewers? Basically, if a user of a 2.6.3 or later viewer, or one that has had avatar physics retrofitted (such as Firestorm Preview 3, due out soon, I hope), changes their shape at all, that change won't be shown, and all other users on 1.x viewers looking at that avatar will see the system default hair base as well as any prim hair they're wearing.

Needless to say, this breaks content for the majority of users of Second Life, at least until they move to a viewer with the fix for the issue in it. We're hoping to get out a version of Phoenix that has the fix sometime this week. All current versions of Phoenix, up to and including 1.5.2.1050, are affected by the change.

If you read down to Oz's reply to my comment, you'll see that LL thinks this is a bug that was fixed long ago, and that we should track LL's changes to the codebase. In general, he's right - but how do we find out about other fixes that have been in v2 from before the code was opened up, but aren't in v1? Do we read through all 800K lines of code in both versions, comparing how they both work? That's a superhuman task.

The practical effect of this is that LL has broken 1.23. TPV developers have the fix - literally, deleting 7 lines of code - and will be putting out updates very soon to account for it. 1.23 users have no such update to go to. They've got four choices:

1. Put up with the problem.
2. Change to Viewer 2.
3. Change to a TPV with the fix.
4. Get off of SL.

Which choice they'll make depends on why they're still on 1.23. If they're there because they saw no need to update, they now have one, and will move. If they're still there because they can't stand Viewer 2, then they'll either pick a TPV or else get off of SL. If they're still there because they're a casual SL user, they might update - or might simply say "screw this!" and get off of SL.

In any case, LL, for better or worse, has now decided, unofficially or otherwise, to break 1.23. They're gong to have to live with the consequences of that, and not get the benefit of having done it in a deliberate manner with plenty of warning for folks. I hope it works out for the best, but I'm not as hopeful as LL appears to be.