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.

Wieder einmal eine neue KOMA-Script-Release und wieder einmal dasselbe Theater, wie es in unregelmäßigen Abständen auftritt, wenn ich eine neue Release für eines meiner LaTeX-Pakete erstelle. Da dies auch in die Frage hineinspielt, warum es tatsächlich bis zu dieser KOMA-Script-Release so lange gedauert hat und warum es beispielsweise das titlepage-Paket nur hier auf komascript.de nicht aber bei anderen Distributoren gibt,¹ wäre es unehrlich, das ganze einfach unter den Teppich zu kehren.

Das ist eine gute Frage und es gibt darauf nur eine recht schlechte Antwort: Weil ich selbst keinen Bedarf dafür habe.

Tatsache ist, dass ich zwar seit Jahrzehnten vom Bauplan bis zum Roman alles mit LaTeX erstelle und dabei fast immer KOMA-Script zum Einsatz kommt. Seit Jahren kann KOMA-Script allerdings alles, was ich benötige. Außerdem nimmt die Anzahl der Dokumente, die ich erstelle, stetig ab, bzw. erstelle ich die immer gleiche Art von Dokumenten lediglich mit anderem Inhalt. Das führt dazu, dass ich selbst neue Features in KOMA-Script nicht mehr hinreichend gut im täglichen Gebrauch testen kann. Selbst, wenn ich für alle meine Dokumente die aktuelle Beta-Version von KOMA-Script verwende, werde ich daher neue Fehler kaum finden.