"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.