NiranVs Viewer wird eingestellt – oder auch nicht

Das mit den Gemütslagen mancher Opensourcentwickler ist ja so eine Sache. Das Leben ist natürlich nicht einfach, meistens ist es sogar recht undankbar, längst nicht alles, was man programmiert, wird auch von Projektleitern dann übernommen. Das empfinden viele als einen Schlag ins Gesicht, kommt aber täglich vor und damit muss man eben einfach leben, fertig. Nicht umsonst hieß das Essay von Eric S. Raymond damals „Die Kathedrale und der Basar.“

NiranV Dean hat nun bei Linden Lab einen Bugreport eingereicht, dass die Attachments im Viewer nicht genau symmetrisch dargestellt werden und, wie es sich gehört, das alles schön fein säuberlich dokumentiert plus eine mögliche Problemlösung gleich mitgeliefert. Das klingt im Prinzip erstmal nach einer runden Sache, das Ticket nennt sich Open-162. Da gibt es auch einige Bilder dazu, inwieweit nun sich der bisherige Fehler genau auswirkt. Eigentlich ist es mehr eine Kleinigkeit kosmetischer Natur.

Nun hat Linden Lab aber den Bugfix nicht angenommen und das Ticket geschlossen. Warum? Ganz einfach, weil dieser Bugfix Unmengen an bereits existierendem Content kaputt machen würde, und die Besitzer per Hand nachbessern müssten. Die meisten Designer haben nämlich drum herum gebaut und fertig, also es ist kein wirklich weltbewegender Fehler, sondern mehr so eine Sache mit der man leben gelernt hat und an die man sich gewöhnt hat. Second Life ist voll davon, und würde man nun hergehen und das korrigieren, dann wäre der Schaden eindeutig größer als der Nutzen. Also ist es besser, man lässt es so bleiben wie es ist und fertig.

NiranV Dean weiß zwar darum, aber er ist folgender Meinung:

better break all available content that has been attached to those bones instead of creating even more broken stuff in the future making it unnecessarly harder for avatar and clothing creators to align their stuff symetrically correct. If this issue would have never happened , i wouldnt have lost so many hours on finetuning my legs and other attachments because they are simply not symetric to each other.
And instead of saying „it breaks content“ we actually DO it and prevent more broken stuff to be created which makes this shitstorm just bigger.

Und mit der Meinung eben flog er auf die Schnauze, fertig. Das kommt vor, und es ist einmal wirklich einer der Fälle, wo ich die Meinung von Linden Lab absolut unterstütze, die da lautet:

Real bodies are not perfectly symmetric, and neither is our avatar model; changing this now would be more disruptive than symmetry justifies.

Also Linden Lab erspart seinen Zigtausend Benutzern hunderte von Stunden unnötiger Arbeit. Schön. Die Reaktion von Niran darauf ist trotzig, er hat nun angekündigt, deswegen mit der Entwicklung seines Viewers aufhören zu wollen.

Er selber schrieb dazu das noch: 

for my users , i will do one last release sometime soon (not sure yet) and i guess thats it then , i will just return to what i´ve done prior to creating a Viewer that doesnt try holding the users hand and wants to improve Second Life instead of keeping its broken state

Da sage mal noch einer, dass Programmierer keine Diven sein können.

Die rabiate Phoenix-Fanbase und noch ein paar Statements von Henri Beauchamp zum Thema Serverside Baking

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…

Da liegt sie nun, die Hoffnung der Meshfreunde und ist doch noch nicht das, was man sich erhofft hat…

Dieser obige Gedanke kam mir, als ich bei Maddys Wochenumschau die Neuigkeiten von Nalates Urriah in Bezug auf den Mesh Deformer gelesen habe.

Nun, was ist geschehen?
Zunächst einmal die gute Nachricht: es wird nach wie vor am Mesh Deformer mit Hochdruck gearbeitet und die Entwicklung geht offenkundig weiter, auch wenn man davon in der Öffentlichkeit momentan weniger mitbekommt, so stehen die Räder da dennoch nicht still. Das ist schon mal eine gute Sache, vor allem wenn man auch bedenkt, wie lange dieses Feature nun bereits in der von SL-Bewohnern finanzierten Entwicklung steckt! Wer zahlt, der will schließlich auch irgendwann etwas dafür sehen, und man sieht es auch!

