Was mit Ihrer Software passiert, wenn ihr Autor verschwindet

Es kommt häufiger vor, als man denkt: der Entwickler schließt, der Dienstleister wechselt das Geschäft, die Person, die wusste, wie es funktioniert, geht. Und das System, auf dem das Unternehmen läuft, wird zu einer Kiste, die niemand öffnen kann.

Das ist ein reales Risiko, und niemand schreibt es ins Angebot, weil es beim Unterschreiben unangenehm zu benennen ist. Vier Dinge verringern es.

1. Die Schlüssel in Ihrer Hand

Domains, Hosting, Postfächer, Konten externer Dienste, Archive: auf Ihren Namen, mit den Zugangsdaten in Ihrem Besitz, ab dem ersten Tag. Nicht „die gebe ich Ihnen, wenn wir fertig sind“: ab dem ersten Tag.

Das ist am leichtesten zu bekommen und macht den größten Unterschied. Haben Sie Zugriff auf die Infrastruktur, kann ein anderer Dienstleister in Tagen übernehmen. Haben Sie ihn nicht, kann allein das Auffinden der Dinge einen Monat dauern — und manchmal ist gar nichts mehr zu retten.

2. Exportierbare Daten

Lassen Sie sich vor der Unterschrift zeigen, wie sich die Daten in ein Format exportieren lassen, das ein anderes Programm lesen kann. Kein proprietäres Format: eine CSV, ein SQL-Dump, eine JSON-Datei.

Lautet die Antwort „das ist nicht vorgesehen“, wissen Sie bereits, dass die Beziehung nur in eine Richtung läuft.

3. Ein Dokument, das erklärt, wie es gebaut ist

Es braucht kein hundertseitiges Handbuch. Es braucht fünf niedergeschriebene Dinge: wo es läuft, welche externen Dienste es nutzt, wie man im Notfall hineinkommt, wie der Code organisiert ist, was regelmäßig aktualisiert werden muss.

Wer Software ordentlich schreibt, hat dieses Dokument bereits, weil er es selbst zuerst braucht. Danach zu fragen ist ein indirekter Weg zu verstehen, wie jemand arbeitet.

4. Lesbarer Code

Das können Sie selbst nicht prüfen, und es ist das einzige der vier Dinge, das Vertrauen verlangt. Aber Sie können eine Frage stellen, die viel verrät: „wenn in drei Jahren jemand anderes daran arbeiten muss, wie lange braucht er, um es zu verstehen?“

Wer antwortet „das ist alles im Code dokumentiert“, antwortet gut. Wer antwortet „uns gibt es doch noch“, beantwortet eine andere Frage — und vielleicht ist genau das der Punkt.

Die Unterscheidung beim Eigentum

Sie gehört vorab geklärt, weil sie Missverständnisse erzeugt: die Daten und die Infrastruktur gehören Ihnen, immer. Das Eigentum am Quellcode ist etwas anderes und bleibt oft bei dem, der ihn geschrieben hat, sofern er nicht vollständig erworben wird — was Sie erhalten, ist das Nutzungsrecht.

Das ist an sich weder richtig noch falsch: es ist eine Vertragsbedingung, und als solche gehört sie vor Projektbeginn schriftlich festgehalten, statt hinterher entdeckt zu werden. Ein Anbieter, der sie ungefragt erklärt, ist ein gutes Zeichen.