The clock is officially ticking

At yesterday's TPV meeting, Oz Linden gave TPV developers notice: the server-side baking code is now in the queue to be rolled out to the grid. Here's the announcement he sent to the TPV developers list:

We have now made available the code for our upcoming server side baking changes - you will need to update to be compatible with this in order for users to see avatars correctly once the server side change is rolled out to the main grid (some time > 8 weeks from now, but no date has been set yet). 

See https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance for information on this new code, and watch it for updates.

As Oz said in the meeting, the clock is now ticking. We asked for at least two months' notice, and yesterday we got that. LL would like to roll the code out to the grid in February, but they'll work with TPV developers to make sure we all have had the code and a good chance to implement it before they actually roll it out.

Why are they being so solicitous? Because this will break every existing viewer. Any viewer that does not have the new code in it will see every avatar that connects to Second Life through a simulator running the new code as either a cloud or as a gray shape. This means you will have to upgrade your viewer sometime in February or early March. No exceptions.

This is not news. Oz first told us of this change back in July. I said then that that put Viewer 1 on borrowed time, and I meant it. The loan is about to come due.

There have been a lot of vocal folks telling me I was lying about Viewer 1 being a dying codebase. Well, folks, you've been wrong all this time, and now it's time to shut up. These changes will be extremely difficult to backport to version 1 viewers, because LL refactored most of the avatar appearance code to let them split out the parts that do the baking. It's not a drop-in replacement.

Siana Gearz yells at me whenever I speculate about the maintenance load of Singularity. Still, I think they've got quite a substantial amount of work ahead of them. Henri Beauchamp did recently implement the Current Outfit folder in CoolVL, so he's at least got that work behind him.

And Phoenix? Stick a fork in it. It's done.

We've been saying for a year that we will not put any more significant effort into Phoenix. Adding the server-side baking code to it is a significant effort. We've got our hands full with Firestorm, and none of the developers has any desire to take time away from that and update Phoenix.

That's why we announced at today's Phoenix Firestorm Office Hour that we are ending support for Phoenix at the end of the year. The support team doesn't run it or know it very well any more, and the development team is heartily sick of patching it together one more time.

LL is not going to block older viewers. As Oz said at the meeting, "if you want to live in a world of gray, cloudy avatars, that's your choice - if a weird one - and we're not going to stop you." Similarly, we are not going to block Phoenix, or even remove the download. If you want to stick with it, go ahead - but don't complain to us when you can't see your friends.

If you want to still see everyone else, you will have to upgrade. There are folks who will be diehard V1 users and not even consider Firestorm or any other V3-based viewer. There are V1-based options for them; Phoenix will simply not be one of them any longer. For the rest of you, I strongly recommend you switch to Firestorm now so you can learn its ins and outs at your leisure instead of having to do it under the pressure of not being able to do anything on Second Life, period.

And for those of you whose computers are so old you can only run 1.23 or older Phoenix? Sorry, folks, but you will have to spend some money. There's no way around it. It doesn't take all that modern a computer to run Firestorm, but it does take one that's newer than 2003. If you can't swing that, then I'm sorry, but the platform has moved on and left you behind.

We've known this day was coming for a long time. So has anyone who was not willfully blind to it. I have no sympathy for the latter. Upgrade or leave, your call.

LL shoots itself in the ass again: public JIRA is closed

Today, Linden Lab closed access to their JIRA. Anyone can still file bug reports, but only the one who filed the bug can see it outside of LL. This has always been the case for a few JIRAs, such as the ones in the SECurity category, but now it applies to all of them.

This is only going to hurt LL. It will cause many, many more duplicate JIRAs for them to sort through. Right now, it's common and good practice to search for an existing JIRA to make sure that the problem you're about to report isn't known. That will go away.

There's also a bunch of people who watch the LL JIRA and help with triaging, work with reporters to make sure the needed information it present, and suggest fixes without ever writing a line of code. Those folks just got the finger.

