Final releases usually aren't

Sigh. By now, if you've been following the saga of Phoenix, you know that 725 was less than a total success. We put a lot of work and fixes into it, and pushed even harder to release 818 by Christmas.

It's better, but it's still got bugs. (Film at 11.)

The only program that's bug-free is one that's never used. Just as with any other human endeavor, no program is perfect. There are bugs left in Phoenix that need fixing, mostly in the areas of RLV, texture video memory management, and the new inventory system LL keeps trying to push out, AIS.

At this point, however, Phoenix is feature-frozen. It will get bug fixes, but no new features, at least officially. (I can't speak for Jess, but I expect that new features that can be dropped in without significant effort will be added - as long as they're added to Firestorm first.) All new feature development will happen in Firestorm, and only get backported to Phoenix on a time-available basis.

The difference between now and a couple of months ago, when I first said that we weren't feature-freezing Phoenix yet, is that the developers believe that the major features that can be added to Phoenix have been. In particular, display names and multi-attach are in and working about as well as they can be. We're also tired of chasing some persistent bugs that simply don't exist in the V2 codebase.

Even so, as we fix things, there will be more releases of Phoenix. We hate having a viewer out there with problems as much as the users hate having to deal with problems. This is a final release only in that new versions likely won't have significant feature additions. There will be bug fixes, at least until Firestorm reaches production release status. Once that happens, though, expect Phoenix to be finalized.

Release early, release often

One of open-source guru Eric Raymond's favorite sayings is "Release early, release often". This appeared originally in his seminal work The Cathedral and the Bazaar, which should be required reading for anyone doing open source development.

This has relevance to the current state of the Phoenix Viewer project. The release of 1.5.2.725 - what we're calling a release candidate, mainly in self-defense - was delayed by quite a bit of time relative to our previous schedule of releases. We kept adding features and fixing bugs and introducing more bugs and adding features and introducing more bugs and fixing bugs. Part of the reason there is that the release was delayed for a while, waiting first on my fix of a nasty texture upload issue, and then the completion of the parcel Windlight settings feature.

Regardless of the reason, the end result was the same: we wound up having to do a lot of debugging, and releasing with bugs we'd rather have fixed.

The answer is in Eric's dictum. Releasing early and often both tends to compartmentalize the addition of features and the corresponding bugs, and also tends to make bug resolution easier and closer to the introduction of whatever caused the bug. On top of that, it also reduces the pressure to just push something out before it's really ready, by keeping users happy that features are being introduced and bugs fixed on an ongoing basis.

A case in point here is the support for Display Names. The original feature was added by a developer scratching his own itch. As I've said before, that's the norm in open source development. The feature was originally added to just show the display name int he user's tag and profile, and tested that way. One user submitted a patch, after that version went out in beta test, to extend the reach into local chat windows - but we couldn't add it, at that point, because we were trying to lock it down tighter for the formal release of what became 725.

Then we had a couple of showstopper bug reports - including one that was submitted to us that we agreed to fix before the release, but that apparently didn't satisfy the user, who submitted an abuse report with Linden Lab over it! (I really, really hope I don't find out who that idiot is. He caused a lot of needless pain and agony.) Those delayed the release even further, and got in the way of proper beta testing as we quickly approached the deadline we'd publicly set. The result was a release candidate that isn't bad, but has a few noticeable bugs that really should have been caught before release.

The answer is to release much more often. No, I'm not advocating public betas. What I am advocating is that we release whenever a major bug is fixed or a significant new feature is added and tested. This shouldn't necessarily happen on any fixed schedule, but rather as we get the work actually done. Releasing to a fixed schedule leads to putting things out before they're ready, and rushing to do so - with less-than-optimal results.

What of Firestorm? We're faced here with two conflicting demands: a group of users who want it, and a group of users who will only use it if it's been sufficiently de-sucked. The fear is that waiting long enough to satisfy the latter will cause the former to go off to something else, while satisfying the former runs the risk of the latter trying it, saying "This is just like Viewer 2! This sucks!" and never trying again.

I would argue that we should err, once again, on the side of releasing early and often. We should also make it plain to the latter camp that Firestorm is very much a work in progress, and that nothing is nailed down until the users are happy - so, like the weather in Houston, if you don't like it, just wait 10 minutes and it'll change. That has two benefits: it gets us people actually finding bugs, which is the true power of doing open source development, and it shows the user base in a concrete manner that we are indeed listening to their concerns and working to fix them.

Will we irritate people? Yeah. I think we're going to do that any way we cut it, and that this approach will cause the least total irritation in the user community of anything we might do.

De-sucking Viewer 2

With the impending release of the next version of Phoenix, the team is beginning to turn its attention to Firestorm, our version of Viewer 2. We're just beginning the process, and there's a lot of work to do. Even so, there's already been significant de-sucking done, as this screenshot will show.

The biggest overall complaint is that Viewer 2 wastes immense amounts of screen space, between the sidebar and the separate IM and local chat floaters and the UI design that puts huge borders everywhere for no apparent or good reason. As that screenshot shows, we've already gotten local chat docked into the IM window, with vertical tabs, as in Phoenix, and a separate inventory floater like the one in version 1. That screenshot is already very reminiscent of the way I lay out Phoenix's user window.

This is very preliminary. We haven't really devoted much thought or design effort to Firestorm, as yet, and so any or all of that can change. We also have a lengthy list of features to examine, adapt, and port to the new codebase. The whole developer community uses Phoenix's feature set above and beyond that of the base viewer. To be sure, we all use different parts of it, but if there's a feature in Phoenix, there's a member of the team that uses and knows it.

We're not going to put out a viewer we won't use ourselves.

In addition, the members of the development team have a wide range of experience within SL, and the folks we know have an even wider range. For example, I personally know one of the biggest vendors of clothing in SL. As far as I'm concerned, Firestorm isn't ready for prime time unless he can get his job done as easily as he does today, with the minimum of learning curve to surmount. (He doesn't have time to spend learning another way of working. He's too busy creating.) The same goes for folks in many other realms of SL.

