Hallo da draußen!

Einige wenige werden es mitbekommen haben: Das „KOMA-Script Documentation Project“ geht auf komascript.de seinem Ende entgegen. Seit einigen Wochen lösche ich fast jeden Tag Dutzende von Benutzer-Accounts und die zugehörigen Inhalte.

Nachdem ich gerade entdeckt habe, dass komascript.de seit nunmehr 21 Jahren unter Drupal läuft (davor war es schon als Zope-Site vorhanden), erfasst mich nun doch ein wenig Wehmut. Das ist rund 2/3 der Zeit, die ich nun schon an KOMA-Script arbeite. Gesponsort wird die Domain von Anfang an von Robin (von dem ich gar keine gütige E-Mail-Adresse mehr habe). Der Server wird ebenfalls seit 21 Jahren zumindest größtenteils von ein paar freundlichen Recken zur Verfügung gestellt und in Betrieb gehalten. Hin und wieder haben sich auch einzelne KOMA-Script-Anwender an den Kosten beteiligt.

Für mich steht außer Frage, dass tiefgreifende Veränderungen stattfinden und weiter anstehen. Deshalb will ich heute einen kleinen Rückblick auf fast 30 Jahre KOMA-Script und mehr als 30 Jahre LaTeX-Engagement werfen. Aus der angerissenen Geschichte leiten sich Konsequenzen ab, die teils längst erkennbar sind. Weitere Veränderungen sind notwendig und sollen nicht verheimlicht werden, ohne dass irgend jemand heute konkret sagen könnte, was die Zukunft tatsächlich bringen wird. Den Kopf in den Sand zu stecken, wird aber nicht mehr funktionieren.

Wer auf komascript.de aufmerksam mitliest, weiß schon länger, dass einige Entscheidungen anstanden und teilweise noch anstehen. Diese sollen dringend notwendige Veränderungen für mich mit sich bringen, haben aber natürlich auch Auswirkungen auf die Anwender. Mit dem neuen Jahr – oder eigentlich bereits kurz vor Weihnachten – sind die meisten dieser Entscheidungen gereift.

Seit mehr als 25 Jahren entwickle und pflege ich KOMA-Script quasi als One-Man-Show. So ganz stimmt das natürlich nicht, denn schon sehr früh bekam ich erste Unterstützung. Damals übernahm Luzia den Upload von KOMA-Script auf den CTAN-Server, weil es für mich extrem umständlich war, per Modem und VT220-Terminal-Zugang zur Uni das damals schon nicht kleine Paket zuerst auf meinen Benutzeraccount an der Uni zu übertragen und dann per ftp auf den CTAN-Server. Axel/Harald schrieb die erste vollständige Anleitung zu KOMA-Script. Der andere Axel steuerte die erste Briefklasse bei. Jahre später investierte Jens-Uwe sehr viel Zeit, die Überarbeitung der Anleitung und die Veröffentlichung als Buch zu betreuen und auch einige Kapitel der neuen Anleitung beizusteuern. Torsten wurde in dieser Zeit unverzichtbar als Ratgeber bei der Entwicklung einer komplett neuen Briefklasse aber auch bei der fortgesetzten Korrektur der Anleitung. Wenige Jahre später wurde Elke für die Weiterentwicklung des Pakets und die Korrektur der Anleitung und der Buchfassung aber auch für den Support im Allgemeinen unverzichtbar. Falk wiederum findet seit Jahren die Fehler, die so tief in KOMA-Script vergraben sind, dass ihre Beseitigung mir immer wieder erhebliche Kopfschmerzen bereitet. Dasselbe gilt für die vielen Anregungen und Erweiterungen, die auf ihn zurück gehen. Uwe hat seit der Jubiläumstagung von DANTE in Heidelberg die Verwaltung der CTAN-Uploads übernommen. Nach Elke, die die komplette Familie dafür eingespannt hat, haben zunächst unter anderem Gernot, dann Krickette und schließlich Karl sich der Übersetzung der KOMA-Script-Anleitung angenommen und diese massiv überarbeitet. Viele weitere stießen im Laufe der Jahrzehnte zum inoffiziellen Team, manche sind wieder in der Versenkung verschwunden. Ohne die ganzen Mitstreiter wäre die Arbeit aber auch der immer wieder entstehende Frust nicht zu bewältigen gewesen. Eine wichtige Rolle haben dabei natürlich auch diejenigen gespielt, die mich auf unterschiedliche Weise aufgemuntert und ermutigt haben. Eine zentrale Rolle spielte auch meine Familie, die mir überhaupt ermöglicht haben, Jahre in die Entwicklung und Pflege dieses Monsters zu stecken.

Die Parole vom Abschneiden alter Zöpfe wird immer wieder gerne gebraucht. Einige Zeitgenossen meinen ja, TeX selbst sei so ein alter Zopf. Tatsächlich aber ist die Gemeinschaft derer, die mit und an TeX arbeiten, aktiver als selten zuvor. LaTeX galt lange Zeit als stabil, womit eigentlich eher statisch bis hin zur Stagnation gemeint war. Seit letztem Jahr ist das wieder erkennbar anders. Das LaTeX-Team baut Verbesserungen wieder direkt in LaTeX ein, Kompatibilität gibt es nur bei expliziter Auswahl einer bestimmten Version.¹ Stabil im besten Sinne ist LaTeX trotzdem weiterhin. Die Progressivität spielt sich hauptsächlich unter der Oberfläche und in der Verbesserung des Ergebnisses ab.