And, as I said in my last post here, having the JIRAs be secret hurts TPVs, too. It makes it much harder for us to know whether the bug we're hunting is a LL bug. It also makes it harder for us to realize that we just fixed an LL bug and contribute the fix back to them. They spend a lot of time assuring us they want our contributions. This change makes that much more questionable.

The stated reason is that the change will make the process easier for reporters. My guess is that it will: it'll be so much easier when bug reporters give up because their bug reports get ignored in the flood of duplicates and support requests that aren't bug reports and anything else.

I've heard speculation that this change is because the online games don't have publicly accessible bug trackers. Given Rod Humble's background, this reasoning certainly is plausible. The problem is that Second Life, fundamentally, isn't a game. It's a community. The more LL forgets that, the more they alienate users.

This is a poorly-thought-out change. It needs to be reversed, ASAP.

How to screw up a release

As I write this, the QA group is beta testing Firestorm 4.2.2.29837. This has been one hell of a long day.

Yesterday, we were all hopeful and happy that we'd gotten 4.2.1 the hell out the door. We'd been beating on it to get the pathfinding tools in, and a bunch of crash fixes and translation updates and a few very highly requested features (control-shift-E for Edit Linked Parts being my primary original contribution, though I also ported the Flickr snapshot upload from Exodus) as well. We QAd it, we beat on it, everything looked good. We pushed all the needed changes to the various repositories, told the users to grab it and have fun, and went to bed.

I got up about 5:40 AM my time (US Central, GMT-6/SLT+2). When I sat down in front of the computer, I saw in the support chat that there was a problem. It turned out that 4.2.1 has a bug in it that makes most swinging doors not look like they act correctly (though they actually do). They appear to swing normally, then jump ahead, swinging farther all at once.

You can guess how many swinging doors there are in SL. You'll probably guess low. No, I don't have a number, but it's gotta be astronomical.

The thing that annoyed me especially: The front doors on my own house showed the bug! Worse, I'd noticed the issue a week or so ago, and blown it off!

Fortunately, our ace support person and walking JIRA encyclopedia, Whirly Fizzle, had already found the changesets that caused the issue. I whipped up a quick build and saw that yes, backing them out did fix the problem. A bit more jockeying, and I had a recommended course of action: back out three changesets directly in the release branch of the repository, bump the version number to 4.2.2, and ship it.

Oh, if it were that simple.

First, the build servers were behind a fiber cut as a result of an automobile accident in Boston. That delayed spinning the new release builds.

Then, while we were waiting on that, we discovered another problem, with another patch: some spinning objects stuttered and didn't show correctly if they updated while spinning. This is the problem that the patches we backed out were supposed to fix. We found the changeset that caused that and backed it out, and it seemed to fix the problem, with no side effects.

But we couldn't be sure. The LL JIRA that that changeset was reported to fix, PATH-542, was (and still is) secret. So how the hell do we decide? Have we reached the end of the string, or are there nasty side effects of not fixing that one? Without knowing what the problem is, we can't make an intelligent decision on what to do with it.

We spent a large chunk of the afternoon trying to figure out what to do next. This time was completely wasted because of the JIRA being kept secret. Finally, about dinnertime, we got enough of a hint as to what the problem was that we were able to exercise it - and decide that not only was the original behavior not a bug, at least at the level of the Firestorm codebase (LL 3.3.3), it was actually the way things should behave.

So we declared it fixed and built release binaries. That's what QA's poking at now.

Jessica Lyon is not at all happy that we had to back out a release. I'm not either. Worse, I feel some responsibility for not saying anything.

Where did we screw up? To examine this, we need to detour for a moment into the world of fail that's been the LL pathfinding release. The pathfinding code has been rather epically broken at just about every step of the way. The problems ranged from broken physics to sitting on the ground failing in rather entertaining ways to the world and minimaps being mis-scaled to the toolset in the viewer being very, very unstable. (This is the reason that LL 3.4.0 is taking so long. It's really, really not pretty.)

We fought a lot of this while putting the pathfinding tools into Firestorm. We saw the effects of a whole bunch of these problems, to the point we got to thinking "Oh, something else broke? Must be pathfinding fail." That is exactly what I thought when I saw my front doors broken a week or so ago...and it cost us.

