Ein Jahr Frist, dann ist der Baustein weg

Cloudflare übernimmt das Team hinter Deno, und der dazugehörige gehostete Betrieb wird in einem Jahr eingestellt. Deno ist eine Laufzeitumgebung für JavaScript, also die Schicht, auf der ein Teil moderner Web-Software überhaupt erst läuft. Ein Kommentar bei heise misst das Projekt an dem, womit es angetreten war, nämlich an Unabhängigkeit von einem großen Anbieter. Die Meldung und die Einordnung aus der Entwicklergemeinde findest du auch bei LWN.

Für dich als Auftraggeber ist die interessante Frage nicht, ob Deno eine gute Technik war. Sie war es. Die interessante Frage ist, was passiert, wenn so etwas tief in deiner Software steckt und du es erst erfährst, wenn der Abschalttermin schon steht.

Der Ärger kommt selten vom großen Ding

Ein Warenwirtschaftssystem wird nicht abgekündigt, ohne dass du es mitbekommst. Gefährlich sind die kleinen Bausteine, über die nie jemand mit dir gesprochen hat, weil sie beim Bauen selbstverständlich waren. Die Bibliothek, die eure PDF-Rechnungen erzeugt. Der Dienst, der die Hintergrundaufgaben nachts abarbeitet. Die Laufzeitumgebung, auf der das Kundenportal läuft.

Solche Teile tauchen in keinem Angebot auf, wenn niemand danach fragt. Und sie verschwinden nicht mit einem Knall, sondern mit einer Mail an Entwickler, die du nie zu Gesicht bekommst.

Vier Fragen, bevor du den Auftrag unterschreibst

Du musst dafür nicht verstehen, was eine Laufzeitumgebung ist. Du musst vier Antworten schriftlich haben.

Erstens. Auf welchen fremden Bausteinen steht das, und wer steht dahinter? Frag nach einer kurzen Liste der tragenden Teile, fünf bis zehn Zeilen, mit je einem Satz dazu, wer das Projekt betreibt und wie es sich finanziert. Ein Projekt hinter einer Stiftung verhält sich anders als eines hinter einer Firma, die gerade Kapital eingesammelt hat.

Zweitens. Wie tief sitzt der Baustein? Es gibt einen Unterschied zwischen einer Bibliothek, die an drei Stellen aufgerufen wird, und einer Laufzeitumgebung, auf der alles aufsetzt. Die Antwort lautet idealerweise „an dieser einen Stelle, dahinter beginnt unsere eigene Logik".

Drittens. Gibt es etwas Zweites, das dasselbe kann? Wenn der Baustein einen offenen Standard bedient, gibt es Ersatz. Wenn er eine Eigenheit eines Anbieters bedient, gibt es Umbau.

Viertens. Was kostet der Ausstieg, grob geschätzt, heute? Nicht auf den Tag genau. Es reicht die Größenordnung. Zwei Entwicklertage, zwei Wochen oder drei Monate sind drei völlig verschiedene Antworten, und jede davon ist brauchbar. Keine Antwort ist die einzige schlechte.

Woran du im Angebot erkennst, wie austauschbar etwas ist

Du brauchst dafür keinen Code zu lesen. Es gibt Signale, die du im Text siehst.

• Es werden Standards genannt und nicht nur Produktnamen. Eine PostgreSQL-Datenbank, S3-kompatible Dateiablage, Container nach OCI, Mail über SMTP. Das sind Dinge, für die es mehrere Anbieter gibt.
• Zwischen eurer Fachlogik und dem fremden Dienst liegt eine eigene Schnittstelle. Im Angebot klingt das nach Mehraufwand von ein, zwei Tagen. Es ist die Stelle, an der der Austausch später stattfindet, statt im ganzen Projekt verteilt.
• Es gibt Tests für eure Abläufe, nicht nur für die Anbindung. Wenn geprüft wird, dass aus einem Auftrag die richtige Rechnung wird, bleibt diese Prüfung auch nach einem Anbieterwechsel gültig. Sie ist die Zusage, dass nach dem Umbau noch dasselbe herauskommt.
• Die Betriebsfrage ist beantwortet. Wo läuft das, wer pflegt es, und wie kommt man wieder weg.
• Es steht da, in welchem Format deine Daten herausfallen. „Export vorhanden" ist zu wenig. Ein Export, den ein anderes System einlesen kann, ist die Zusage.

Beim Betrieb hast du übrigens drei Wege und nicht zwei. Du kannst selbst betreiben, mit eigenen Leuten. Du kannst pro Kopf und Monat mieten. Und dazwischen liegt der Weg, auf dem fremde Software auf einem Server läuft, der dir gehört, gepflegt von jemand anderem. In dieser Kategorie arbeiten wir, und sie ist der Grund, warum ein Anbieterwechsel bei uns ein Umzug ist und keine Rettungsaktion.

Ein Beispiel aus unserem eigenen Betrieb, weil du es sonst nirgends nachlesen kannst. Die Plattform für Kunst gegen Bares erzeugt Textvorschläge pro Kanal mit einem Cloud-Modell. Der Aufruf dafür liegt hinter einer eigenen Schnittstelle, weil wir damit rechnen, dass sich Preise, Modelle und Anbieter mehrfach ändern, bevor sich die Arbeitsweise der Bühne ändert. Veröffentlicht wird über einen externen Dienst, und das bleibt auch so, denn wer auf Instagram posten will, schickt Daten zu Instagram. Austauschbar ist nicht dasselbe wie hausintern.

Wer entscheidet, ob ihr umbaut

Eine Abkündigung mit einem Jahr Frist ist kein Notfall. Sie ist ein Termin im Kalender. Und sie ist genau die Art von Entscheidung, die kein System für euch treffen sollte, auch keins, das sonst gut automatisiert.

Der Entwickler liefert den Befund und zwei Zahlen. Was kostet der Umbau jetzt, und was kostet es, bis zum letzten Monat zu warten. Dazu gehört ein Satz dazu, was passiert, wenn ihr gar nichts tut. Manchmal lautet die ehrliche Antwort, dass das Teil nach dem Abschalttermin einfach weiterläuft, weil es bei euch auf eigener Hardware liegt und nur keine Updates mehr bekommt. Das ist ein Risiko, aber ein kalkulierbares.

Entschieden wird das von dir. Du weißt, ob im Frühjahr die Saison anläuft, ob gerade eine Zertifizierung ansteht und ob zwei Wochen Entwicklerzeit dieses Quartal überhaupt frei sind. Die Maschine kann dir die Liste der betroffenen Stellen in einer Stunde hinlegen, wofür ein Mensch zwei Tage bräuchte. Welche davon ihr anfasst, bleibt eine Frage mit eurem Geld und eurem Kalender darin.

Und wenn dir heute niemand sagen kann, welche fremden Bausteine in eurer Software stecken, ist das die erste Aufgabe. Nicht das Umbauen.