Haltung
Der Grund für offene Technologien ist kein weltanschaulicher. Es geht darum, über die Lebensdauer eines Systems handlungsfähig zu bleiben – prüfen, ändern, betreiben und im Ernstfall wechseln zu können.
Das Argument
Softwareentscheidungen werden meist über Funktionsumfang und Preis geführt. Beides ist über einen Zeitraum von fünf bis zehn Jahren die weniger interessante Größe. Was zählt, ist die Frage, was passiert, wenn sich etwas ändert: Der Anbieter erhöht die Preise. Ein Produkt wird eingestellt. Eine Funktion, die Sie brauchen, kommt nicht auf die Roadmap. Eine Schwachstelle wird gemeldet, und Sie brauchen einen Patch für eine Version, die offiziell nicht mehr unterstützt wird.
In all diesen Fällen entscheidet nicht die Lizenz, sondern der Zugang zum Quellcode und zu den Daten darüber, welche Optionen Ihnen bleiben. Mit offenem Code können Sie selbst patchen, jemanden dafür bezahlen, den Betrieb übernehmen oder migrieren – und Sie können vorher ausrechnen, was das kostet. Ohne ihn ist die Antwort auf jede dieser Fragen: verhandeln oder abwarten.
Das ist kein Argument gegen kommerzielle Software. Es ist ein Argument dafür, den Preis einer Bindung zu kennen, bevor man sie eingeht. Manchmal ist dieser Preis angemessen. Häufig ist er nur nie beziffert worden. Wir behandeln das als Teil einer Technologieentscheidung, nicht als Nebenaspekt.
Grundsätze
06 Punkte
01
Offener Quellcode lässt sich lesen, prüfen und im Fehlerfall bis zur Ursache verfolgen. Bei geschlossener Software endet die Analyse an der Schnittstelle – und damit an der Grenze der eigenen Handlungsfähigkeit.
02
Offene Standards und dokumentierte Formate machen Systeme kombinierbar. Daten bleiben lesbar, auch wenn eine Komponente ersetzt wird.
03
Wer den Quellcode besitzt, behält die Wahl: selbst betreiben, extern betreiben lassen oder den Anbieter wechseln. Diese Wahl ist der eigentliche Wert.
04
Etablierte offene Projekte haben lange Release-Zyklen, dokumentierte Sicherheitsupdates und eine öffentliche Historie. Das ist eine bessere Planungsgrundlage als eine Roadmap, auf die man keinen Einfluss hat.
05
Bindung ist nicht grundsätzlich falsch – sie muss bewusst und begründet sein. Vermeidbarer Lock-in entsteht dort, wo eine offene Alternative dieselbe Aufgabe erfüllt.
06
Wo möglich fließen Korrekturen zurück in das ursprüngliche Projekt. Das senkt den eigenen Wartungsaufwand und hält künftige Upgrades einfach.
Grenzen
Ein Beratungsangebot, das die eigene Position nie einschränkt, ist keine Beratung. Es gibt Fälle, in denen wir von offener Software abraten.
Nischenfachlichkeit ohne Community. Wenn ein Fachbereich von zwei proprietären Produkten abgedeckt wird und das offene Gegenstück einen einzelnen Maintainer hat, kaufen Sie mit dem Produkt vor allem Kontinuität ein. Das kann die richtige Entscheidung sein.
Regulatorische Zertifizierungspflicht. Wo eine Zulassung an ein zertifiziertes Produkt gebunden ist, hilft der beste offene Ersatz nicht, solange die Zertifizierung fehlt.
Fehlende interne Kapazität. Offene Software verschiebt Kosten von der Lizenz in den Betrieb. Wenn niemand diesen Betrieb übernehmen kann und auch kein Budget für einen Dienstleister vorhanden ist, entsteht ein System, das niemand pflegt – das ist schlechter als ein Wartungsvertrag.
Die ausführliche Abwägung steht in Open Source vs. proprietäre Software.
Fragen
Nicht automatisch. Die Lizenzkosten entfallen, die Betriebsverantwortung nicht. Was wegfällt, sind Nutzerstaffeln, Audit-Klauseln und Preiserhöhungen bei Vertragsverlängerung. Was hinzukommt, ist eigener Aufwand für Betrieb, Updates und Integration – oder ein Dienstleister, der ihn übernimmt. Der ehrliche Vergleich ist Total Cost of Ownership über fünf Jahre, nicht Lizenzpreis gegen Null.
Die Lizenz selbst schließt Haftung praktisch immer aus – das gilt für MIT, Apache-2.0 und GPL gleichermaßen. Haftung entsteht über einen Vertrag mit dem Dienstleister, der die Software für Sie betreibt oder anpasst, nicht über die Lizenz. Bei proprietärer Software ist es strukturell dasselbe, nur dass Lizenz und Supportvertrag beim selben Anbieter liegen.
Das hängt von der Lizenz und der Art der Nutzung ab. Permissive Lizenzen wie MIT und Apache-2.0 verlangen das nicht. Starkes Copyleft wie die GPL greift bei Weitergabe eines abgeleiteten Werks; die AGPL erweitert das auf den Netzwerkzugriff. Reine interne Nutzung ohne Weitergabe löst bei der GPL keine Offenlegungspflicht aus. Die Prüfung gehört vor die Architekturentscheidung, nicht in das Kundenaudit.
An überprüfbaren Signalen, nicht an Sternen auf GitHub: Zahl aktiver Committer über die letzten zwölf Monate, Release-Kadenz und ob Sicherheitsreleases separat erscheinen, ein dokumentierter Meldeweg für Schwachstellen, ein Governance-Modell, das nicht von einer Person abhängt, und ob eine Stiftung oder mehrere Firmen die Entwicklung tragen. Ein Projekt mit einem einzigen Maintainer ist kein Ausschlussgrund – aber ein Risiko, das man kennen und einplanen muss.
Eine Open-Source-Strategie regelt verbindlich, welche Fremdkomponenten hereinkommen, was veröffentlicht wird und wer entscheidet. Aufbau, Rollen, Einführung.
Was offene Software wirtschaftlich bringt, welche Kosten sie nur verschiebt statt streicht und wann proprietär die bessere Wahl bleibt.
Quellcode, Kostenverlauf, Support, Exit-Kosten: ein sachlicher Entscheidungsrahmen für die Wahl zwischen Open Source, proprietärer Software und Mischformen.
Kontakt
Beschreiben Sie kurz Ihr System und die offene Frage. Wir antworten mit einer fachlichen Einschätzung – ohne Vertriebsschleife.