No, Firestorm isn't going to happen overnight. There's too much to de-suck, for too many people. I don't expect even an alpha version to be available to the testers for quite some time. I can promise this, though: When it does come out, it'll be worth the wait.

"It's the official viewer; get used to it!"

I commented in a discussion elsewhere that I felt mesh wasn't going to take off because it wasn't going to appear in popular TPVs for months yet. That drew a reply basically saying Emerald was eeeeevil for putting out multiple attachments before LL did it, and all it did was make content creators' jobs more complicated, ending with "Plus last I checked, it's Linden Lab who decides the official stuff. Don't like it, don't log in."

The user under whose account that was posted - not the one doing the posting - asked people not to start a flamewar there, so I sent a private message asking him what his problem was. That drew this reply:

Ok, let me put it like this.

Back when Emerald had an update done, it caused major issues with our products. Soon people just began to state that our stuff was broken. The problem was that our stuff wasn't broken, the viewer just SUCKED!

It isn't MY job to make sure my fucking crap works for EVERY viewer! That is NOT my job and it isn't even listed in the TOS! Until it does state somewhere that it does, I am NOT going to fix my stuff for anyone's misfortune JUST because they are using a TPV! Don't like it, download 2.0 and shut it! This whole thing began to occur again when we started to distribute alpha layers. We made them optional, but people complained EVERY DAY about how they'd get harmless errors, but said that it was SOMEHOW preventing their product from working (which was bull crap!).

Bottom line is that I don't care what viewer is mostly used on the grid, and last I checked, since the Emerald fallout, some of them even began to use 2.0, some went to (of all things) (please get rid of this viewer if you can, it'd do us all a favor) (not kidding) (still reading?) Accent, Kirstens, or Phoenix. The other bottom line is that Linden Lab is the hosting service and the main creators. Everyone is whining and moaning about 2.0 and it's new interface all because people are lazy and don't want to learn how their buttons were just made vertical (with another button added). All in all, it's the official viewer; get used to it!

Now onward towards your Emerald dealing. Biggest wrong move ever! Emerald made their multi-attachment, but Linden lab asked them to remove it because they were planning to release the multi-attachment for premium users! It was swapped around to make it seem that Linden Lab was trying to stop Emerald and people threatened to leave, so Linden Lab stopped.

As for viewers that can't render Meshes, last I checked, Kirstens(S21) works pretty damn good on my machine. (Also, I'm a developer for god's sake! I know what the hell a mesh looks like when you don't have the ability to see them!)

To quickly summarize, it doesn't' MATTER who uses meshes or not! When people see how much higher quality they are compared to most other avatars, can't make it work, and ask why, they can't ask for a refund because the sale was legit and the product DOES work, it's just the moron is using a TPV that isn't up to date. That would never be my problem, and I don't care, because that is just how the damn real world works!

Hoo boy. Where to begin?

The overall thrust of this guy's argument is that we should take whatever LL chooses to give us. Step over that line, and we're nasty, eeeeevil folks who make everyone's lives harder. Never mind what the users want or don't want. Just eat your Brussels sprouts.

The fundamental thing this guy is forgetting is that we're here to serve the users, just as he is in his business. Everything that was added to Emerald, and now Phoenix, is there because users wanted it. Multi-attach is a case in point. Yes, Linden Lab finally added the feature, and got it right (and that, in itself, is an exception). The problem is that it took them six months to add it to a released viewer after Emerald had added it. This pattern repeats endlessly.

When LL does add a feature, they get it wrong more often than not, sometimes quite badly so. Display Names is just the latest notorious example. What users wanted was a way to change their existing account name, because their original choice, made before they understood what the name choice meant, sucked, because they were partnered, or for role-playing reasons. What we got, instead, was a way to impersonate someone else that didn't address what the users were asking for in the first place.

Of course, everybody knows Viewer 2 sucks. It's the poster child for what the user community thinks is wrong with LL. They tried to tell us what we wanted, instead of listening to us. The result is a classic disaster that has convinced a major part of the user community that LL fundamentally doesn't care about them. They're slowly de-sucking the user interface, but the users are voting with their feet: over twice as many users use viewer 1 based viewers as use V2-based viewers, and the current version of Phoenix is the most popular viewer on the grid by nearly a factor of 2 over any version of V2.

It's about what the users want, not about what LL tells the users to want. We're adults. We know what we want. Telling us to shut up and eat our Brussels sprouts is not going to go over well, be it from LL or a content creator who doesn't want to do the work needed to serve their users.

I'm not in the market for a new avatar - I'm quite happy with the AnthroXtacy tigress I wear - but if I was, I wouldn't buy from this guy anyway, if I knew who he was inworld. I deal with businesses that serve their customers, not dictate to them.

How easy is it to be evil?

Very easy. I got a notecard advertising a product to find out whether any user is online or not, by way of a chat command, for a mere L$150. I thought about it a while, and then used code snippets from the LL wiki to whip up a script.

The code to do the job is 129 lines of LSL, about half of them comments, and I didn't try hard to write compact code. (When I write programs, I come at them knowing that I'll have to come back and answer the question "Why the precise hell did you do it that way?!" in five years or so. When you look at it that way, clear and concise beats efficient but impenetrable every time.) The only magic here is in getting the key from the avatar name, and that I lifted straight from the LSL wiki.

There's a tiny but very loudly vocal minority of folks who claim that this code is evil, and that the Phoenix Viewer is evil for providing an equivalent function right in the profile display. Their ire at the Phoenix team is misdirected. If they don't think that this kind of thing is appropriate, then they need to convince LL to change the behavior of LSL. There's a JIRA to do just that, SVC-4823. It's only gotten 14 votes as I write this. Maybe, just maybe, the number of users who really care about this is a lot smaller than the loudmouthed kooks think.

In the meantime, I refuse to sit still while people call me evil for doing something that's both explicitly allowed by LL and done in many ways by many other people. This script is no more evil than a pistol is evil. It's the user, not the tool, that is good or evil; a tool simply is.