Wo liegt das Problem?
Das Problem liegt nach Nalates Urriah darin, dass der sagenhafte Mesh-Deformer momentan vor allem auf älteren Rechnern das Tempo einer Weinbergschnecke vorlegt im Bereich seiner Berechnungen.

Die Avatare werden nacheinander, also seriell, abgearbeitet und die Kalkulationen sind sehr umfangreich. Die Zeit, die sich dann ein älterer Rechner gönnen soll bis er mit Deformieren fertig ist, soll im Bereich von mehreren Minuten liegen und das ist einfach für ein fluffiges SL-Erlebnis viel zu lange.

Wer neuere Rechner hat, der soll das Problem nicht haben. Nun wird darüber spekuliert, dass das Problem auch daher rühren könnte, dass der Deformier-Thread im Viewer eine recht niedrige Priorität habe und ein Anheben diese das Problem beseitigen könne. Ich bin mir sicher, das wird ein TPV-Entwickler sehr flott ausprobiert haben.

Der andere Vorschlag, der gefallen ist, ist dass das Deformieren auf SL-Servern stattfinden solle wie in Zukunft auch das Texture Baking für die Avatare, so dass die Clients damit nichts mehr zu tun haben. Die Wahrscheinlichkeit aber, dass dies realisiert werden wird, ist dann doch recht gering.

Was bleibt?
Es klingt alles schlimmer, als es in Wirklichkeit ist. Ich bin mir sicher, der Deformierer wird nun erst einmal getuned werden und man wird schon versuchen Mittel und Wege dafür zu finden, seine Arbeitsweise zu beschleunigen. All das wird noch ein wenig Zeit und Arbeit erfordern, aber findet sicher schon statt und dann irgendwann wird er vielleicht doch einmal Ready for Prime Time werden. Im Moment ist er es offenkundig als Baustelle jedenfalls noch nicht.

Und wer dann eben einen älteren Rechner haben sollte, der wird dann unter Umständen eben Pech haben. Das mag zwar hart klingen, aber so ist das Leben.

Was bedeutet die Reform des JIRA-Trackers genauer?

Ich habe mir zu der Änderung im Umgang mit dem JIRA-Tracker noch so einige, weitere Gedanken gemacht.

Die einen sehen darin einen notwendigen Schnitt und Schritt in die Normalität. Ein Bugtracker ist schließlich zum Melden von Fehlern gedacht und nicht als Abstimmungssystem über Features, die viele nun sehr gerne hätten oder um in den Kommentaren Druck auf die Entwickler auszuüben. Aber gerade das war sehr häufig im Laufe der Zeit im JIRA geschehen, wer kennt es nicht, dass irgendjemand ein Ticket zu irgendwas eröffnete, dann den Link weiter reichte und darum bat, man möge bitte dafür abstimmen, damit Linden Lab mal den Arsch hochkriegt und das behebt? Eben!

Dafür war das System nie gedacht gewesen, andererseits ist es aber auch so, wenn man es wirklich systematisch ausgewertet hat, konnte man daraus eine Menge über die Wünsche seiner Kunden erfahren.

Also ist das aus Sicht Linden Labs ein Schritt in die richtige Richtung, diese Unkultur im Bugtracker zu unterbinden, für die er niemals gedacht gewesen ist.

Aber das greift dann eben doch ein wenig zu kurz. Man hätte nämlich es so machen können, dass Bugs sehr wohl noch für jeden öffentlich sichtbar sind, aber nicht mehr jeder kommentieren/abstimmen kann. Die meisten erfolgreichen Opensource-Projekte fahren generell mit offenen Bugtrackern, weil eben diese durch die Offenheit leben. Beispiele dafür sind die Bugtracker von Firefox, Linux, Video Land Client, Chromium (die Basis von Google Chrome) und viele weitere. Offen einsehbare Bugs gehören zu einer guten Opensource-Entwicklung einfach dazu, denn sie bringen eine Menge an Vorteilen. So etwas ist also Standard.