I'm not the only one. More than a few of the support folks and beta testers report the same thinking.

The lesson is obvious: Even - no, especially - when dealing with known LL fail, we need to investigate every problem we see. No matter how much it seems that it's just another LL screwup. Every problem. Period.

There's another lesson, and that's that LL's entirely too secretive when it comes to many bugs. Yes, I can see keeping details of LL's infrastructure secret, and it goes without saying that SECurity JIRAs need to be secret. There's simply no good reason for the others, though, especially once they've been fixed. The only reason is to keep TPV developers in the dark and make us reinvent wheels.

I hate reinventing wheels. If you're lucky, you end up with a pentagon.

So here we are; before I go to bed, 4.2.2 will be released, full of goodness. But a lot of us wasted a lot of time because nobody said anything about a bug many of us saw. That's gotta stop. It will stop.

Viewer 1 is officially on borrowed time

At today's Third Party Viewer Developers meeting, Oz Linden announced three upcoming changes. (The audio recording of the meeting can be heard from the archive here.)

1) Pathfinding. The pathfinding code has been rolled out on the Magnum RC channel, after a few false starts, and seems to be running well. The pathfinding tools will soon be released in source form for integration into other viewers. They'll be needed to edit the pathfinding properties of objects, and to trigger a rebuild of the navigation mesh that pathfinding objects use to move around.

2) From the Shining Project, an overhaul of the HTTP interface in the viewer. The code has been completely reworked. The new code fixes many, many HTTP bugs in the current viewers - but it's incompatible. It'll go on a new TCP port. It'll also not work very well with older consumer WiFi or DSL routers.

3) Also from the Shining Project, server-side baking. Currently, your shape and hair and system-based (but not prim-based) clothing are all initialized and merged together by your viewer and then uploaded to the servers. This is known as baking, and when it doesn't work, you get bake fail. That's what produces the orange clouds you see when someone logs in sometimes. The new code will have your viewer attach whatever, update the Current Outfit folder, and then notify the server - which will then turn around and notify an internal server that does the actual baking. This should eliminate bake fail. However, once again, it is incompatible with current viewers.

The second and third changes are longer-term. Oz said that we should plan for two to six months; I don't know if that estimate is better than Linden Lab's historic estimates (which tend to be optimistic), but we should plan on their being accurate.

The result of the final cutover to the new HTTP library is that the viewer won't be able to communicate. The result of the server-side bake is that viewers that don't handle it will simply see gray avatars, with no way to fix them.

Needless to say, there will be plenty of warning before the switch gets flipped. Oz committed to giving us at least two months' notice, unless he is unable to convince higher ups that they need to give us that after making a decision to switch faster. There's not a lot he can do in that case.

When it does, though, viewers that have not been updated will simply refuse to work. 1.23 will not be updated, and this will spell the end of it on Second Life. Older versions of all other viewers will also stop working. Viewers that are not actively maintained will die off.

We will, of course, be fully ready with Firestorm, assuming that Linden Lab gives us enough lead-time to actually integrate the code and release with it before they flip the switch.

Other folks may choose to make the necessary adaptations to work in the new environment. It will be interesting to see whether Henri Beauchamp implements the new bake, since he doesn't like the Current Outfit folder and went to some lengths in CoolVL to avoid having to use it. Some viewers are in active development, and I expect them to continue. However, the only V1-based viewer that will survive is Singularity, I expect, with the possible exception of CoolVL. I expect Siana Gearz to do the needed work as soon as the code's available. Nobody else is developing a V1 viewer any more.

Phoenix is a more interesting question. Just in case there's any doubt, what I'm about to say is my own personal opinion, and not that of the Phoenix Viewer Project. The group has not made any decisions yet.

To me, it's time to say that we are not going to put any more effort into Phoenix.