Here's the offending code, after the jump:

Pushing to release

The Phoenix Viewer team is pushing hard to get a beta of the next release out. We've been working on bug fixes and ironing out a few features where they haven't interfered with getting the release more stable.

This release is intended to be the last one before we turn our attention to Firestorm and de-sucking the Viewer 2 user interface. As such, we're trying hard to get as much into it as we can. One of the biggest feature additions is Display Name support. It's not as extensive as the one in Viewer 2; in particular, it doesn't put the DN in chat or IM texts, or on your friends list, but it does show it in tags and profile views and object ownership and things like that.

The guy who implemented this is our QA lead, Wolfspirit Magic. He's earned a developer tag for it. This is a classic case of an open source developer scratching their own itch, but it turned out to be prescient when LL released DN gridwide a week or so ago and then, a couple of days ago, flipped the switch and changed registrations to a single username instead of the old Firstname Lastname system.

There's some confusion about how to use a new-style username with existing viewers. If your viewer has a Firstname Lastname login window, you need to put your username in the Firstname field, and the word "resident" in Lastname. This will be true of Phoenix in the next release. We decided not to change the login window at this stage of the development cycle. It would have caused too many changes to the login manager, and especially the part that maintains saved logins.

We've gotten requests to add things, as well, even pretty recently. An example was a request that came in just yesterday to add the OpenSim LightShare feature to Phoenix. I sympathize with the submitter who says that not having it will hinder Phoenix's adoption among OpenSim users. He may well be right. However, that's a feature that, again, will take more time to code, integrate, and test than we have available before the beta is cut.

I keep mentioning the time available. It's short: we're planning to cut the beta version Sunday evening, let the beta team pound on it for a week, and if everything goes well - not at all guaranteed - then release Thanksgiving weekend. We haven't released a new version since 373, almost a month ago, and that's getting to be just too long. I believe in the bit of open source wisdom that says the best release policy is "release early and often"; that's not quite as practical when your userbase is measured in the hundreds of thousands, but is still sound advice.

The big change people will notice in the next version is multi-attachments. Henri Beauchamp's patch was imported, and extensively worked on to improve and extend its function. The old secondary attachment points are being deprecated, as well. If you have attachments on secondary points, Phoenix will migrate them to the corresponding primary point and attempt to put them in the same place on your avatar. You may need to do some minor tweaking, but should only have to do it once. The good news is that Phoenix will still display secondary attachments on other avatars correctly. The new system is also compatible with the one used in Viewer 2.

This is planned to be the last major release of Phoenix. Once it's out, we'll start in on Firestorm in earnest. Phoenix may get bugfixes, especially for high-impact bugs, but new features probably won't be added unless they're both crucial to continuing to use SL and straightforward to implement and test. We know that the V2 codebase is the future, and it's time to make it usable for folks who tried Viewer 2 and found it sucked.

Phoenix is not a griefer viewer!

A controversy blew up last week over Phoenix's feature that allows the true online status of a user to be seen in their profile, regardless of their privacy settings. That was used to support the argument that Phoenix is really just like Emerald, and a viewer meant to make life easier for griefers and stalkers.

Horseshit and hogwash.

Here's what the feature does. When you look at a user's profile - any user - the viewer uses a function provided by LL in the LSL scripting language to inquire about the status of the user behind the profile. It then shows that status in the profile window.

The argument goes that people who have set their accounts to not be visible except to friends, or those who have blocked a friend from seeing their online status, should not have those settings overridden by the viewer. There's just one problem with this argument: That setting, and hiding one's online status from others, has more holes in it than a shotgunned Swiss cheese, even without Phoenix's help.

Let's start with the obvious: The viewer only uses code that Linden Lab provides. The function in LSL that gives a user's online status has been there since the early days of SL, and is widely used in all sorts of things. LL even provides sample code to show how the function works, and that can be used for any account in Second Life. If this was a problem, shouldn't LL remove, or limit, the function? There's a JIRA, SVC-4823, on LL's system to try to get them to answer this exact question.

Even with that gone, there are still many ways to see a user's online status. The most obvious is to simply try sending them an IM: if they're offline, you'll get a message saying so. There are also holes in the display of calling cards in your inventory, and in the availability of the Offer Teleport button. All of these are possible with the standard viewer.