Was nun Linden Lab getan hat, ist die Abstimmungskultur im JIRA schlagartig zu beenden. Gut, das ist deren Sache. Aber sie taten eben noch mehr, indem sie dafür sorgten, dass Bugs grundsätzlich nicht mehr öffenlich sind, auch die Bugs, die die Viewerentwicklung betreffen.

Und damit zeigen sie den externen Viewerentwicklern eindeutig den Stinkefinger, etwas anderes ist das nämlich nicht. Sie berauben diese Entwickler nämlich einer immens wichtigen Informationsquelle.

Wer das nicht glaubt, der sollte sich mal damit auseinandersetzen, was gerade in einem ähnlichen Fall passiert. Die Datenbank MySQL gehört schon seit längerem zu Oracle. Oracle selber entwickelt diese als Opensource auch weiter, aber es gibt mindestens zwei kommerzielle Konkurrenten zu MySQL, einmal Percona und dann MariaDB.

Was tut also Oracle, um seine eigene Datenbank zu pushen und die Entwicklung der Konkurrenz zu erschweren? Sie sorgen dafür, dass gewisse Bugs nicht mehr öffentlich sind und stellen zu gewissen Features im öffentlich zugänglichen Quellcode nicht mehr die Testfälle zur Verfügung.

Die externen Entwickler sehen dann in Release-Notes meinetwegen nur noch, Bug 123 und 456 wurde behoben – was aber der Bug gewesen ist, das wissen sie nicht mehr. Das erschwert ihnen also die Entwicklung und das Gleichziehen mit dem Mutterprodukt MySQL gehörig.

Ebenso wird es ihnen erschwert, die Kompatibilität ihrer eigenen Forks noch zu gewährleisten, wenn Oracle nicht mehr die dazu notwendigen Testfälle bereitstellt.

Aus Sicht von Oracle ist das ein logischer Schritt: man behindert die unleidliche Konkurrenz, hofft darauf, dass die Benutzer auch weiterhin den Arsch nicht hoch kriegen sondern bei MySQL bleiben und man so verstärkt Supportverträge verkaufen kann. Diesen Effekt, die unliebsame Konkurrenz so trotz Opensource abhängen zu wollen verstärkt Oracle noch dadurch, dass sie MySQL mit einer brachialen Geschwindigkeit weiter entwickeln.

Also alles in allem eine Sache, die in der MySQL-Nutzerschaft sehr skeptisch aufgenommen wird und kritisch beäugt, wie man beispielsweise bei Kris Köhntopp nachlesen kann.

So, und nun zurück zu Second Life und der JIRA-Reform: die Parallelen sind mehr als offensichtlich. Linden Lab lässt die Entwickler von alternativen Viewern am langen Arm verhungern, indem sie alle Bugreports nun als privat markieren, dazu kommt auch die sehr schnelle Weiterentwicklung der eigenen Viewerlinie.

Damit macht Linden Lab nichts anderes als Oracle mit seinen Konkurrenten: man zeigt ihnen den Stinkefinger und trocknet deren Tümpel aus. Gerade dieser Schritt von Seiten Linden Labs ist nun wirklich mal brachialer und auch folgenreicher als die damals stark kritisierte Havok-Unterlizenz, die ja nur optional ist.

Mit dieser Maßnahme schadet Linden Lab den Entwicklern von Firestorm&Co. nämlich wirklich massiv, und viele bemerken das nicht einmal.

Normal und Specular Mapping für Second Life Viewer kommt bald

http://www.youtube.com/watch?v=pr3AP_DADAY

Die Entwickler vom Exodus Viewer erweitern in Zusammenarbeit mit Linden Lab den Second Life Viewer um die Möglichkeit der Verwendung von Normal und Specular Maps – Linden Lab kümmert sich um die Serverseite, Exodus um den Viewer. Da ein Video mehr als tausend Worte sagt, schaut euch oben das Video dazu an, danach sieht man klarer was da bald auf uns zukommt (das Video ist aus dem offiziellen Secondlife-Kanal bei Youtube und taufrisch).