Und manchmal kann man von außen nur schwer erkennen, wie groß diese Schritte tatsächlich sind. Letzteres betrifft aus meiner begrenzten Zwergensicht beispielsweise den LaTeX-Kern. Der wurde in den letzten Wochen massiv an Änderungen bei lualatex angepasst. Diese Änderungen bemerkt der LaTeX-Anwender im Idealfall gar nicht. Anwender von lualatex würden hingegen sehr stark bemerken, wenn es diese Änderungen nicht geben würde, sie aber trotzdem beispielsweise lualatex aus dem kommenden TeX Live 2016 verwenden würden.

Wie ich entdeckt habe, gibt es zwar keinen direkten Zugriff auf die alten Repositories mehr, aber man kann indirekt über das Web-Frontend noch darauf zugreifen. Da das noch ein altes CVS-Repository war, gibt es keine globale Revisionen, sondern jede Datei hat ihre eigene Historie und ihre eigene von den anderen Dateien unabhängige Revisionsnummern. Also musste ich nicht nur ein Skript schreiben, das mir über das Web-Frontend die Dateien holt, um die Historie (allerdings ohne jeweiliges Datum) zu übertragen, musste ich auch noch die Dateien in der jeweiligen Revision in der richtigen Reihenfolge holen, um sie in ein neues subversion-Repository zu schreiben. Dazu mussten dann die Änderungen, die ich in letzter Zeit über ein neues, lokales Repository vorgenommen hatte, ebenfalls übertragen werden. Das ging aber Dank globaler Revisionsnummern dann schnell. Jetzt habe ich also ein neues (nicht öffentliches) Repository mit der gesamten Historie.

Aufgrund verschiedener Umstände stapelte sich Anfang der Woche hier die Wäsche. Da ich aufgrund beschränkter Leinenkapazität nur eine bestimmte Menge an Wäsche gleichzeitig zum Trocknen aufhängen kann, ziehen sich die Waschtage über die ganze Woche hin. Ein Teil der Wäsche kann auch in den Trockner. Die Wäsche braucht auch unterschiedlich lang und zwischendurch gibt es immer Zeiten an denen ich weder Zeit zum Aufhängen noch zum Umräumen in den Trockner und Neubeladen der Waschmaschine habe. Auch brauchen Waschmaschine und Trockner teilweise unterschiedlich lang. Deshalb will das Ganze gut geplant sein.

[als damals beim Ende von BerlIOS]

Wie ich gerade feststellen durfte, hat Sarovar.org, der langjährige Hoster von splitindex, am 26. Dezember ebenfalls die Pforten geschlossen. Allerdings habe ich von dem keine Vorwarnung bekommen. Die gab es wohl im Sarovar-Forum, das ich nie verfolgt habe. Bemerkt habe ich das erst jetzt, als ich eine neue Version einchecken wollte. Damit geht die gesamte Historie des Pakets verloren. Nun, es gibt sicher schlimmeres, aber ein wenig ärgerlich ist es doch. Außerdem muss ich nun auch noch für dieses Paket irgendwo ein neues Projekt aufsetzen …

Da es unmöglich war, mit einem sinnvollen zeitlichen Aufwand, alle notwendigen Information zur automatischen Migration nach SourceForge von den Verantwortlichen bei BerliOS zu bekommen, habe ich heute Vormittag in einer Nach-und-Nebel-Aktion die Quellen von KOMA-Script selbst nach SourceForge migriert.

Für diejenigen unter Euch, die mit dem Repository arbeiten, bedeutet das, dass sie ebenfalls zum SourceForge Repository von KOMA-Script wechseln müssen.

Mich selbst wirft das in einigen wenigen Punkten etwas zurück, weil ich beispielsweise die weitgehend automatisierte Erstellung neuer Pakete und Releases noch auf dieses Repository umstellen muss. Allerdings war mir die Gefahr, dass der Umzug dann schief geht, wenn ich nur noch Stunden dafür habe, einfach zu groß.

Seit mehr als einem Jahrzehnt ist KOMA-Script als Projekt bei BerliOS beheimatet. Entstanden ist die Partnerschaft, als ich für KOMA-Script 3 eine Heimat für ein öffentliches Source-Repository gesucht habe. Damals gab es mit LPPL als Lizenz bei diversen der bekannteren, kostenlosen OpenSource Hoster noch einige Probleme. BerliOS erkannte aber bereits damals LPPL als freie Lizenz an. Außerdem fand ich den Gedanken, meine Quellen nicht jedes Mal über sämtliche Kontinente zu schicken, vernünftig. Beides zusammen war der Hauptgrund, warum ich mich damals zu einem Projekt koma-script3 auf BerliOS entschieden habe.