Im Open Source Bereich gibt es immer wieder Projekte, die sich aufspalten (d. h. ‘forks’ = Gabelungen im Entwicklungsbaum bilden). Die Gründe dafür sind meist unterschiedliche Interessen verschiedener Nutzergruppen. Das bekannteste Beispiel sind die Linuxvarianten und deren Hauptlinien RedHat bzw. Debian. Solange sich hinter den jeweiligen Entwicklungslinien genügend Entwicklerpower befindet, und die Entwicklungen sich gegenseitig befruchten, ist diese Tendenz gut. Konkurrenz belebt das Geschäft und Variation fördert Fortschritt.
Anders sieht es aus, wenn die Gabelei zur Verzettelung führt und jeder sein eigenes Süppchen kocht. Dann herrscht schnell Chaos und keiner weiss mehr, welche Entwicklungslinie welchen Zustand hat. Linien mit unterbesetzter Entwicklung und geringer Nutzerbasis kommen für professionelle Anwendungen nicht in Frage. Die langfristigen Perspektiven sind zu unsicher. Und alles, was nicht regelmäßig mit der Hauptentwicklungslinie abgeglichen wird, läuft Gefahr eine proprietäre Sackgasse zu werden.
Man kann dem entgegenwirken, indem die Änderungen zur Hauptentwicklungslinie in Form sogenannter Patches konstruiert werden: Original+Anpassungen=modifizierte Version
Vorteil:
Ändert sich das Original, kann durch Anwendung der Patches jederzeit eine aktuelle modifizierte Version erstellt werden. Aktualität, Qualität und Transparenz sind das Ergebnis.
Nachteil:
Die Arbeit an der abweichenden Version muss aufwändig in Patches gegossen werden. Die Patches müssen häufig nachgepflegt werden. Dies führt zu höherem Aufwand und macht mehr Disziplin erforderlich.
Das ist aber der Preis für den Umgang mit Standards. Solange mein Projekt nicht groß genug ist, einen eigenen Standard zu definieren, muss ich mein Projekt an einen anderen Standard anlehnen. Nur so kann ich meinen Nutzern Sicherheit geben und auf Akzeptanz hoffen.
Im OpenSimulator-Bereich wird dies leider nirgendwo konsequent berücksichtigt.
Alle Third-Party-Viewer sind inzwischen unkontrollierte Abwandlungen von den originalen Second Life Viewern. Keiner kann mehr beurteilen, wie lange eine Variante noch existieren wird und welche Qualität sie hat. Die originalen Second Life Viewer haben dagegen immer noch die größte Nutzerbasis und werden kommerziell weiterentwickelt.
Also wäre ein auf Patches basierendes Entwicklungsverfahren für Third-Party-Viewer zu bevorzugen. Nur der Cool VL Viewer hat dies in seiner Anfangszeit mal eine Weile so gemacht.
Im Serverbereich ist die OpenSimulator-Hauptentwicklungslinie der Standard. Eine große Nutzerbasis und ein stabiles Kernentwicklerteam versprechen Qualität und Nachhaltigkeit, auch wenn nicht auf jeden Wunsch der Community eingegangen wird.
Der von der Aurora-Sim eingeschlagene Weg ist dagegen auf Dauer nicht durchzuhalten. Eine Abkopplung vom Original, die geringe Nutzerbasis und kleines Team führen langfristig in eine proprietäre Sackgasse.
Besser wäre eine Umstellung auf ein auf Patches basierendes Entwicklungsverfahren, in dem Aurora seine Abweichungen zur OpenSimulator-Hauptlinie klar definiert und somit auch die Rückführung von Anpassungen fördert. Aurora könnte sich so als OpenSimulatorPlus darstellen, da das Projekt eine Ansammlung von communityorientieren Verbesserungen wäre.
In der aktuellen Form sehe ich für Aurora allerdings keine dauerhaften Perspektiven, es wird wohl eher zu einem zweiten RealXtend werden.