01 January 2013

Go ahead, fork Phoenix

Ever since we announced the end of Phoenix support, people have been bitching and moaning about it. As I said previously, this should be a surprise to nobody. We've been saying this is what we'd do for a solid year. We told everyone right up front that our development efforts on Phoenix have ended and that we would make no more changes.

Well, it's now come to pass. If you ask a Phoenix question in the support group that isn't related to migrating to Firestorm, you'll politely be told that we cannot answer your questions any more and directed to the self-help group. The support team was very happy when midnight SLT came around last night so they didn't have to deal with Phoenix any more.

There have been a few comments recently from folks claiming to fork - or even "take over" - the development of the Phoenix viewer. While it's not available for a takeover, a fork is entirely possible. Forking is inherent in open source development; indeed, nearly all experts in the field of open source development claim that the freedom to fork is at the very foundation of what makes open source successful. I have no particular problem with this view.

However, I think forking Phoenix to keep it running in SL is a very bad idea, for the same reasons we stopped developing on it. There will be a lot of work that needs doing in a very short time just to get the ability to deal with server-side baking into it. You might be able to piggyback off of Henri Beauchamp's work - as we did to get mesh into Phoenix - but that will only be the beginning of your problems.

You'll have a fair amount of work on your hands just to bring the mesh renderer up to speed. The one in Phoenix 1691 is based off of the LL 2.8 viewer. Every other one is based off of at least 3.3, if not 3.4 (I think CoolVL's current version is 3.4, for one example). You'll likely need to roll that work in to be able to use the other code that's floating around.

There are other things people have been screaming for and we haven't done. Multiwearables and RLV 2.7 are the two biggest, and neither one is going to be trivial. There are many others.

This is going to be an immense amount of work. Anyone who's not already intimately familiar with the code will have a steep learning curve, as well; Phoenix was hacked on by a cast of thousands, with decidedly varying levels of competence at programming and at C++ (and those are two independent variables). I'm not kidding when I say it's an unmaintainable tissue of hacks held together by spit, chewing gum, duct tape, and baling wire.

One thing I don't understand is the fetish some of our haters have for accusing us of lying. We don't lie. We tell the truth as we see it. That's exactly what I've done in every posting I've made publicly, both here, on Google+, on SLUniverse, and on the LL forums. I've been wrong sometimes. I'm not perfect. Even so, it's still the truth as best I can say it. Just because you don't like the answer doesn't make it incorrect, far less a lie.

And we're doing exactly what we said we'd be doing. Don't like it? Fine. Go right ahead and fork Phoenix. I double-dog dare you. Go ahead and prove me wrong.

But somehow, I don't think that someone who just today picks up the code and gathers programmers who know what they're doing will be able to have it working before LL breaks Phoenix. Anyone who claims that without some serious achievements under their belt to back up the bluster is just blowing smoke.


  1. Guy who brought up the fork stuff is a poser, not a thinker. Any coder knows what he’s doing and wants to contribute to a V1-based viewer would rather lend Henri or Seana a hand because Cool VL and Singularity are far more advanced.

  2. The way Linden Labs seem to be handling TPVs and licencing, the apparently-defunct V1-based viewers may be worth reviving for OpenSim.

    The Lindens are acting a little as if they're scared of OpenSim. If OpenSim compatibility is on the way out we might see some big changes. We're already seeing Grids with new stuff that I doubt can happen in Second Life. We have large regions, for instance.

    Is Phoenix the right starting point? From your viewpoint, probably not. Long term, is a Linden-clean viewer a worthwhile idea?

    1. Don't jump to that conclusion just yet. LL is *not* prohibiting viewer developers from releasing versions without the Havok libraries included, and Firestorm is fully committed to supporting OpenSim in the long run - as long as it does not deliberately make changes that would be incompatible with what it does now, or for new added features that match LL, as long as they don't implement them incompatibly.

      Realistically, as long as we don't have to have a mountain of code different for the two cases, it'll be good. The main reason for this is that we want the non-Havok viewer to be usable on SL as well, without only those features enabled by Havok.