Yes, that's right. As far as I'm concerned, it's time to put Phoenix to rest. The developers don't like working in the codebase, as in many ways it's an unmaintainable tissue of hacks, the support team barely remembers how to run it, and Firestorm now provides essentially all of the function Phoenix has and much more besides. There's even a selectable interface that caters to Phoenix users. (If you are one of those, select Phoenix mode at the login screen. Have fun.)

I realize this will be an unpopular change, especially for folks who refuse to run Firestorm or any other V2/V3 viewer. However, there comes a point when making an old program run in a new environment simply isn't feasible. We're a volunteer project. There's essentially nobody here who wants to keep putting effort into Phoenix any more. Firestorm does everything that Phoenix does. (Two exceptions: OTR IM encryption, which a small but very loud fraction of users want, and object import/export and some build tools that depend on it. I expect both to be in Firestorm by the time the incompatibility switches get flipped.)

There are some folks whose creaky old computers won't run Firestorm. Guess what, folks? It's time to upgrade. Past time. If your computer isn't hopelessly low-end and was built in the last 4 years or so, it'll run Firestorm. If not, then it's past time to upgrade anyway. Yes, I know this is hard-hearted sounding. It's also simple reality.

There are other folks who swear up and down they'l never run Viewer 2 or its descendants. Well, folks, your bluff is being called. You've been saying you'll leave SL before you'll run Viewer 2. It's time to shit or get off the pot.

Me? I'll be happily running Firestorm 5. (Or whatever we choose to call it.)

A gorgeous necklace

Just gotta show off a lovely necklace Axi Kurmin gave me. It's from her jewelry store, House of Rain, and it's called - you guessed it - Phoenix. This one's in gold with onyx and citrine inset in it. Perfect colors for a tigress.

Thanks!

How to be an open source asshole

Not too long ago, a couple of folks have released forks of Firestorm, taking the source we've put a year of hard work into, making their own changes in it, and releasing it under a new name.

There's nothing wrong with that. It's an essential part of the open source software model.

What is wrong is that, in both cases, they did the open source equivalent of filing off the serial number: they removed any credit to Firestorm and its contributors. In essence, they claimed credit for the work themselves.

That's beyond the pale.

There are three main reasons people work on open source software: scratching their own itches, helping others, and gaining a good reputation in the community. The first two are obvious. Every Firestorm developer has added features or fixed code to do something they personally want to see done; the best examples are Zi Ree's Phoenix emulation and animation overrider, and Tozh Taurog's LSL bridge. The second underlies what all of us get out of it, to one degree or another. It's not entirely altruistic. We get warm fuzzes from people thanking us for the work.

The third one is what the two forks have destroyed. As much an economy as open source has is based on credit for work: not monetary credit, but reputation credit. I've cited open source guru Eric Raymond's essay Homesteading the Noosphere here before. In it, Eric describes what drives open source developers as a gift economy: people give away their work in return for credit, thereby enhancing their reputation in the community.

That means that removing credit for work is as close to theft as you can come in the open source world.

There have been complaints in the past that we have not properly credited others for their own work. This has been unintentional, and rectified as soon as the issue was raised. We proudly and happily acknowledge the work of others that makes its way into Phoenix and Firestorm to the best of our ability.

I don't know if the offenders have put the credits back. I suspect one has not; she has shown an ongoing pattern of taking others' work and removing credits before distributing it. The other is reported to have taken down his entire codebase, or at least have made it inaccessible.

One of the two claims that some developers asked him to remove their credits in his codebase. If someone asks that their credits be removed, that is their right, and he would be right to comply. I find the claim difficult to believe, however.

I would personally not consider using either viewer, myself. If they're willing to steal credit for others' work and break the norms of accepted behavior in that way, what else are they breaking?

I considered naming the two viewers and their developers. I decided not to. They have a tiny number of users, and I decided that naming them here might induce others to try them. If you encounter a viewer that looks a lot like Firestorm, though, I would strongly recommend checking the credits section first, and if the Firestorm team isn't credited, run the other way fast.

Death Sold Light Beer

