Open Source reduziert Vendor Lock-in. Warum Unternehmen trotzdem abhängig werden

Viele Unternehmen entscheiden sich für Open Source, um Vendor Lock-in zu vermeiden. In der Praxis entstehen Abhängigkeiten jedoch häufig nicht durch die Software selbst, sondern durch Geschäftslogik, Integrationen und Wissen, das über Jahre im System gewachsen ist.

Bei der Auswahl eines PIM-, ERP- oder E-Commerce-Systems fällt früher oder später fast immer ein Argument:

„Wir setzen auf Open Source. Dann sind wir unabhängig.“

Die Aussage ist nicht falsch.

Sie ist jedoch unvollständig.

Open Source kann bestimmte Formen der Herstellerabhängigkeit reduzieren. Trotzdem erleben viele Unternehmen Jahre später eine Situation, in der ein Systemwechsel praktisch unmöglich erscheint. Obwohl der Quellcode offen ist. Obwohl zahlreiche Dienstleister verfügbar wären. Obwohl theoretisch jederzeit jemand anderes übernehmen könnte.

Die entscheidende Frage lautet deshalb nicht:

Wem gehört der Quellcode?

Sondern:

Wo befindet sich das Wissen meines Unternehmens?

Open Source hat reale Vorteile

Zunächst sollte man fair bleiben.

Open Source bietet Unternehmen echte Vorteile:

Zugriff auf den Quellcode
größere Auswahl an Dienstleistern
geringere Abhängigkeit von einem einzelnen Hersteller
geringeres Risiko bei Herstellerinsolvenzen
Möglichkeit zur Eigenentwicklung
langfristige technische Verfügbarkeit

Diese Vorteile sind real und wichtig.

Deshalb werden Systeme wie Odoo, Akeneo, Pimcore oder andere Open-Source-Plattformen bewusst ausgewählt.

Das Problem beginnt erst dort, wo Open Source mit echter Unabhängigkeit gleichgesetzt wird.

Warum viele Projekte trotzdem abhängig werden

Kaum ein Unternehmen nutzt ein ERP- oder PIM-System dauerhaft im Auslieferungszustand.

Im Laufe der Jahre entstehen:

individuelle Importprozesse
Schnittstellen
Plugins
Workflows
Sonderlogiken
Middleware-Strecken
Validierungen
Berechnungen
Freigabeprozesse
Exporte

Jede einzelne Erweiterung löst zunächst ein konkretes Problem.

Nach einigen Jahren besteht das eigentliche System jedoch nur noch teilweise aus Standardsoftware. Ein erheblicher Teil der unternehmensspezifischen Logik steckt inzwischen in den Erweiterungen.

Die Software bleibt dieselbe.

Das Wissen verändert sich.

Das eigentliche Unternehmenswissen steckt nicht in den Daten

Viele Unternehmen betrachten ihre Daten als wichtigstes Asset:

Produkte
Kunden
Dokumente
Bilder
Stammdaten

Diese Informationen lassen sich meistens exportieren.

Wesentlich schwieriger wird die Migration von:

Preislogiken
Datenqualitätsregeln
Freigabeprozessen
Plausibilitätsprüfungen
Variantenlogiken
Importdefinitionen
Exportregeln
Automatisierungen
Geschäftsregeln
Prozesswissen

Genau dort steckt häufig das eigentliche Know-how eines Unternehmens.

Diese Regeln beantworten Fragen wie:

Wann darf ein Produkt veröffentlicht werden?
Welche Daten sind verpflichtend?
Welche Ausnahmen existieren?
Welche Berechnungen gelten?
Welche Sonderregelungen wurden in den letzten zehn Jahren aufgebaut?

Je erfolgreicher ein System genutzt wird, desto wertvoller werden diese Regeln.

Knowledge Lock-in: Die unterschätzte Form der Abhängigkeit

Wenn über Vendor Lock-in gesprochen wird, denken viele an:

Lizenzen
Verträge
SaaS-Abonnements
proprietäre Dateiformate

In der Praxis entsteht aber häufig eine andere Form der Abhängigkeit:

Knowledge Lock-in.

Knowledge Lock-in entsteht, wenn das Wissen über die Geschäftsprozesse eines Unternehmens nur noch in der technischen Implementierung existiert.

Zum Beispiel:

im Quellcode
in Plugins
in Skripten
in Middleware
in Workflows
in Datenbank-Prozeduren
in den Köpfen einzelner Entwickler

Die Regeln existieren weiterhin.

Niemand kann sie jedoch noch vollständig erklären.

Aus einem Softwareprojekt wird langsam ein Archäologieprojekt.

Der Mythos vom einfachen Partnerwechsel

