Open Source im Mittelstand: Abhängigkeit statt Ablösung?

Open Source bedeutet, dass der Quellcode offenliegt und eine Lizenz Nutzung, Prüfung und Veränderung erlaubt. Offen heißt weder kostenlos noch wartungsfrei. Genau an dieser Stelle entscheidet sich in kleineren Betrieben, ob ein offenes Werkzeug trägt oder zu einer zweiten Baustelle wird. Die Frage lautet selten, ob ein Projekt technisch gut ist. Sie lautet, wer sich darum kümmert, wenn der ursprüngliche Autor keine Zeit mehr hat.

Der Vergleich in diesem Beitrag ist ein fiktives Beispiel. Er stellt ein selbst betriebenes Werkzeug einem kommerziellen Dienst gegenüber und kürt keinen Sieger, weil die Antwort an Daten, Personal und Ausstiegsmöglichkeiten hängt.

Wer pflegt das Projekt?

Eine Lizenz regelt, was ein Betrieb mit der Software tun darf. Die verbreiteten freizügigen Lizenzen wie MIT oder Apache-2.0 erlauben Weitergabe und Veränderung auch in eigenen Produkten. Copyleft-Lizenzen wie die GPL verlangen, dass abgeleitete Werke unter denselben Bedingungen weitergegeben werden. Wer Software nur intern einsetzt, hat mit beiden wenig Mühe. Wer sie in ein eigenes Produkt einbaut oder Kunden zugänglich macht, muss die Bedingungen prüfen, besonders bei der AGPL, die auch den Betrieb über ein Netzwerk erfasst.

Die Lizenz sagt aber nichts über die Pflege. Entscheidend ist, wer den Code tatsächlich weiterentwickelt. Vier Beobachtungen helfen bei der Beurteilung:

• Gibt es mehr als eine Person mit Schreibrechten, oder hängt das Projekt an einer einzelnen?

• Wie regelmäßig erscheinen Veröffentlichungen, und wie werden Sicherheitsmeldungen behandelt?

• Steht eine Firma, eine Stiftung oder eine Gruppe dahinter, die auch in zwei Jahren noch existiert?

• Werden Fehlerberichte beantwortet, oder sammeln sie sich ungelesen?

Ein Fork, also das Weiterführen einer Kopie durch Dritte, ist rechtlich fast immer möglich und praktisch teuer. Wer forkt, übernimmt die Pflege vollständig, ohne die Gemeinschaft, die das ursprüngliche Projekt getragen hat. Ein Fork ist ein Notausgang und kein Beschaffungsweg.

Für die Sicherheitsseite gilt: Ein offenes Projekt ist nicht unsicherer als ein geschlossenes, aber Schwachstellen sind öffentlich nachlesbar. Wer ein Werkzeug betreibt, braucht deshalb einen Weg, auf dem Meldungen ankommen und jemand sie liest. Wie ein solcher Grundschutz ohne eigene Sicherheitsabteilung aussieht, beschreibt der Leitfaden zum Basisschutz für Betriebe ohne Security-Team.

Was kostet ein kostenloses Werkzeug?

Die Lizenz kostet nichts. Der Betrieb kostet. Vier Positionen kehren in jedem Fall wieder: die Hardware oder der gemietete Server, die Arbeitszeit für Einrichtung und Aktualisierungen, die Prüfung nach jedem Versionssprung und die Zeit für Rückfragen der Beschäftigten. Wer diese Positionen nicht aufschreibt, vergleicht später ein vollständiges Angebot mit einer unvollständigen Eigenleistung.

Im fiktiven Beispiel eines Betriebs, in dem eine Person die IT nebenbei verantwortet, stehen zwei Wege zur Wahl: eine selbst betriebene Lösung auf einem eigenen Server oder ein gemieteter Dienst mit monatlichem Entgelt. Der Betrieb rechnet mit angenommenen Werten und kommt zu keinem eindeutigen Ergebnis. Der eigene Server verursacht kein Entgelt, bindet aber Arbeitszeit in jedem Monat und verlangt eine Vertretung für den Urlaubsfall. Der Dienst verursacht ein laufendes Entgelt und verlangt eine Prüfung, wohin die Daten fließen und was bei einer Kündigung mit ihnen geschieht.

