Ein fremdes Statistik-Plugin forken und umlackieren

Für Spielerstatistiken gibt es ein etabliertes Plugin mit eigener Weboberfläche: Spielzeit, Sitzungen, Aktivität, Serverauslastung, alles fertig. Es läuft bei mir seit Wochen, und es tut, was es soll.

Was es nicht tut: aussehen wie mein Netzwerk. Die Oberfläche ist die des Projekts, mit dessen Farben und dessen Aufbau — und sie liegt unter einer Adresse meines Netzwerks, was den Bruch besonders sichtbar macht.

Seit heute läuft ein eigener Fork.

Die Entscheidung, die ich mir schwer gemacht habe

Ich habe abgeraten. Von mir selbst.

Ein Fork eines aktiv gepflegten Projekts ist etwas anderes als der Fork eines verwaisten. Beim verwaisten übernimmt man ein totes Projekt — es gibt nichts, was einem davonläuft. Bei einem lebenden übernimmt man eine dauerhafte Aufgabe: Jede neue Fassung des Originals muss man einarbeiten, und je mehr man ändert, desto schwieriger wird das.

Die Alternative wäre gewesen, die Oberfläche in Ruhe zu lassen und stattdessen die Daten über eine Schnittstelle abzurufen und selbst darzustellen.

Die Entscheidung fiel trotzdem für den Fork, aus einem Grund, den ich nachvollziehen kann: Das Ziel ist nicht eine Seite mit denselben Zahlen, sondern dieselbe Funktionsvielfalt in einer Optik, die zum Rest passt. Ein Nachbau hätte Monate gedauert und wäre schlechter geworden.

Was ich mir dafür aufgeschrieben habe: die Update-Last ist bekannt und akzeptiert. Das ist ein Unterschied zu einer Entscheidung, die man später bereut, weil man die Folgen nicht bedacht hat.

Wie man so etwas sauber aufsetzt

Der wichtigste Teil ist die Ordnung, in der das Projekt liegt.

Das Original bleibt als Fernquelle eingetragen, unter einem eigenen Namen. Damit kann man jederzeit die neuen Änderungen holen und einarbeiten.

Die eigene Arbeit liegt in einem eigenen Zweig, nicht im Hauptzweig. Dann bleibt der Hauptzweig ein sauberer Spiegel des Originals, und die eigene Arbeit ist als solche erkennbar.

Die Basis ist ein bekannter Stand. Bei mir liegt zwischen dem laufenden Stand und dem Ausgangspunkt des Forks ein knappes Dutzend Änderungen des Originals — der erste Ausrollvorgang bringt also fremde Änderungen mit. Das ist wichtig zu wissen, wenn danach etwas anders ist als vorher.

Warnung

Eine praktische Falle beim Bauen: Die Versionsnummer des Projekts entsteht aus der Anzahl der Änderungen in der Historie. Wer flach klont — also nur die letzten Stände holt —, bekommt eine unsinnige Nummer, und zwar ohne Fehlermeldung. Mein Bauskript bricht inzwischen ab, wenn die Zahl unplausibel ist, statt still etwas Falsches zu bauen. Solche Selbstprüfungen im Bauvorgang sind billig und ersparen die Frage, warum die ausgelieferte Fassung sich merkwürdig verhält.

Was ich zuerst geändert habe

Die Optik. Farben, Schriften, Abstände, Aufbau der Übersichtsseite — angeglichen an meine Hauptseite. Nicht als Anstrich, sondern konsequent: Wer von der Hauptseite auf die Statistiken klickt, soll nicht merken, dass er eine andere Anwendung betritt.

Die Skins der Bedrock-Spieler. Das ist der inhaltlich interessanteste Teil.

Die Oberfläche zeigt zu jedem Spieler seinen Kopf, den sie von einem Dienst für Java-Konten holt. Bedrock-Spieler haben dort kein Konto — sie bekommen entweder einen Platzhalter oder, schlimmer, das Bild eines fremden Java-Kontos mit zufällig ähnlichem Namen.