My roommate, the incredibly silly ox, was one of an apparent multitude of folks who heard the chorus of Faderhead's TZDV not as "Tanz zwo drei vier", as intended, but as something else. In his case, it was "Death sold light beer".

This caused a stir around Gothika. One denizen in particular seemed to complain that she couldn't get that out of her head. Naturally, I had to turn that line into a full set of lyrics. Enjoy.

DSLB
Lyrics by Tonya Souther
With apologies to Faderhead


This is a song about the football clubs
This is a song about the drunk
This is a song for everyone who chugs
The barfers ride home in the trunk
This is a song for all the cheering fans
This is a song for all the geeks
This is a song about the scoring drives
This is the time to drink the yeast

Chorus:
And I say
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
And I say
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)
Death sold light beer (light beer light beer)

This is a song for all the college kids
This is a song to make you fart
This is a song about fermented rice
This song's officially fine art
This is a song for all the booing fans
This is a song for all the geeks
This is a song about the sticky floors
This is the time to drink the yeast

Chorus

Miller beer
Coors beer
Heineken beer
Foster's beer

Miller beer
Coors beer
Heineken beer
Foster's beer
Death sold light beer

Chorus
And I say

Death sold light beer (light beer light beer)
And I say (beer light beer light beer light beer)

Building with mesh

I've been skeptical that I'd be able to deal with building with mesh ever since it was announced. I didn't see the point, and didn't think the tools were something I could learn to deal with. Over the past couple of weeks, I've changed my view.

I had thought that the only tool that I could use without spending piles of money I don't have would be Blender. I hate Blender. Blender is as user-friendly as Viewer 2 is popular among long-time SL users. Every time I run it, I want to throw my screen out the window without bothering to open it first. The official tools, like Maya or 3DStudioMax, are far out of my price range.

Then I got interested in sponsoring World Goth Fair 2012, a monthlong event run by my good RL friend Axi Kurmin to benefit the Sophie Lancaster Foundation. That's the kind of charity I can get behind, and I was happy to plunk down the sponsor fee and pledge a substantial portion of sales to the foundation's benefit. There's just one problem: None of my furniture is gothy.

I'm not a goth. I know bupkis about it, myself. My furniture design principles are simple, clean, and functional; I build with 2-inch aluminum plate for a reason. I've gotten pretty good at slinging pims, to the point I prototype that way. I've got a well-developed set of design rules I stick with when building furniture. They won't work for this fair.

I asked Axi at one of her world-famous Wednesday evening 80s sets at Gothika what I needed to do to make gothy furniture. My roommate, an incredibly silly ox by the name of Orvan Taurus (yes, he really is silly. Ask anyone but him.) chimed in with "anodize the aluminum". Axi said "you're not far wrong." Oh, really? Maybe I can do this. Axi showed me some furniture samples and explained what they were derived from. That didn't look too bad, so I whipped up a Gothic equilateral arch out of prims, ran them through a prim oven, and ...it almost came out usable.

Almost. The texturing had obvious seams. The point at the top of the arch where the arc prims met was just terrible-looking. When I applied my standard metal texture, it just plain sucked.

All right, time to bite the bullet and try mesh. Axi had suggested Google SketchUp as a mesh building tool. It was maddening at first, but the learning curve looked like it was actually surmountable. I made up an arch or two and they actually looked good when imported into Second Life.

Still, the project languished, until I realized I had another learning opportunity. Linden Lab was sponsoring a design competition to replace the theater used for Third Party Viewer Developers' meetings, and one of the requirements was that it had to be mesh.

I spent an evening, and then a morning, struggling up SketchUp's learning curve, but finally figured out how to do it. I came up with a simple, functional, usable mesh theater, with seating for 36 and a nice screen to show web pages on via Media on a Prim.

When it was done, I let my friend Helena Lycia at it. She's an experienced, accomplished builder. I thought I'd done well. She showed me I hadn't, and how to fix it so I did. I started out with screwed up physics and a prim equivalent of 209. When she was done, the physics were fixed and the land impact was down to 108. I took her lessons and redid things myself, and while I couldn't make 108, I did get it down to 114.