Viele Anbieter argumentieren:

„Sie können jederzeit den Implementierungspartner wechseln.“

Auch das stimmt theoretisch.

Praktisch beginnt der neue Partner mit Fragen wie:

Welche Erweiterungen existieren?
Welche Regeln wurden umgesetzt?
Welche Integrationen sind kritisch?
Welche Sonderfälle wurden eingebaut?
Welche Workarounds wurden im Laufe der Jahre ergänzt?

Nicht selten folgt anschließend eine Aussage wie:

„Das sollten wir neu aufbauen.“

oder

„Die bisherige Lösung können wir nicht verantworten.“

oder

„Wir würden an dieser Stelle neu starten.“

Formal bleibt die Software dieselbe.

Praktisch entsteht ein neues Projekt.

Die technische Herstellerabhängigkeit wurde durch eine Wissensabhängigkeit ersetzt.

Wenn Updates zum Risiko werden

Open Source bedeutet nicht automatisch Update-Sicherheit.

Insbesondere umfangreiche individuelle Erweiterungen können Updates erheblich erschweren.

Typische Ursachen sind:

geänderte APIs
neue Framework-Versionen
inkompatible Erweiterungen
veraltete Plugins
weggefallene Erweiterungspunkte

Die Folge ist oft bekannt:

Updates werden verschoben
technische Schulden wachsen
Wartungskosten steigen
die nächste Migration wird immer schwieriger

Irgendwann befindet sich das Unternehmen in einer paradoxen Situation:

Das System ist offen.

Aber niemand traut sich mehr, es anzufassen.

Viele Partner ersetzen keine Transparenz

Ein großes Partnernetzwerk kann hilfreich sein.

Es ersetzt jedoch keine transparente Architektur.

Jeder neue Dienstleister muss verstehen:

das Datenmodell
die Prozesse
die Regeln
die Erweiterungen
die Historie

Je stärker dieses Wissen über verschiedene Komponenten verteilt ist, desto schwieriger wird die Übergabe.

Viele Partner bedeuten nicht automatisch geringe Abhängigkeit.

Oft bedeuten sie lediglich viele potenzielle Kandidaten, die zunächst dieselbe Lernkurve bewältigen müssen.

Die wahre Unabhängigkeit entsteht durch Architektur

Deshalb wird die Diskussion häufig an der falschen Stelle geführt.

Entscheidend ist weniger die Lizenzform als die Architektur des Systems.

Ein Unternehmen wird unabhängig durch:

dokumentierte Geschäftsprozesse
nachvollziehbare Geschäftsregeln
transparente Datenmodelle
verständliche Dokumentation
saubere Schnittstellen
geringe technische Kopplung
klare Verantwortlichkeiten

Ein schlecht dokumentiertes Open-Source-System kann deutlich mehr Abhängigkeiten erzeugen als ein sauber aufgebautes proprietäres System.

Umgekehrt kann auch ein proprietäres System problematisch werden, wenn Geschäftslogik und Prozesse verborgen bleiben.

Die entscheidende Frage

Bei der Bewertung eines Systems sollte deshalb nicht nur gefragt werden:

Können die Daten exportiert werden?

Sondern vor allem:

Kann das Wissen exportiert werden?

Ist die Geschäftslogik dokumentiert?
Ist sie nachvollziehbar?
Ist sie lesbar?
Ist sie wartbar?
Kann ein neuer Mitarbeiter sie verstehen?
Kann ein neuer Dienstleister sie übernehmen?

Oder ist dieses Wissen ausschließlich in individueller Implementierung und den Köpfen einzelner Beteiligter gespeichert?

Fazit

Open Source reduziert bestimmte Formen des Vendor Lock-ins.

Es beseitigt Abhängigkeiten jedoch nicht automatisch.

Die größte Abhängigkeit entsteht häufig dort, wo Unternehmenswissen ausschließlich in individueller Implementierung existiert:

im Quellcode,
in Plugins,
in Skripten,
in Middleware,
in Workflows,
oder in den Köpfen einzelner Personen.

Die wichtigste Frage bei der Systemauswahl lautet deshalb nicht:

Wem gehört die Software?

Sondern:

Wem gehört das Wissen?

Denn Daten lassen sich meist exportieren.

Geschäftslogik, Prozesse, Regeln und Automatisierungen sind dagegen oft das wertvollste Asset eines Unternehmens.

Nicht der Quellcode entscheidet über die langfristige Unabhängigkeit eines Unternehmens. Sondern die Frage, ob das eigene Wissen dokumentiert, nachvollziehbar und unabhängig von einzelnen Personen, Dienstleistern oder Implementierungen verfügbar bleibt.