There's an even more basic way, too: If you know where they hang out, just teleport into the same region and use your camera to look around. You don't need to be near them, just in the same region (or even one next door, if you're patient enough to handle the delay in the region crossing with your camera).

So all Phoenix is doing is providing a facility that LL does, in several different ways. If you've got a complaint about it, go complain to LL; they're the ones who provide the facility and even endorse its use (if they didn't, that wiki page wouldn't be there).

Yabbut, the argument goes, even if you can, you shouldn't! More horseshit and hogwash.

The Phoenix viewer exists to give users a viewer with as rich a feature set as possible while still being usable and logical. The focus is on what users want, while remaining firmly within the third party viewer policy's limits. Our users want the true online status to show up. Who are we to make the judgment for them that they shouldn't have it, especially when they can get it so many other ways?

This issue blew up last week at one of the Lindens' office hours. Before it was all said and done, one person was raving at me about how they were going to sue Phoenix developers individually for invasion of privacy and file criminal charges against all of us for being accessories to stalking and cyberbullying and other crimes. That user is now the sole occupant of my mute list.

I, for one, am not going to allow the demented ravings of one kook to control what I do. If that user really wants to file separate lawsuits in separate states, and contact a whole raft of law enforcement agencies to pursue their stupid quest, I can't stop them - although I'm certain they'll get laughed out of court and told to go away by law enforcement agencies who have much better things to do. (Hint: In order to secure a conviction as an accessory to a crime, one must prove that a crime has been committed and that the alleged accessory actually provided material support in that specific crime.)

The bottom line is this: While a loudly screaming, but small minority, wants Phoenix to drop the feature, it's not going to happen while I have anything to do with it. The users demand it, dropping it would have no real effect on privacy, and I'm not interested in caving in to every kook with an axe to grind. If LL comes out and says that we should remove it, then we will. Until then, the kooks can rant in vain.

On new features and open source development

The next version of Phoenix will get a few features backported from Viewer 2:

• Display Names (just added yesterday!)
• Multi-attachments
• Along with that, RLVa version 2

There are two features that are in Viewer 2 that won't be available in Phoenix, period: meshes and multi-wearables (more than one item of clothing on a given layer). I discussed mesh at some length in an earlier entry. I don't know if multi-wearables is all that important, or difficult to add, but unless someone comes up with a drop-in patch for it, we probably won't do it.

There's been a lot of argument, both publicly and within the Phoenix developer community, about whether we should concentrate on fixing bugs and freeze new feature additions. The argument goes that we need to freeze Phoenix's feature set and spend scarce developer time on fixing bugs and stabilizing the code so that we can turn our attention to Firestorm, the Viewer 2-derived replacement. This argument misses the point.

One very clear lesson from the history of open source development is that developers scratch their own itches. Open source developers on a project such as Phoenix are unpaid volunteers. They work on the code because they want to, because they enjoy it, and because it increases their good reputation in whatever community they're working in and serving.

I've managed another open source project, one that's well known within the community that can make use of it, for over a decade. I understand what makes open source developers tick. If that weren't enough, I also, as I've alluded to previously, have been good friends with open source guru Eric Raymond for two decades or so. If I have cultural questions, I pick up the phone and call him and ask.

The history is clear: The most successful open source projects are those where developers are free to do as they want, where project management is done with a light touch, and where people understand that developers are contributing out of the goodness of their heart on their free, donated time. Trying to run a volunteer open source project on the same lines as a business, where employees can be told "do this if you still want a job", leads to a dead project fast. The landscape is littered with examples.

You can only impose a feature freeze on a project such as Phoenix for a limited time, and only right before a new release. Otherwise, developers will simply ignore it and go on. It's possible to extend that period, but only if the consensus of the developers is that it is a good idea. A six-month feature freeze is probably not going to fly, especially in a project where that's an appreciable fraction of the entire history.

Display names support is a good example here. The developer who added it to Phoenix did so in about a day and a half, because he couldn't stand the idea of display names on Linden Lab's website that would not show up in the viewer. He had a very strong motivation to add the feature. Telling him not to would either have been ignored or else caused his resignation from the team.

Key lesson 1: Deliberately chasing off productive volunteers kills organizations. This is true in any volunteer organization, not just open source projects.

Key lesson 2: There's a bit of military wisdom that applies here: "Never give an order you know will not be obeyed." If you tell someone to do something, knowing they will not do so, you not only cause resentments all the way around, and not only don't get done what you need done, you also damage your authority and their confidence in your leadership, with rapidly disastrous effects.

The end result was a good thing. Phoenix will support display names. That will make the feature much more useful to the users of SL. (I'll ignore for the moment the entire controversy surrounding it.) It will also help others to implement it in their viewers. Instead of complaining about it, the right answer is to thank the developer who did it, include it in the program, and go on.

Yes, feature freezes before releases are good practice. At some point, you have to buckle down and fix bugs and get the release as stable as possible before unleashing it on an unsuspecting world. However, you also have to recognize their inherent limitations in a volunteer open source project.

No, I'm not getting off SL...

A lot of folks have been making noises lately about how they're getting off of Second Life and going to other grids. InWorldz seems especially popular right at the moment, but others have been mentioned. The Phoenix Viewer team has been approached about becoming the official viewer for one grid.

I'll be staying on SL, myself, until they turn the lights out. Why? It's where my friends are.

A lot of people see SL as just a place to play games, or to harass people, or MAKE LINDEN$ FA$T!, or have random pixel sex with anyone they can entice onto a poseball. Naturally, they think that the rest of SL is in it for the same kind of reason. Those folks can switch grids pretty much as they wish.

To me, SL is a much different place. It's where I can meet my friends and spend time with them in a world of our own making. The key word in that sentence is "friends". I have RL friends that I knew before I'd ever heard of SL who are on there with me. If my friends aren't on InWorldz, then the place isn't interesting to me.

Yes, I enjoy sex on SL. I sell stuff (not a lot of it, not even enough to pay my rent, but some). I play a game, as a Princess in the Tiny Empires Kingdom of Home. That last is revealing, in itself: TE is an explicitly social game. It's not about gaining rank or accumulating gold and acres. It's something to do while you spend time with friends.

My friends aren't on InWorldz, although one of them is considering setting up a presence there. I set up an InWorldz account the other day. I got logged in, poked at it for a bit, found that Phoenix runs fine over there, and lost interest. Why? Because none of my friends were there to talk to.

There's a secondary problem, but one that is no less real. I couldn't get a nice tigress avatar on InWorldz. My avatar is the version 3 tigress from AnthroXtacy (and I highly recommend them; they do fantastic work!). I looked around InWorldz and couldn't find anything at all in the way of a furry avatar. Nothing. Not a blessed thing. There's supposedly a feline avatar in the freebies store at the island where new folks to InWorldz land, but I wasn't able to wade through the severe lag there to actually locate it, let alone lay a paw on it.

This points out something more fundamental. SL is full of user-generated content. Very full. It's easy to obtain and cheap on the grand scale of things: my nice avatar cost me all of US$3. People on SL don't truly appreciate just how easy it is to find and buy stuff, even with search and the Marketplace as broken as they are. I didn't until I went to InWorldz. There, the selection is much more limited, and many categories are missing altogether.

Why isn't there more content? Because InWorldz is a separate grid from SL, you can't just have your SL inventory appear there. It's worse for a content creator. Using a viewer such as Phoenix, you can export your own creations to disk and then re-import them. The problem is that this is not and cannot be a complete copy. You have to export each individual object. You then have to import the object to the new grid, upload every texture (they're not saved on export), upload every script (because the client cannot export those), then manually marry them all. Repeat for each object. For an avatar maker, there are lots of those per avatar. Multiply that by 200 avatars, in the case of AX, and you have an immense amount of work.

On top of that, there's a technical issue. While the Second Life viewer code is open source, the server code, and the stuff that backs it up such as the asset infrastructure, is most definitely not. A group of folks has created an open source workalike called OpenSim. The problem is that it's only a workalike, and in particular contains some incompatibilities around the scripting engine. Those incompatibilities are why I rent a SL homestead sim to do script tuning instead of just using OpenSim.

This all means that, once again, we have a chicken-and-egg problem, just as LL does with mesh. It's a lot of work for content creators to establish a presence on InWorldz, or any other grid. They're not going to attempt that unless there's money in it for them. Where are the users? Waiting for their friends, and their content, to make the switch. Without users, where's the money?

I do believe there's a future in alternate grids such as InWorldz, if for no other reason than LL seems intent on shooting itself repeatedly in the foot until it dies of gangrene. I'm not a good enough fortune teller to guess as to how much future there is there. One day, if SL becomes untenable for some reason, I might move to another grid. That day is not today, nor is it any day in my foreseeable future.

A couple of updates

Just a couple of quick updates on previous posts:

I got permission to use the Imprudence CoreGraphics patch created by Elektra Hesse. I took it, extended it to work on OS X 10.4, and pushed it into the main Phoenix codebase. I also sent it back to Elektra for her further use as she wishes.

I hope that puts paid to the arguments that the Phoenix team is the same old stuff as the Emerald team.

The other update is that the Phoenix team is now collecting concrete suggestions for what to change in the Viewer 2 user interface. If you'd like to add your two cents worth, head on over to this entry at the Phoenix Viewer blog to see how to contribute. Note that you need to email to Jessica, not just comment on the blog, to be heard and added to the collection.

We're not Emerald, $DEITY->dammit!

I'm trying to chase down a nasty bug in Phoenix on the Mac. Everyone, or nearly so, who creates a sculpt map on their machine and uploads it finds it corrupted when it gets there, in Phoenix builds 225 and 373. I think it's a color space or gamma issue, and spent a couple of fruitless days trying to hunt it down.

It turns out that there's a better answer. Mac OS X contains perfectly usable image conversion libraries as part of its built-in CoreGraphics framework. It even contains a version of the (in)famous KDU library for JPEG2000. It's there in the base OS, and is used for any native image processing on the system. It even handles PSD and TIFF files natively, something the viewer code doesn't. Clearly, using it is the Right Thing.

I hate reinventing wheels. Elektra Hesse of the Imprudence project has already coded up the necessary hooks in the viewer. Imprudence is GPLd, so this isn't a problem for Phoenix - but it is a problem for Firestorm, because the stated goal of the project is to produce an LGPLd viewer, and you can't use GPLd code in an LGPLd program unless you change the entire license to LGPL.

Since Elektra is the author of the change, she can give permission to use it under the LGPL. So I set out to contact her. I dropped her IMs inworld, and joined the #imprudence IRC channel. No luck for a couple of days. Finally, I pinged the other developers, and explained what I wanted. That produced the following comment from McCabe Maxsted, the lead developer for Imprudence:

anyway, a viewer based on Emerald that's friendly to opensource is a strange thing, so you'll excuse me if I'm a bit skeptical about any cooperation coming from Phoenix' end on anything viewer-related. Elektra's the only one who can relicense her patch, you can email her at [redacted]

Grumble snarl. I really wish people would quit associating us with the idiots who were the public face of Emerald. I replied:

I know Elektra is the only one who can relicense it. That's why I'm looking to talk to her.

As for your skepticism, all I can say is that the folks on the Phoenix team are not the folks who were on the Emerald team. The former Emerald developers who were forced to leave are unlikely to be willing to relicense their code to something besides GPL. That's something we're going to have to deal with ourselves, and the results will be LGPLd.

I am not Phox, or Fractured, or the other banned developers. I've been the manager of an open source project in a completely different field for over a decade. I know how open source is supposed to work.

There's a lot of bad blood in the TPV community, and I'd like to see it go away. We're all trying to do the same thing, and we're not competition for each other; if someone has a problem with Phoenix, I've got no problems with their using some other viewer.

McCabe's reply:

I'll keep that in mind

All right, that's fair enough. I hope he does; he'll find that we really don't mind others picking up our changes and using them. I verified this with Jessica Lyon, and she completely agrees.

Unfortunately, at this point, Latif Khalifa, developer of the Radegast text client, decided to throw his two cents in as the Keeper of the One True Open Source Way. I found this especially hilarious, since I'm typing this on Eric Raymond's kitchen table (Raymond, founding president of the Open Source Intiative and open source guru, and I go back two decades). He claimed that the dialog that pops up when you run a copy of Phoenix that isn't an official build was not in accordance with the One True Open Source Way, and said

you cannot claim "not emerald" and continue emerald-like policies, so don't get surprised if people are not very convicend about the opensource spirit of the phoenix project

He claimed later that the dialog box was in the same spirit as emkdu, a clearly laughable claim considering that emkdu was about steganographically encoding user identifying information in uploaded textures and the dialog box is simply a warning that can be easily ignored.

Since the channel is about Imprudence, not Phoenix, I replied:

lkalif, I'm not going to help you take over this channel with your vendetta.

And he fired back:

TonyaSouther: well if you take any criticism as "vendetta" just shows how empty your "not emerald" claim is

Uhm, yeah. He attacks me in an unrelated channel out of the clear blue about a triviality, after creating a "clone" of the official Phoenix repository that's clearly not an exact clone, and refusing to clearly mark it as unofficial, and says that I shouldn't call it a vendetta? Riiiiiight. I refused to rise to the bait:

I've said all I'm going to.

I've dropped Elektra an email; hopefully, we can get together and work for the benefit of the entire TPV community. I didn't come here to be attacked for things I'm not involved in, and that's not the purpose of this channel anyway. It's called #imprudence, not #bash_phoenix.

After sending that, I left the room.

This isn't the first time people has associated us with the Emerald idiots. One especially nasty comment on Tateru Nino's Dwell on It blog suggested the entire Phoenix team get off SL because we could never redeem ourselves. The results of the poll she took, to which that comment is attached, were negative, as well.

I don't know how to say it any plainer than I did to McCabe. The idiots and griefers and bad guys on the former Emerald team are gone, gone, gone. We don't put up with that kind of crap any more. We know damned good and well that if we abuse the fragile trust we've earned back, we're doomed. I'm not going to allow my good name to be destroyed by another developer's actions.

There will always be people who don't trust us. I accept that sad reality as reality. It's still dismaying when it rears its head like this, though.

Update: Elektra has now given permission to use her patch in Phoenix. Yay!

Why open source?

A question I hear a lot is "why did LL open source the viewer?" This is usually followed by a comment along the lines of "it was a dumb decision, it didn't get the Lab anything, it lets people steal content, and it was just plain st00pid". I think this kind of thinking is insanely short-sighted and ignores a lot of history. Open source development can and often does compete well against closed source development on a level playing field.

I have to say here that I have a lot of experience with open source software, both as a user and as a project manager. For the last decade, I've managed an open-source project that's very well known in its field. I know what open source can do, and what it can't.

I don't know why LL chose to open source the software. I seem to recall hearing it was because they chose to include library code that itself was GPLd, forcing the viewer code to be GPLd...but that doesn't explain the new viewer that uses pretty much the same libraries being LGPLd. I do know that, having done so, they can't closed source it again, not just for political reasons, but because the license is irrevocable. They could, if they wanted, obsolete every open source TPV out there by making an incompatible change to the protocols and changing the license on their code (as they did in going from GPL to LGPL), at the cost of forcing everyone to change - and we all know how well Viewer 2 went over.

There are three things LL gets from open sourcing the viewer. The first is described by Raymond's Law: "With a sufficiently large number of eyes, all bugs are shallow". An open source project can harness the enthusiasm and talents of anyone interested and motivated enough to work on the project. A closed source project can only harness the resources of those working for the producer. All else being equal, this is a significant advantage for the open source project.

The second is that open source allows others to add features that the primary developer didn't think of or want to add. There are many features in the Phoenix viewer - nearly 300 of them - that LL didn't come up with. Some (like breast physics (and this still amuses me no end)) they may well add; some (like RLV) they almost certainly won't.

The third effect is often overlooked, but no less real. Programmers working on an open source project are aware that others will look at their code. This makes them more careful when coding, more likely to comment their code and do other things to make it understandable to others, and less likely to sweep bugs under the rug.

People like Prokofy Neva argue that third party viewers should be done away with because they're nothing but content theft tools. (Prokofy also thinks that there's no place for RLV, based on a fundamental refusal to understand that true BDSM is neither violent nor exploitative, but rather loving and consensual; she'd rather see me and my fellow practitioners get the hell off of SL.) The problem with this simplistic worldview is that closing down every TPV and changing the protocol would not stop copybotting. The first copybot came out before LL open sourced the viewer code. There's a content theft proxy out there that will work just fine with a box stock LL-supplied viewer. The history of MMORPGs is rife with examples of people cracking the communication link and doing all sorts of evil. LL wouldn't be able to buck that trend.

The users are voting with their feet. Well over half of them are using open source TPVs. Regardless of what those who don't understand open source have to say about it, it's here to stay on SL, and that's a good thing.

Belial Foulsbane is a bully

Once upon a time, a programmer added the ability to change the viewer's draw distance from the Emerald command line. Then someone realized that that made it possible to use a gesture in SL to do it automatically from a keypress.

Then someone - maybe the same person, maybe not (there are accounts of the programmer who added the function to Emerald blogging about it, but I haven't been able to locate the post), but he uses the SL name of Belial Foulsbane - decided to turn it into a product. He sold it, eventually, for L$212 on XStreetSL but only L$200 inworld, itself a violation of the XStreetSL terms of service. He apparently made a lot of Lindens from it.

This was all well and good until other folks started passing around freebie gestures. I got one many months ago, thought it was neat, and promptly forgot about using it when it was explained that using it caused a load on the server that made everyone else lag. Unfortunately, Foulsbane took this as people stealing his content, and started sending DMCA takedown notices and even filing a lawsuit. (Edit: I'm now told that Foulsbane's DMCA notices even targeted freebies that existed before he began selling his products.)

Free clue: DMCA is about copyright. Copyright does not protect ideas. Copyright protects expression of ideas. A DMCA complaint about someone giving away something that does the same thing as someone's product is frivolous.

By doing this, Foulsbane earned the enmity of many folks. This includes the developers of the various third party viewers around SL, including (at the time, back in May or so) the Emerald team. A change was coded to disable the use of the draw distance command from a gesture back then, but never made it into the codebase.

Not long ago, the subject came up again. We discussed it, and after we realized that the "speed rezzer" Foulsbane was selling did indeed cause problems, not only did we disable it, we also provided a superior alternative. The problem with "speed rezzers" has to do with how Second Life sends data to the viewer. Normally, it doesn't prioritize sending the closer data to the viewer first. When a "speed rezzer" is used, the data that's already been sent to the viewer is discarded, and then re-sent by the server. This causes lag for everyone else on the same sim. Phoenix now has a function called progressive draw distance stepping. Like the "speed rezzer", it forces the server to send closer data to the viewer first. The crucial distance is that the Phoenix PDD stepper doesn't cause the data to be sent to the viewer in the first place, and so doesn't add load on the server.

Foulsbane's response to this was to post a big red-text rant to his item listing accusing the Phoenix development team of being in league with content thieves and asking his users to demand that we remove the code from the viewer. His approach was, to say the least, guaranteed to make the development team unsympathetic to his demands. We talked about it briefly, and we decided that we weren't going to change things to accommodate a real litigious asshole of a bully.

After his attack on the Phoenix development team, there's no way in hell Phoenix will go back to letting him sell his lag-inducing piece of software as long as I have the slightest bit to say about it. I'm a content creator. I do not condone, much less assist in or perpetrate, content theft. I do not consider removing the ability of Foulsbane's product to work with the Phoenix viewer - a product that existed only because third party viewer developers added a feature, to begin with - to be a problem. Foulsbane's reign of DMCA-misusing terror is at an end.

Everybody knows Viewer 2 sucks

By now, it should be news to absolutely nobody that Second Life users hate Viewer 2. Nine months after it was released amid great fanfare, only 20% of the logins on the grid are made with it. It's only within the last two weeks that it passed the venerable version 1.23 viewer for popularity among users, with third party viewers leading the pack substantially.

The only people who won't admit Viewer 2 sucks as far as the user community is concerned is Linden Lab itself. This makes perfect sense, even though it drives users nuts. LL spent seven figures on Viewer 2 development. For a company that size, that's a major investment. They cannot just throw that away. Doing that would make executives lose their jobs, and get the company's board of directors interested - and not in a good way.

I haven't used Viewer 2 myself for more than about 5 minutes. Since my work on SL requires RLV, and Marine Kelley's RLV wasn't available for the Mac, I saw no particular reason to try it. That stayed the case ever since. The one exception was when I started up the display names test viewer to find out for myself just what the fuss was all about (there's another blog posting coming up about this). The user interface so confused me that I quickly logged out and back in with Phoenix.

Still, there's a small but extremely vocal contingent that swears up and down that Viewer 2 isn't bad, just different, and that people should quit whining and learn to use it - and if they do, they'll love it. This is being greeted with about the level of incredulity you'd expect from people whose views are being totally ignored. These folks don't understand that, as long as there's a choice, most of the user community will simply not choose Viewer 2 no matter how much they're told to shut up and eat their Brussels sprouts.

At the other end of the scale are people who see anything LL does to third party viewers as part of a conspiracy to force the user community to move to Viewer 2 whether it wants to or not. They take comments like Oz Linden's "we see third party viewers as a problem to be solved" far, far too literally. What Oz meant was that LL sees TPVs as competition, but the "solution" isn't to destroy them underhandedly, but rather to out-compete them. I've got no problem with this at all. If a TPV can't out-compete LL's official viewer, then it deserves to wither.

Even so, it's plain that the Viewer 2 codebase is the future of SL viewers. LL's adding new features to SL: inventory links/outfit folders, display names, and mesh are just the beginning. Those additions are all being done only in the Viewer 2 code. They're not touching the Snowglobe 1.5 codebase any more; in fact, they've dropped it officially and won't even distribute it any more shortly, if they haven't stopped already.

The reaction to this in the user community is "Fine! Third party developers, just put the Viewer 1 user interface on Viewer 2, and we'll be happy!" This is one hell of a lot easier said than done. To explain why, I need to discuss program design for a moment.

In a project as large as a viewer, proper code design is something that has to be enforced rigorously from the very beginning. Good practice would have had the code implemented in layers, with the user interface layer talking to the layers that do the actual work through clean, straightforward, well-designed and well-documented interfaces. There are all sorts of benefits to this way of doing things, the biggest of which are simply that it makes life a lot simpler when it comes time to add features or fix bugs.

Anyone who's looked at the version 1 viewer code will know instantly they didn't do it that way. Oh, they tried, and there are some things that are cleanly broken out, but the vast majority of the code is an unmitigated mess. It takes me literally hours to find out where something is done, just trawling through it. This is understandable. When you have a program that big that's grown in many different directions over a period of years, it's very hard not to have it happen this way. That's why major programs get total rewrites every so often.

So with Viewer 2. Unfortunately, LL made two critical mistakes when they did it. They contracted out the development, I'm told, to a group in the Ukraine. The first mistake was that they didn't ride herd on them to enforce good coding standards (like the split between UI and worker layers I described). The second mistake was that they didn't pick people who actually knew anything about Second Life from the standpoint of a user.

The result of these two mistakes was a Viewer 2 codebase that didn't work like anything people knew how to use already, and had assumptions about the way it should work at the UI level baked into the lowest levels of the code. For example, the code assumes, deep down, that there will only ever be one information window for a group - any group - open at a time. The way IMs and local text chat are handled, the sidebar, the inspector instead of the familiar pie menus, all are deep, basic assumptions about the way the viewer will work, and they're all embedded in the code at all levels.

One of the other Phoenix developers is in the camp of "just eat your Brussels sprouts". The Phoenix team will be working on a Viewer 2-based viewer, named Firestorm. We've been talking about a UI redesign, and what's even possible. That developer is adamant that putting a familiar version 1 user interface on the Viewer 2 codebase amounts to a total rewrite. Obviously, the Phoenix team doesn't have the resources for that. As it is, we're planning a minimum of six months to put out some version of Viewer 2 with the UI changes we can make practically and with the most-requested features. (We won't have to add bouncing breasts, though. LL's doing that. No really. Quit snickering. You wouldn't believe the number of complaints we get from folks having a hard time getting it to work.)

So what's the Phoenix team planning? Good question, and one we'd love to have the answer to. Right now, we're concentrating on making the current one stable so we can let it go and work on Viewer 2 uninterrupted. Once we get that out the door (and we're really hoping the version we expect to release in a couple of weeks is that version), then we'll get serious about Firestorm. It's not too early to plan what we're going to do, however. To do that, we need to know what's possible, and what the users really want.

Don't just tell us "put the version 1 user interface on version 2!" That's not going to happen. We've all got real lives to deal with and real world constraints on resources. We can't do the total rewrite this would take.

What we need is specifics. Yes, this means you're going to have to fire up Viewer 2 and tell us what it is you don't like about it, in specific detail. I know it'll be a pain. Force yourself. Concrete suggestions for improvement will get seriously looked at, and implemented if possible without rewriting half of the code.

We all know Viewer 2 sucks. What we don't know is why or how specifically to fix it within the constraints we have to live with. That's where you come in.

Mesh: Dead on arrival

There are a lot of people anxiously awaiting the arrival of mesh importing on SL. They think it'll be neat stuff and make the world a better, richer, more interesting place. I think it's dead on arrival.

For those of you who don't know what that is (yes, there are probably some yet), meshes are a way to build objects with any shape desired in a 3D modeling program like Maya or Blender and have them appear in SL just as they were designed. A mesh describes an object as a series of vertices, with lines and surfaces connecting them. Any object can be modeled this way; how well is a matter of how many vertices are used.

SL has actually had a form of meshes for quite some time. A sculpt is a mesh, but limited in the level of detail by the fact that it can have at most 1024 vertices. That's enough for quite a lot of creativity, but it's not enough for many things. Sculpts are usually used to make one part of a larger item, in greater detail than can be done just with primitive objects like boxes and spheres and cylinders.

A mesh doesn't have that limitation. One demonstration I've seen is of an Audi R8 in one 8192-vertex mesh. It looked quite impressive. That's the kind of eye candy that Linden Lab is hoping creators will make, and that users will demand. People have been demanding it for years and eagerly awaiting it ever since LL announced they'd do it.

There's only one problem: Mesh is dead on arrival. As currently planned, it's got far too many things wrong with it to be useful to content creators.

The first hurdle is that it requires massive changes to the viewer's scene rendering code (the part of the viewer that draws the picture shown on your computer screen). These changes, practically speaking, are only practical in LL's Viewer 2 or third party viewers based on it. This runs smack dab head-on into the basic fact that the SL user community hates the Viewer 2 user interface with a passion normally reserved for a kid hating Brussels sprouts. LL's been trying hard to get users to Viewer 2 ever since it was introduced early this year. The latest figure I've heard is that it's now used for 20% of logins to SL. Where are the users? Either still on 1.23 (which Viewer 2 just passed in popularity for the first time last week), or else third party viewers. Before Emeraldgate, Emerald had 60% of the userbase all by itself. Since then, the users have scattered, with most moving to Phoenix, but a large number are using Imprudence, Emergence (which is deprecated by the developer, who recommends that people use Phoenix instead), and Ascent. All of those are based on the version 1 codebase, which will not show meshes.

All of that means there's a chicken and egg problem. Content creators aren't going to bother with meshes unless there's significant demand, and a significant number of users who can actually see the content they'll create. Users aren't going to switch to Viewer 2 just for meshes that aren't being created, no matter how much LL might think otherwise. Oz Linden said that he expected mesh to drive users to Viewer 2 at a recent third party viewer developer meeting. I think he's full of prunes. That's wishful thinking. Mesh won't overcome users' hatred for the Viewer 2 user interface.

There's another problem with meshes for content creators: Oskar Linden announced at yesterday's mesh office hour that no third-party viewer would be permitted to use LL's mesh upload code in their viewer. It seems that the upload code uses part of the Havok physics library that LL licenses from Intel. That library is very much not open source, and LL is not permitted to distribute it except as part of their own program. This means that a content creator will have to exit his viewer of choice (almost none of them are using Viewer 2, because they can't afford to take the weeks needed to become proficient in the UI), start up Viewer 2, upload the mesh, then sign out and back in with his regular viewer. To a big content creator, time is money. If using a mesh takes up that much time and effort, they just won't bother.

