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.