Am 17. Dezember 2012 verkündete das Phoenix-Team das Ende der Entwicklung des beliebten Phoenix-Viewers. Die Gründe dafür sind unter anderem, dass man nicht mehr weiterhin zwei unterschiedliche Codebasen pflegen will und 2013 neue Features wie Serverside Baking erscheinen werden, die ohnehin die Kompatibilität mit der 1er-Viewercodebasis brechen werden.

Festzuhalten dabei ist: man kann seinen Phoenix noch weiterhin benutzen, die Entwicklung aber wurde Ende 2012 eingestellt. Eine lange überfällige Ankündigung, bei der man förmlich die Freude des Teams, endlich diesen Zombie losgeworden zu sein, spüren könnte. Die Reaktionen auf den Post sind zweigeteilt: die einen haben absolut kein Problem damit, und sich beim Phoenix-Team für all die Arbeit bedankt, sie nutzen in Zukunft nun entweder eben Firestorm, Singularity oder den Cool Viewer. Andere aber tun so, als sei dies der Untergang des Abendlandes und überziehen das Team mit überbordender Häme und Flames.

Diese Flamer haben dabei offensichtlich nicht verstanden, was Opensource ausmacht. Opensource heißt, du kannst den Code nehmen und damit im Rahmen der Lizenz machen, was du willst. Es heißt aber nicht, dass nun die Entwickler eines Projekts unentgeltlich nach der Pfeife ihrer Benutzer tanzen müssen und machen müssen, was die wollen. Wenn die Entwickler keine Lust mehr haben, etwas weiter zu entwickeln, dann ist das eben so und fertig. Dann kann man entweder selber die Initiative ergreifen und da weitermachen, oder lebt damit und lässt es eben sein. Punkt, aus, fertig!

Alles in allem sind aber die anhaltenden Flames der Phoenixfanbase mit bisher 178 Kommentare im Blogpost oben dermaßen überzogen, dass sich die Entwicklerin Tonya Souther zu dem Kommentar “Go ahead, fork Phoenix!” hinreißen ließ. Souther beschreibt die Codebasis des Phoenix-Viewers als hoffnungslos veraltet, dass es schon massiver Arbeit bedürfe, alleine das Meshrendering auf den Level von 3.4 zu bringen — es basiere noch auf Viewer 2.8.

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.

Ich übertreibe nicht, wenn ich sage, dass es [Phoenix] eine unwartbare Masse an Hacks ist, die von Spucke, Kaugummi, Tesafilm und losen Drähten zusammengehalten wird.

Das Zitat lässt dann schon tief blicken, und weil die Fanbase so rabiat weiterhin auf Phoenix pocht, soll sie doch den Mist einfach übernehmen, warten und fertig. Der Rest könne ja mit Singularity oder dem Cool Viewer glücklich werden.

Kurz: Undank ist wohl der Welten Lohn und manche Hohlpfosten fordern da von Freiwilligen eine Arbeitsleistung ein, auf die sie kein Recht haben das einzufordern. Klar, dass da einem schon mal die Galle überlaufen kann.

Übrigens schwebt über all diesen Probleme Henri Beauchamp, denn der bastelt ja nach wie vor an seinem eigenen Viewer, dem Cool Viewer, alleine. Diesen entwickelt er vor allem für sich selbst und wenn jemand Gefallen daran hat, bitte, kann er ihn gerne nutzen. Beauchamp gibt an, über 35 Jahre Programmiererfahrung zu verfügen und dementsprechend kein unbeschriebenes Blatt zu sein.

Gut, Beauchamp hatte mal wieder Langeweile, und daher kann die aktuellste Version vom Cool Viewer bereits Server Side Baking. Ein Feature, das der Phoenix-Viewer nie mehr bekommen wird, es sei denn jemand macht einen Fork und nennt den dann anders. Der Cool Viewer ist damit der erste TPV, der dieses Feature offiziell unterstützt.

Übrigens gibt’s zu dem Thema auch noch eine launige Mail von Beauchamp in der Entwicklerliste an Oz Linden, die es in sich hat. Beauchamp wirft Linden Lab in Sachen Opensource schlichtweg Vollversagen vor, anders kann man es nicht nennen. So schreibt er dies:

I’d rather not judge “Oz, the man” because it is hard to tell whether his actions are the only result of his own decisions and doings, or are the materialization of LL’s policy towards OpenSource and, if we can judge from the resulting actions their policy would clearly be: “take benefit of all the advantages OpenSource can bring to us (i.e. free coding and debugging horsepower provided by volunteering developers), and dismiss all the duties OpenSource cooperation involves in return (such as providing clean diffs for changed we made behind closed doors(*) before releasing them, but also providing an *open* list of known bugs to developers)”.

Kurz und gut: Linden Lab würde gerne die Vorteile der Community wie kostenlosen Code und Debugging abgreifen, dafür im Gegenzug aber nicht mal die grundlegendsten Selbstverständlichkeiten an die Community, wie eine offene Liste der bekannten Bugs, zurückliefern. Eine Klage, die nun überhaupt nicht neu ist, sondern genau so schon Nicholaz Beresford vor fast fünf Jahren formulierte. Linden Lab bleibt also sich und seiner Linie treu. Das Hauptproblem von Linden Lab sei, dass sie hinter verschlossenen Türen monatelang neues Zeug entwickeln würden und dann — BUMM! — ist es auf einmal eben da. Das sei nicht die Art und Weise, wie Opensource funktioniere, und vor allem käme da Linden Lab seinen Pflichten nicht wirklich nach…

Daran angehängt ist eine Email von Beauchamp an Oz Linden vom Juli 2012, in dem sich Henri lange und breit darüber auslässt, wieso er die Art der Implementierung — basierend auf dem “Current Outfit Folder” für eine denkbar schlechte Idee hält.

Und jetzt, wo die ersten Testimplementierungen da sind und das Feature offenkundig so bockt wie Beauchamp voraussagte, zeigt Beauchamp denen mit Freuden den Stinkefinger und sagt dazu: “Ich habe es euch doch gleich gesagt!” — Tja, und er hat damit sogar noch Recht, aber Linden Lab wollte ja nicht hören…