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.