Das sind Eigenschaften, die manche Designer schon lange gerne gehabt hätten – und nun bald kommen werden. Zudem soll es möglich sein genauer festzulegen, wie Licht von Oberflächen reflektiert werden wird. Alles in allem eine schöne, neue Sache Second Life grafisch noch opulenter zu gestalten (auch wenn sicherlich viele nun wieder sagen werden, dass Linden Lab besser erstmal einen Haufen bereits bestehender Features mit dem notwendigen Feinschliff vollenden sollten, bevor sie da schon wieder eine weitere Baustelle eröffnen).

Mit Besten Dank an Amadeus Hammerer für den Link.

Linden Lab unterbindet die Nutzung ihrer eigenen Viewer mit Opensim

Linden Lab hat letzte Woche in ihren eigenen Beta- und Entwicklungsviewern den Kommandozeilenparameter „-loginURI“ ersatzlos gestrichen, mit dem es bisher möglich gewesen ist mit Linden Labs eigenen Viewern per Hand andere Grids anzusteuern.

Dazu gibt es folgenden Chatlog mit Oz Linden, in dem er es Nebadon Izumi erklärt:

[10:07] <nebadon> OzLinden : ping
[10:09] <OzLinden> pong
[10:10] <nebadon> are you guys really removing -loginURI support from the viewer?
[10:10] <nebadon> or is that just a mistake?
[10:10] <nebadon> cause latest Dev and Beta viewers get an error if you try to use it
[10:11] <OzLinden> that was deliberate, but there is a related bug that I’m working on now
[10:12] <nebadon> ok so it will eventually be back?
[10:12] <OzLinden> no, I don’t believe so
[10:12] <nebadon> why is it being removed?
[10:13] <OzLinden> part of cleaning up grid handling – it really doesn’t serve much useful purpose
[10:13] <nebadon> sure it does
[10:13] <nebadon> it lets us connect to opensim
[10:14] <nebadon> this essentially kills all support for OpenSim
[10:14] <OzLinden> which our Havok license does not allow

Kurz und gut: der Parameter wurde aufgrund von internen Bereinigungen am Gridhandling entfernt, da er zudem nicht wirklichen Sinn gemacht hätte. Nebadon warf ein, der Parameter hätte sehr wohl Sinn gemacht, da man so mit Linden Labs Viewern zu Opensim hätte verbinden können, worauf Oz Linden einwarf, dass die Havok Lizenz, welche Linden Lab erworben hat, genau das verbietet. Zur Erinnerung: wegen der Einführung des Pathfindings hat Linden Lab dem Viewer selber Teile von Havok beilegen müssen.

Was bedeutet das nun für die Zukunft? Die Mehrheit der Opensimbewohner hat ohnehin nicht Linden Labs eigenem Viewer benutzt, man bevorzugt Hippo, Imprudence und Singularity, sie wird es wohl kaum vermissen.

Für Viewerentwickler wiederum wird es nur dann interessant, wenn auch sie Pathfinding aktiv haben wollen, denn dann darf auch deren Viewer nur zu Second Life verbinden können. Firestorm hat das Problem so gelöst, indem es nun einen Firestorm für SL gibt und einen eigenen für Opensim geben soll.

Dass so etwas kommen wird, war klar. Die Auswirkungen sind aber wesentlich weniger drastisch, als mancher meinen könnte. Bei Hypergrid Business jedenfalls haben sie ein Fass aufgemacht und dabei alles zu Wort kommen lassen, was im Bereich Opensim Rang und Namen hat. Natürlich steht es jedem Entwickler von alternativen Viewern nach wie vor frei, diese Funktionalität wie auch immer geartet im eigenen Produkt zu bieten, sei es als Kommandozeilenparameter oder Gridmanager. Linden Lab jedenfalls wird das nicht mehr tun.

Kokua Viewer Beta Downloads

Es ist ja schon seit längerem still geworden um den Imprudence-Viewer bzw. dessen offiziellen Nachfolger Kokua. Jacek Antonelli hörte bereits vor Monaten auf, an den Viewern zu entwickeln und Nicky Perian übernahm das Ruder.