There's one step I don't like very much, but see the necessity for. SketchUp groups things in such a way that one of the chairs, for example, takes up several actual mesh objects. Helena showed me how to post-process it so that it takes up just one object - but the post-processing has to be done in Blender. Gah. At least it's mechanistic, so I don't have to actually deal with the damned Blender UI for very much.

(Aside: Firestorm doesn't do as well as LL's viewer at uploading mesh and getting the physics right. I'm hoping the Havok sublicense will fix that. There's another problem, too, and it boggles me pretty thoroughly: Analyzing the same mesh object for upload cost and PE 10 times will produce 10 values with more than a 50% difference from one end of the range to the other. How the hell can they make the process THAT nondeterministic?!)

I probably won't win the contest. Another entry is much more impressive technically, and since the contest criteria include "a showpiece of Second Life design", simple and functional won't get it. That's all right. I needed the learning experience.

(EDIT: No, I didn't win. I did pick up the L$1000 runner-up prize, and Oz nabbed a copy of it to put in Hippotropolis, on the other side from the official theater. I'm happy with that outcome.)

Now to go back and build the furniture. I've got a couple of weeks yet, and I'm sure I can build several pieces now that I know how to go about it.

The Lab gets one right

At last Friday's Third Party Viewer developer's meeting, Oz Linden announced an upcoming program to let TPVs sublicense the Havok libraries that LL is using in the viewer. This is a good thing, and LL deserves to be applauded for getting this one right.

LL uses the Havok libraries in the viewer for two things: to do some analysis on mesh objects at upload time to assess their costs on the SL infrastructure in order to assign a prim equivalent (PE) value, and to edit the mesh used for the pathfinding feature currently in development. TPV developers have worked around the first library, with results that are usable if not as good as LL's; the second is very new - large parts are still in development - so that we haven't had a chance to do so yet.

Havok is the physics package used in SL. It's hideously expensive. LL uses it because they have to. TPV developers can't afford it themselves.

I'm very pleased that LL found a way to let TPVs sublicense it. I'm sure it cost them some extra money. It also requires that they place no small amount of trust in TPVs not to let it leak to unauthorized people. For those who think LL would rather see TPVs wiped out, this is a clear demonstration that it's nowhere near that simple.

The sublicense carries with it some pretty substantial restrictions:

1. The viewer it's part of must be LGPL, or licensed under some other license that allows linking with closed-source libraries. As Oz put it, "we're not going to help you violate the terms of your license." As a practical matter, this means that GPLd viewers need not apply. That, in turn, means that no V1-derived viewer is eligible, since those are all GPLd. The Exodus viewer is not eligible either until they finally relicense themselves under LGPL - which will let them join the TPV community instead of merely taking from it.
2. Be listed in the TPV Directory. This one matters because it gives LL some recourse if the library leaks. I would presume that each TPV's copy of the library will be stamped in some way that lets the source of a leak be traced.
3. Be substantially based on current LL code for those things that use Havok. I'm not sure just how strictly this one will be interpreted, but it can be read to mean that the TPV has to be fairly close to the current released LL viewer.
4. The linked page says "be focused on Second Life". The actual license is stricter than that: paragraph 1.1(b) of the agreement says "Sublicensee must require the Third Party Viewer to connect only to servers owned or operated by the Company". We don't know yet whether we'll have to rip non-SL grid capability out of Firestorm yet to use this license, or if simply disabling the code if the viewer is not connected to SL is sufficient. We're really hoping the latter, as we're not going to drop OSGrid support for this or any other reason. If we can't, we'll have to produce two versions, one with and one without.

I don't see the restrictions - especially number 4 - as being a major deal. Looking at it from LL's perspective, it would make no sense at all for them to spend money on the library sublicense agreement with Havok only to have TPVs use it to help out their competition!

This is a very positive step for LL to take for TPVs. I'm pleased, and hope that more goes this way. It shows a true partnership between the Lab and TPV developers, something that's been lacking ever since the last round of TPV Policy changes.

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.