Meshes are also considerably less useful than they might appear to be to clothing designers, because they cannot be made flexible. A piece of rigid clothing isn't very comfortable or realistic.

Finally, the cost of using meshes, as things currently stand, is astronomical. There are only two things in SL that cost real money: land area and primitive usage. That's because both translate directly into load on the server computers that run Second Life. Meshes also add to that load, so they need to count as well. Just how much they cost isn't known outside the group within LL that is doing the project (and maybe by nobody, really, but Andrew Linden). This cost is being expressed as an equivalent number of primitives, and will count against the primitive limit for a parcel of land. The problem is that that cost is being set high  enough that, in many cases, a mesh object is more expensive than the same object built up out of primitives. Yes, the mesh object looks a little bit nicer, but if the price is double that of the primitive-based object, why bother?

As I said above, Linden Lab has a chicken-and-egg problem with mesh. The rest of the problems with it pretty much guarantee that people aren't going to make the leaps needed to exploit them. Despite LL's best hopes for meshes pushing people to Viewer 2, it just ain't gonna work that way. Mesh is dead on arrival.

The obligatory "who are you?" post

It's possible that people who don't know me personally will be reading this, so I suppose I should introduce myself.

I'm a Second Life tigress. I joined SL in May 2009 because some good friends are there. The friends are what keep me in SL instead of jumping ship to Inworldz or some other grid. To me, SL is first and foremost a communications medium for people that just happens to have aspects of a game about it. It's not a game in and of itself.

I've built and scripted bondage furniture for almost my whole time on SL. I've written my own script suite for furniture. It's open source and freely available, reusable, and redistributable. If you want a copy, just ask me. I sell my furniture from my store, Tonya's Restraint Works.

Because of that, I've been using third party viewers for almost as long as I've been on SL. I started out with Marine Kelley's Restrained Life Viewer, and then switched to Emerald when I got tired of waiting for RLV to be updated on the Mac. Emerald had the richest feature set and was actually updated on the Mac at the same time it was on Windows.

When Emeraldgate happened, the team was in disarray. There was a beta release of Emerald that was supposed to be a major step forward. I couldn't find out, because it wasn't available on the Mac because it was broken there and nobody was left available to build and test. So I volunteered. The next thing I knew, I was a member of the Emerald team...for all of four days before the project was killed.

I'm now the lead Mac developer for the Phoenix Viewer. I'm also helping to organize the non-profit corporation to carry on the project's work. I'm learning a lot about Second Life that I never knew in the process. I'll share those insights here.