Ein bezahlter Support-Vertrag ist der dritte Weg, der in kleineren Betrieben selten geprüft wird. Er verbindet offene Software mit einer benannten Ansprechstelle und Reaktionszeit. Ob sich das rechnet, hängt daran, wie oft eine Störung den Betrieb tatsächlich aufhält.

Auf der Kostenseite steht außerdem die Frage, wo das Werkzeug läuft. Ein Dienst in einer Cloud ist etwas anderes als ein Gerät im eigenen Netz. Was der Ort der Verarbeitung für Reaktionszeit, Ausfallverhalten und Betriebsaufwand bedeutet, ordnet der Beitrag über die Verarbeitung am Rand des Netzes statt in der Zentrale ein.

Wie sieht ein Exit-Plan aus?

Ein Exit-Plan ist keine Drohung an den Anbieter, sondern eine Vorbereitung. Er beantwortet drei Fragen: In welchem Format liegen die Daten, wer kann sie exportieren, und wie lange dauert ein Wechsel? Bei einem kommerziellen Dienst gehört diese Antwort in den Vertrag, bei einem selbst betriebenen Werkzeug in die Dokumentation.

Ein Export, der nie getestet wurde, ist kein Export. Ein Betrieb sollte einmal im Jahr mit einer Kopie der Daten eine Wiederherstellung in einer Testumgebung versuchen. Wer das nicht tut, erfährt erst im Streitfall, dass ein Format unvollständig ist oder Anhänge fehlen.

Für die Beschaffung hilft eine kurze Prüfliste, die vor der Entscheidung ausgefüllt wird und nicht danach:

• Zweck und Datenarten, die das Werkzeug verarbeiten soll.

• Lizenz und Bedingungen für eine Weitergabe, falls die Software in ein Produkt einfließt.

• Wer die Pflege übernimmt, mit Namen und Stellvertretung.

• Wie Sicherheitsmeldungen ankommen und wer sie innerhalb welcher Frist liest.

• Ausstieg: Datenformat, Exportweg, Frist und Kosten eines Wechsels.

• Abbruchkriterium, falls das Werkzeug den Zweck nicht erfüllt.

Wer ein neues Werkzeug einführt, sollte nicht mit der vollständigen Ablösung beginnen. Wie ein begrenzter Versuch aufgesetzt wird, ohne die Organisation zu binden, steht im Beitrag über den Pilot, der klein bleiben darf. Und wenn ein Werkzeug Teil einer Lieferkette wird, kommen Anforderungen der Auftraggeber hinzu. Welche Sicherheitsvorgaben über Verträge weitergegeben werden und wann eine eigene Pflicht greift, trennt der Beitrag dazu, wann NIS2 einen kleineren Betrieb erfasst.

Die Auswahl selbst braucht keine Produktversprechen, sondern Kriterien. Wie eine solche Auswahl ohne Rangliste der Anbieter aussieht, zeigt die Auswahlhilfe zum Passwortmanager für ein Team.

Welche Abhängigkeit bleibt

Open Source löst Abhängigkeit nicht ab. Sie verschiebt sie. Aus der Abhängigkeit von einem Vertragspartner wird eine Abhängigkeit von einem Projekt, von seinen Beitragenden und von der eigenen Fähigkeit, das Werkzeug zu betreiben. Diese Verschiebung kann ein Vorteil sein, weil der Quellcode prüfbar bleibt und ein Wechsel ohne Zustimmung Dritter möglich ist. Sie kann ein Nachteil sein, wenn im Betrieb niemand die Aktualisierungen liest.

Die offene Grenze liegt in der Zukunft. Ob ein Projekt in fünf Jahren noch gepflegt wird, lässt sich bei der Beschaffung nicht zusichern, weder bei offener noch bei gekaufter Software. Prüfbar ist nur, wie ein Betrieb darauf reagieren könnte. Deshalb ist der Exit-Plan das einzige Versprechen, das ein Betrieb sich selbst geben kann.