Nur weil es aber im Blog von den Machern still geworden ist, so heißt das noch lange nicht, dass sie nicht weiter am Viewer arbeiten würden. Weit gefehlt, am Kokua Viewer wird gerade munter geschraubt und gehämmert, und es gab einige Ankündigungen von Nicky Perian in der Opensim-Users-Mailingliste, das neue Betas zum Download bereit stünden.

Interessant ist das auch und vor allem für Benutzer von 64bit-Linux, da es Kokua in einer nativen Version für diese Plattform gibt.

Also – wer Kokua in der aktuellen Beta mal testen will, der wird hier fündig: https://bitbucket.org/NickyP/kokua-dev/downloads. Es gibt dort Downloads für Linux und Windows, der Stand ist Mitte Juni. Have fun!

Captain Obvious reitet wieder

Im März wurde Oz Linden bei Treet.TV zur Viewerentwicklung befragt. Unter anderem ließ er dabei diese Aussage vom Stapel:

„Our own viewer users are a minority. A significant minority — we’re the number three viewer behind, behind the two… Phoenix is far and away the number one viewer, although it’s quite steadily losing market share these days, has been for some months now. And Firestorm is the newer technology viewer from your project, is the number two, and it’s gaining market share… And our viewer is number three behind Firestorm.“

Damit bestätigt er nur das, was man mit den Viewertags alltäglich sah und sich so noch immer dachte: die Benutzer des lindeneigenen Viewers sind eine Minderheit. Die meisten Benutzergruppe hat nach wie vor der Phoenixviewer, der sich auf Platz 1 befindet aber an Marktanteilen verliert, gefolgt vom Firestormviewer, der Marktanteile langsam aber stetig gewinnt, und der Lindenviewer kommt dann auf Platz 3.

Vielleicht sollte Lindenlab die Macher vom Firestorm einfach einstellen und den eigenen Viewer einstampfen, das wäre mal ein Zug, den viele sicherlich begrüßen würden.

Gamification – ein Weg auch für den offiziellen Second Life Viewer?

Nirans Viewer macht es mit dem Release 1.36 gerade vor: es ist ein Errungenschaftssystem (Englisch: Achievements) eingebaut, wie man es von moderneren Spielen und MMORPGs kennt. Wie das aussieht, kann man bei Maddy ausführlich bewundern, daher erspare ich mir hier einfach die Screenshots davon.

Zudem ist der Viewer inzwischen offiziell in der TPVD drin, herzlichen Glückwunsch!

Nun ist es ja so, dass nach Rod Humble Linden Lab im Moment genau darauf setzt, was Niran vormacht, nämlich Gamification. Achievementsysteme sind irgendwie das neue Buzzword in der Branche, und werden in Zukunft häufiger vorkommen, als man meint. Selbst so dröge Software wie die Compilersuites von Microsoft sollen Achievementsysteme verpasst bekommen, um die Programmierer zu Entdeckungen und besserer Arbeit zu animieren. Muss also was dran sein, und man kann sich das bei Kleinstweich für umme bereits runterladen!

Niran und Microsoft zeigen, was Gamification bedeuten kann. Nachdem Rod Humble in der Spieleindustrie jahrzehntelange Erfahrung hat, weiß er das auch auf dem Effeff. Die Frage ist daher: wie lange dauert es denn noch, bis auch der offizielle Lindenviewer solch ein System spendiert bekommt? Ist so etwas bei Linden Lab überhaupt bereits in Planung? Denn wenn Linden Lab es ernst mit der Gamification ist, dann wird sich das zu alleerst im Viewer zeigen müssen, wo denn auch sonst!

Linden Lab könnte es sich sogar einfach machen und einfach Nirans Änderungen bei sich für umsonst einbauen, the joy of open source eben! Ob sie das aber machen oder nicht – wir werden sehen. Jedenfalls erwarte ich früher oder später solch ein System auch im offiziellen Lindenviewer, alles andere widerspricht dem neuen Credo der Firma.