
Digitale Souveränität ist in den Chefetagen des Mittelstands angekommen. Plötzlich ist das, was lange als IT-Infrastruktur-Thema galt, eine strategische Frage: Wem gehören eigentlich die Daten, der Code und die Schnittstellen, auf denen mein Umsatz läuft? Wer entscheidet über Roadmaps, Preisstrukturen und Auslistungen? Die Antwort darauf bestimmt, wie selbstbestimmt ein Unternehmen in zehn Jahren noch agieren kann.
Open-Source-Shopsysteme wirken auf den ersten Blick wie das passende Gegengift zur Konsolidierungswelle der SaaS-Anbieter. Im Hintergrund jeder Plattformdiskussion läuft eine grundsätzlichere Frage mit: Abhängigkeit gegen Selbstbestimmung. Diese Frage ist nicht neu, sie war im Maschinenbau bei der Wahl zwischen Eigenfertigung und Zulieferung über Jahrzehnte präsent. Im E-Commerce stellt sich dieselbe Logik jetzt mit voller Wucht.
Die Debatte polarisiert, weil sie nicht nur technisch ist. Sie rührt an Grundsätzen der Unternehmensführung. Wer als Geschäftsführer auf eine SaaS-Plattform setzt, kauft Geschwindigkeit. Wer auf Open Source setzt, kauft Kontrolle. Beides hat einen Preis, beides hat seinen legitimen Platz. Falsch wird es erst, wenn man die eine Entscheidung als ideologisch überlegen verkauft, ohne die strukturellen Konsequenzen ehrlich zu benennen.
Hinzu kommt ein Faktor, der die Diskussion gerade neu sortiert: KI senkt die Hürde, eigene Software zu entwickeln. Code entsteht schneller, individuelle Module wirken plötzlich erschwinglich. Wer daraus aber ableitet, dass Open Source jetzt für jeden funktioniert, übersieht den entscheidenden Punkt. Das Schreiben ist günstig geworden, das Betreiben nicht. Eine fundierte Shopsystem-Auswahl gehört deshalb nicht ans Ende, sondern an den Anfang jeder Plattformstrategie.
Open Source ist die Antithese zum geschlossenen Ökosystem. Sie kaufen keine Software, Sie übernehmen sie. Mit allen Rechten, Pflichten und Konsequenzen.
Der größte strategische Vorteil ist die Eigentümerschaft am Code. Niemand kann Ihnen Funktionen wegnehmen, Preise diktieren oder Sie zwingen, ein veraltetes System weiterzubetreiben, weil die Migration zu teuer wäre. Im State of Enterprise Open Source-Report von Red Hat gaben 82 Prozent der IT-Entscheider an, dass sie bevorzugt auf Anbieter setzen, die Open Source nutzen oder unterstützen, gerade weil dies Vendor Lock-in reduziert. Dieser Befund ist keine Stimmung, sondern eine konsistente Linie über mehrere Erhebungsjahre.
Flexibilität ist der zweite große Hebel. Sobald Ihr Geschäftsmodell vom Standard abweicht, etwa durch komplexe B2B-Preislogiken, tiefe ERP-Integrationen, projektbezogene Angebote oder regulierte Branchenanforderungen, wird Anpassbarkeit zur Währung. SaaS zwingt Sie in einen vordefinierten Korridor, Open Source lässt Sie den Korridor selbst bauen. Das ist mächtig, aber eben auch aufwendig.
Dazu kommt der geschäftskritische Aspekt der Datenhoheit. Bei Open Source liegen Datenbank, Logs, Tracking und Bestellhistorie auf Ihrer Infrastruktur. Sie können sie auswerten, exportieren, archivieren und mit anderen Systemen verheiraten, ohne einen Anbieter um Erlaubnis zu fragen. Diese vollständige Kontrolle über die eigene Datenbasis ist im B2B-Vertrieb oft der entscheidende Punkt, weil Kundendaten dort ein strategisches Asset sind und kein technisches Beiwerk.
KI verändert dieses Bild zusätzlich. Custom-Module entstehen schneller als je zuvor, Code-Generierung ersetzt Routine-Arbeit, technische Spezifikationen lassen sich teilweise automatisiert ableiten. Was sich aber nicht ändert, sind die strukturellen Folgekosten: Reviews, Sicherheitsaudits, Performance-Tuning, Release-Management. Ein KI-generiertes Modul ist immer noch ein Modul mit allen langfristigen Pflichten. Wer KI als Hauptargument für Open Source nutzt, sollte ehrlich rechnen.Die Erfahrung aus der E-Commerce-Beratung zeigt hier ein klares Muster: Ohne eine realistische Kalkulation entstehen sehr schnell technische Schulden mit einer Pseudo-Einsparung.
Souveränität klingt nach Freiheit. In der Bilanz steht aber Verantwortung. Wer den Code besitzt, betreibt auch das Risiko.
Ein eigenes System bedeutet, dass jeder Patch, jedes DSGVO-Update und jede Sicherheitslücke Ihr Problem ist. Sie brauchen Monitoring, ein Incident-Response-Konzept und Dokumentation, die einem Audit standhält. Bei einem SaaS-Anbieter passiert das im Hintergrund, bei Open Source wird es Chefsache. Das ist kein Argument gegen Open Source, sondern eine klare Anforderung an die Organisation.
die Komplexität künftiger Releases. Ein Major-Update wird schnell zum Projekt mit sechsstelligem Budget, weil hundert kleine Customizations einzeln nachgezogen werden müssen. Diese Aufwände tauchen in keinem ersten Angebot auf, sie schlagen im Jahr drei oder vier auf. Wer den Lebenszyklus seiner Plattform nicht über mindestens fünf Jahre durchrechnet, vergleicht beim Pitch die falsche Zahl.
Performance, Skalierbarkeit und Disaster Recovery kommen on top. Open Source bedeutet, dass Sie sich um Lasttests vor dem Black-Friday-Wochenende kümmern, um Failover-Szenarien bei Stromausfall im Rechenzentrum, um Backup-Strategien für den Fall, dass ein Mitarbeiter aus Versehen die Produktivdatenbank überschreibt. Bei SaaS sind das SLAs des Anbieters, bei Open Source ist es Ihr Geschäftsrisiko. Diese Verantwortung lässt sich nicht delegieren, sie lässt sich höchstens an externe Spezialisten outsourcen, was die Abhängigkeitsfrage nur verschiebt.
Bevor die Diskussion in eine reflexhafte Pro-SaaS-Richtung kippt, lohnt der ehrliche Blick auf die Gegenseite. Wer auf Shopify, BigCommerce, Salesforce Commerce Cloud oder Adobe Commerce Cloud setzt, trifft eine genauso folgenreiche Entscheidung, nur in die andere Richtung. Sie geben Komplexität ab, dafür geben Sie auch Hoheit ab.
Der erste Reibungspunkt sind die Preise. SaaS-Anbieter können ihre Tarife einseitig anpassen, und sie tun es regelmäßig. Shopify hat in den vergangenen Jahren mehrfach an der Preisschraube gedreht, sowohl bei den Plan-Preisen als auch bei Transaktionsgebühren, sobald nicht der eigene Payment-Provider genutzt wird. Adobe hat die Lizenzmodelle von Magento Commerce Cloud wiederholt umgestellt, Salesforce kennt jeder, der schon einmal eine Vertragsverlängerung verhandelt hat. Die Logik dahinter ist einfach: Je tiefer Sie integriert sind, desto schmerzhafter wird ein Anbieterwechsel, desto höher die Preise, die Sie zähneknirschend akzeptieren. Diese Mechanik ist nicht böse gemeint, sie ist betriebswirtschaftlich rational aus Sicht des Anbieters und genau deshalb gefährlich für den Kunden.
Der zweite Punkt sind die Daten. In einem SaaS-System gehören die Geschäftsdaten dem Kunden, aber das Schema, die Analytics-Logik und die Auswertungsmöglichkeiten gehören dem Anbieter. Wer eine spezifische Frage an die eigenen Verkaufsdaten stellen will, ist auf die Reports angewiesen, die das System mitliefert. Tiefergehende Analysen erfordern oft kostenpflichtige Add-ons oder externe Tools, die per API angebunden werden müssen. API-Limits sind dabei nicht selten. Wer Bestelldaten in Echtzeit ins eigene Data Warehouse spielen will, stößt regelmäßig an Rate-Limits oder muss in höhere Tarifstufen wechseln, die genau diese Schnittstellenkapazität freischalten.
Der dritte Punkt ist die App-Ökonomie. SaaS-Plattformen leben von ihren App-Stores. Jede Funktion, die nicht im Standard ist, kommt als Monatsmiete eines Drittanbieters dazu. Versandlogik, Bewertungssystem, Abo-Modelle, B2B-Funktionen, Multi-Shop-Setup: Bei Shopify und Co. sind das selten Bordmittel, sondern Apps, die zwischen 20 und mehrere hundert Euro pro Monat kosten. Ein durchschnittlich ausgestatteter Mittelstands-Shop verteilt seine eigentlichen Funktionskosten auf 15 bis 30 monatliche Abos, deren Preise unabhängig voneinander angehoben werden können. Der vermeintlich günstige Plan-Preis ist dann längst zur Nebensache geworden.
Der vierte Punkt betrifft die Migration. Ein SaaS-System verlassen Sie nicht im Vorbeigehen. Bestelldaten lassen sich meistens exportieren, Kundendaten ebenfalls, Produkte mit Aufwand. Schwierig wird es bei allem, was in proprietären Strukturen liegt: Workflow-Automatisierungen, App-Konfigurationen, individuelle Templates, native Marketing-Logiken. Wer von Shopify zu Shopware oder umgekehrt wechseln will, muss damit rechnen, dass ein Drittel bis die Hälfte der Plattform faktisch neu gebaut wird. Das ist gewollt. Lock-in ist im SaaS-Geschäftsmodell kein Bug, sondern Feature.