Bedrock-Konten haben eine eigene Kennung, und die steckt in der Spielerkennung, die die Kontenbrücke erzeugt. Aus ihr lässt sich das richtige Bild ermitteln. Der Fork prüft also zuerst, ob es sich um ein Bedrock-Konto handelt, und wählt danach die Quelle.

Das ist eine kleine Änderung mit großer Wirkung für einen Server, auf dem die Hälfte der Leute von Konsole und Handy kommt — und ein gutes Beispiel dafür, warum ein Fork manchmal die richtige Antwort ist. Diese Anpassung würde in ein allgemeines Projekt nur passen, wenn sie dort jemand pflegen will.

Die Lizenzfrage

Ein Punkt, den ich vor der ersten Zeile geklärt habe: Das Projekt steht unter einer Lizenz, die interne Nutzung und Änderung erlaubt — bei Weitergabe aber verlangt, dass der Quelltext mitgeht.

Für mich heißt das konkret: Ich darf den Fork betreiben, ich darf ihn ändern, und ich dürfte ihn nicht als geschlossenes Produkt verkaufen. Das ist für meinen Fall völlig in Ordnung, und es steht als Vermerk neben dem Projekt — damit die Frage in einem Jahr beantwortet ist, bevor sie sich stellt.

Wie ich Änderungen des Originals einarbeite

Ein Fork lebt davon, dass man ihn aktuell hält. Bei mir läuft das nach einem festen Ablauf, ungefähr monatlich.

Änderungen des Originals holen — in den Zweig, der ein reiner Spiegel ist. Dort wird nichts von mir geändert.

Ansehen, was dazugekommen ist. Nicht jede Änderung ist relevant. Interessant sind die, die Bereiche betreffen, an denen ich gearbeitet habe.

Zusammenführen und Konflikte lösen. Die entstehen genau dort, wo ich Dateien geändert habe — also in der Optik und an der Stelle mit den Spielerbildern.

Bauen und prüfen. Läuft es, sieht es aus wie vorher, funktioniert die eigene Anpassung noch?

Der zweite Schritt ist der, den ich anfangs übersprungen habe, und das war ein Fehler. Wer Änderungen ungelesen übernimmt, weiß hinterher bei einem Problem nicht, ob es an einer eigenen oder einer fremden Änderung liegt.

Was ich beim Umgestalten fremder Oberflächen gelernt habe

Eine fremde Oberfläche an das eigene Aussehen anzupassen, ist mehr Arbeit als eine eigene zu bauen — und zwar aus einem Grund, den ich unterschätzt hatte.

Fremde Oberflächen haben Annahmen, die man nicht sieht. Ein Abstand, der an drei Stellen gebraucht wird. Eine Farbe, die gleichzeitig für einen Zustand steht. Eine Schriftgröße, an der eine Zeilenumbruchsberechnung hängt.

Wer nur Farben tauscht, bekommt ein Ergebnis, das an einzelnen Stellen bricht — meistens in Ansichten, die man beim Testen nicht geöffnet hat.

Was funktioniert hat: Erst die Struktur verstehen, dann die Variablen finden, dann ändern. In einem gut gebauten Projekt gibt es eine zentrale Stelle für Farben und Abstände. Wenn es sie gibt, ist die Anpassung überschaubar. Wenn nicht, ist eine vollständige Umgestaltung ein eigenes Projekt — und dann wäre die Frage neu zu stellen, ob ein Fork der richtige Weg ist.

Was ich mitnehme

Ein Fork ist eine Entscheidung über die Zukunft, nicht über die Gegenwart. Die Frage ist nicht „kann ich das ändern", sondern „will ich das die nächsten Jahre pflegen".

Wenn man forkt, dann ordentlich. Eigener Zweig, Original als Quelle eingetragen, bekannter Ausgangspunkt, Selbstprüfungen im Bauvorgang. Der Unterschied zwischen einem gepflegten Fork und einem Haufen geänderter Dateien ist ungefähr der zwischen einem Projekt und einer Sackgasse.