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.