Diese vier Mechanismen wirken zusammen. Sie schaffen eine schleichende Abhängigkeit, die sich erst dann zeigt, wenn man austreten will. Genau das ist der Punkt, an dem die Selbstbestimmung verloren geht. Open Source hat dagegen genau den umgekehrten Effekt: Sie investieren früh in Eigenleistung und sind ab einem bestimmten Punkt im Wesentlichen frei. SaaS investiert wenig am Anfang und kassiert über die Vertragslaufzeit. Welches Modell günstiger ist, hängt davon ab, wie lange Sie planen, wie sehr Sie wachsen und wie individuell Ihr Geschäftsmodell ist. Eine ehrliche Bewertung des passenden Setups muss diese Mechanismen offenlegen.
Hier liegt der eigentliche Knackpunkt der Debatte. Open Source scheitert selten an der Technik, sondern an den Menschen, die fehlen.
Ein stabiler Eigenbetrieb braucht mehr als einen Entwickler. Sie benötigen ein eingespieltes Team, das mindestens folgende Rollen abdeckt:
Diese Rollen sind nicht in einer Person abbildbar. Wer das versucht, baut einen Single Point of Failure mit drei Monaten Kündigungsfrist. Der Arbeitsmarkt hat sich gegenüber den Spitzenjahren etwas entspannt. Laut Bitkom-Studie 2025 fehlen in Deutschland aktuell rund 109.000 IT-Fachkräfte, gegenüber dem Höchststand von 149.000 im Jahr 2023. Die nominale Entspannung täuscht aber. 85 Prozent der Unternehmen beklagen weiterhin einen Mangel, 79 Prozent erwarten eine erneute Verschärfung. Hinzu kommt eine Verschiebung der Profile: KI ersetzt Junior-Tätigkeiten, gefragt sind Senior-Profile mit Plattform-Tiefe, Architektur-Verständnis und Security-Erfahrung. Genau diese sind teuer und kaum verfügbar.
Die naheliegende Alternative ist die Auslagerung an eine spezialisierte Agentur. Das funktioniert technisch, schafft aber eine neue Abhängigkeit. Ihre Plattform wird so stabil wie die Liefertreue, Kapazität und Preispolitik dieses Dienstleisters. Fällt der Partner aus, übernimmt der nächste, der erst einmal sechs Monate braucht, um sich einzuarbeiten. Souveränität gegenüber einem Software-Anbieter eingetauscht gegen Abhängigkeit von einer Agentur ist kein Gewinn, sondern ein Verschieben der Abhängigkeit. Wer Open Source sauber betreiben will, braucht beides: ein Inhouse-Kernteam und gezielte externe Verstärkung. Das ist machbar, kostet aber strukturell mehr, als die meisten KMU einplanen.
SaaS wird oft als ideologische Bequemlichkeit abgetan. Das wird der Realität nicht gerecht. Für viele Unternehmen ist es die rationale Antwort auf eine begrenzte Ressourcenlage.
Standardisierung ist dabei das eigentliche Geschenk. Ein SaaS-System nimmt Ihnen die Diskussion ab, ob Sie Komponente A oder B nutzen, wie Sie hosten und wie Sie patchen. Der Anbieter liefert Updates, skaliert die Infrastruktur und übernimmt die Compliance-Basisarbeit. Das ist kein Verlust an Wertschöpfung, sondern Konzentration auf das, was differenziert. Sortiment, Kundenbeziehung, Marketing, Service. Eine Studie des KfW-Mittelstandspanels zeigt, dass nur etwa 19 Prozent der kleinen und mittleren Unternehmen in Deutschland überhaupt eigene IT-Spezialisten beschäftigen. Für den Großteil ist SaaS keine Komfort-, sondern eine Realitätsentscheidung.
Der Effekt zeigt sich besonders in kleineren D2C-Setups und in B2B-Einstiegen. Sie kommen in sechs bis zwölf Wochen live, statt zwölf bis achtzehn Monate zu investieren. Das schafft Lernzyklen, Cashflow und Marktfeedback, lange bevor ein Open-Source-Projekt überhaupt seinen ersten Bestellabschluss verarbeitet. Wer früh validieren muss, fährt mit SaaS klüger. Bei Bedarf kann später auf eine eigene Plattform migriert werden, dann allerdings mit echtem Geschäftsmodell und nicht mit einer Hypothese.
Der Preis dieser Pragmatik ist genau das, was im vorherigen Abschnitt beschrieben wurde: Preisrisiko, Lock-in und reduzierte Datenhoheit. Das ist kein Widerspruch, sondern ein bewusster Tausch. Wer diesen Tausch eingeht, sollte ihn aber bewusst eingehen. Vertraglich heißt das: Verhandeln Sie Preisgleitklauseln, Exit-Szenarien und Datenexportrechte aktiv. Strukturell heißt es: Halten Sie Ihre Datenmodelle so anbieterneutral wie möglich, indem Sie Kundendaten parallel in einem eigenen CRM oder CDP führen, statt sie ausschließlich im SaaS-System leben zu lassen. Das ist die kleine Souveränität, die sich auch in der SaaS-Welt erhalten lässt.
Die Entscheidung ist weniger eine Frage der Technologie als eine Frage der Konstellation. Drei Dimensionen sind dafür entscheidend.
Erstens die Unternehmensgröße und das IT-Budget. Ohne ein internes Team von mindestens fünf bis acht IT-Profilen lässt sich ein Open-Source-Shop kaum stabil betreiben. Zweitens die strategische Relevanz des E-Commerce-Kanals. Ist der Onlineshop das Kerngeschäft oder ein ergänzender Vertriebsweg? Drittens die Komplexität des Geschäftsmodells, etwa B2B-Preisstaffeln, internationale Logiken oder regulatorische Anforderungen.
Als Orientierung helfen folgende Konstellationen:

Daneben braucht jede Entscheidung eine saubere TCO-Betrachtung. Lizenzkosten sind dabei nicht der Treiber. Entscheidend sind Personalkosten, Update-Zyklen, Hosting, Sicherheit, Apps, Transaktionsgebühren und das Customizing-Risiko über fünf Jahre. Wer nur den ersten Implementierungspreis vergleicht, vergleicht die falsche Zahl. Eine belastbare TCO-Analyse deckt Effekte auf, die im Sales-Pitch jedes Anbieters systematisch unterschlagen werden, von der schleichenden Preiserhöhung bis zur App-Inflation.
Ein zweiter Aspekt der Matrix ist die Zeitachse. SaaS belohnt kurze bis mittlere Horizonte, Open Source belohnt lange. Wer in den nächsten zwei Jahren validieren will, ist mit SaaS schneller im Markt. Wer in zehn Jahren noch unabhängig agieren möchte, profitiert von der Investition in eigene Strukturen. Die Frage ist nicht, was heute günstiger ist, sondern was Sie in fünf oder sieben Jahren noch handlungsfähig hält. Genau diese Perspektive fehlt in den meisten internen Diskussionen, weil sie unbequem ist.
Open Source ist kein Selbstzweck, SaaS ist keine Kapitulation. Beide Modelle haben ihre Berechtigung, beide haben harte Voraussetzungen. Die ehrliche Frage lautet nicht, was technisch das beste System ist, sondern was zu Ihrer Organisation, Ihrem Geschäftsmodell und Ihrem realistischen Ressourcenrahmen passt.
Im Kern bleibt es eine Frage von Abhängigkeit und Selbstbestimmung. Open Source verlangt Investitionen in Personal, Prozesse und Know-how, gibt dafür aber Kontrolle über Code, Daten und Roadmap. SaaS schenkt Geschwindigkeit und Stabilität, kassiert dafür langfristig in Form von Preiserhöhungen, App-Kosten, Transaktionsgebühren und einem Lock-in, der mit jedem Monat tiefer wird. Beide Modelle haben einen Preis. Der Unterschied liegt darin, ob Sie ihn vorne oder hinten bezahlen, und ob Sie ihn beeinflussen können.
Vier Punkte sollten Sie aus dieser Diskussion mitnehmen. Erstens: Digitale Souveränität ist eine berechtigte Anforderung, aber sie hat einen Preis, der nicht in der Lizenz steht, sondern im Organigramm. Zweitens: KI senkt Entwicklungskosten, aber nicht Betriebskosten. Wer Open Source darüber legitimiert, rechnet zu kurz. Drittens: SaaS ist für die Mehrheit der KMU keine zweite Wahl, sondern die strategisch saubere Antwort auf begrenzte interne IT-Kapazitäten. Viertens: SaaS ist nicht risikofrei. Preisrisiken, Datenhoheit und Lock-in gehören aktiv in jede Vertragsverhandlung, sonst zahlen Sie die Selbstbestimmung in Raten zurück.
Die Handlungsempfehlung ist klar. Treffen Sie die Entscheidung bewusst und nicht aus Reflex. Bewerten Sie Ihre IT-Ressourcen ehrlich, rechnen Sie die TCO über fünf Jahre, prüfen Sie Ihre Verhandlungsposition gegenüber dem Anbieter und stellen Sie sich die unangenehme Frage, was passiert, wenn die Preise um 30 Prozent steigen oder der Anbieter eine strategische Schwenkung vollzieht. In den meisten mittelständischen Konstellationen ist die Antwort weniger ideologisch, als die Debatte vermuten lässt.