Stell dir den Morgen in einem modernen Open-Source-Team 2026 vor. Im Repository des Shopware-6-Hauptshops liegen siebzehn Pull Requests, die über Nacht entstanden sind: drei Dependency-Bumps, ein CVE-Patch in einer Symfony-Library, ein paar kleine Refactors, ein Update der API-Client-Bibliothek auf eine neue Major-Version inklusive der zwei Anpassungen, die es braucht, damit die Tests grün bleiben. Geschrieben hat das alles ein Coding-Agent. Ein Entwickler braucht den Vormittag, um zu reviewen und zu mergen. Damit ist die Wartung für diesen Tag erledigt.
Genau in dieser einen Nacht stirbt das wichtigste Argument der letzten zwanzig Jahre gegen Open Source. Niemand merkt es, weil es leise passiert. Aber jede Make-or-Buy-Entscheidung, die noch auf der alten Wartungs-Rechnung beruht, ist seit der breiten Verfügbarkeit produktionsreifer Coding-Agenten (ab Mitte 2025) auf einer Folie unterwegs, die nicht mehr stimmt.
Dieser Post ist die Top-Down-Sicht auf das Pattern dahinter: Was die KI-Revolution mit deiner Wartungsrechnung macht, warum „Vendor Lock-in“ damit vom abstrakten Risiko zum konkreten finanziellen Schaden zurückkehrt, und wie ein Open-Source-Fundament unter deinen Kernsystemen heute ausschaut, wenn man es ernst meint.
Wie die alte Rechnung wirklich aussah, und warum sie funktioniert hat
Wer in den 2010ern eine ERP-, CRM- oder Shop-Entscheidung zu treffen hatte, bekam von jedem Anbieter dieselbe Folie zu sehen. Lizenzkosten sind sichtbar, Personalkosten sind versteckt. Eine Closed-Source-Lösung kostet als illustrative Hausnummer 250.000 Euro im Jahr für Lizenz und Support. Ein vergleichbarer Open-Source-Stack kostet null Euro Lizenz, aber du brauchst zwei bis vier Entwickler, die ihn pflegen, plus eine Agentur als Backup. Rechnest du fair, landest du bei ähnlichen Gesamtkosten, mit weniger Komfort.
Das war keine Anbieter-Propaganda, das war ehrlich beobachtbar. Wer einen Magento-1-Shop in den Jahren vor dem M2-Replatforming betrieb, kannte den Schmerz: Sicherheits-Patches alle paar Wochen, Major-Upgrades, die ein halbes Jahr Engineering binden, jede dritte Extension bricht beim Update. Dieselbe Geschichte galt für selbstgehostete CRMs, für Eigenentwicklungen auf Java-Stack, für interne Datenpipelines. Open Source war frei und es kostete dich konstant Menschen.
Genau in diesem Spalt zwischen planbarer Lizenz und unplanbarer Pflege haben die großen SaaS-Hersteller ihre Marktanteile gebaut: Salesforce, Shopify, ServiceNow, HubSpot. Du zahlst monatlich, du musst nichts patchen, du musst niemanden einstellen, der den Stack kennt. Das war ein echtes Versprechen, und es wurde überwiegend gehalten.
Was sich 2025/26 fundamental verändert hat
Der Bruch kam leise. Während die Schlagzeilen sich auf Bild-, Sprach- und Chat-Modelle stürzten, haben Coding-Agenten (Claude Code, Cursor, GitHub Copilot Coding Agent und Open-Source-Werkzeuge wie Aider und OpenHands) einen anderen Job übernommen: die laufende Pflege existierender Codebasen. Genau die Arbeit, die in der alten Rechnung der teure Posten war.
Was ein Coding-Agent heute mit menschlicher Aufsicht im Pull-Request-Loop zuverlässig erledigt: Sie liest einen Security-Advisory, erkennt die betroffene Library im package.json oder composer.json, hebt die Version, passt die zwei Stellen im Code an, an denen sich das Interface geändert hat, und öffnet einen Pull Request mit grünen Tests. Sie reagiert auf einen Fehler im Sentry-Log, isoliert den Stack-Trace, schreibt einen Reproduktionstest und einen Fix dazu. Sie nimmt einen Refactor-Auftrag entgegen, der drei Tage manuelle Arbeit gewesen wäre, und liefert in zwanzig Minuten einen Diff, den ein Mensch nur noch reviewen muss.
Kurz gesagt: Der Coding-Agent ist nicht der Senior-Entwickler, der die Architektur entwirft. Er ist der Junior-Entwickler, der die unliebsamen, repetitiven Wartungs-Tickets abarbeitet, und genau diese Tickets waren das eigentliche Argument gegen Open Source.
Das Vorher-Nachher-Bild eines typischen mittelständischen Stacks: Vorher landeten Dependabot-Alerts im Backlog, der einmal pro Quartal in einem Sprint abgearbeitet wurde, sofern dringende Features das zuließen. CVE-Patches kamen mit Verzögerung. Die Test-Coverage erodierte unter Liefer-Druck. Nachher läuft Wartung als kontinuierlicher Pull-Request-Strom durch, CVE-Patches sind oft innerhalb von Stunden im Branch, und die Test-Coverage lässt sich nachträglich mit überschaubarem Aufwand auf ein vernünftiges Niveau heben. Was 2022 noch teuer war, ist 2026 überwiegend Routine.
Die neue Rechnung, grob aber ehrlich
Konkretisieren wir das als Modellrechnung. Nimm einen mittelständischen Shopware-6-Shop mit einer Handvoll Custom-Plugins, angeflanscht an ein ERP via REST. Vor zwei Jahren hätte dieser Stack realistisch 0,5 bis 1 FTE Engineering an reiner Wartung gebunden, plus eine Agentur, die du für Major-Upgrades und Notfälle in Bereitschaft hältst. Auf DACH-Senior-Lohnniveau plus Overhead landet das bei 80.000 bis 140.000 Euro pro Jahr, je nach Senioritätsmix. Das ist keine empirische Marktzahl, das ist die Größenordnung, die sich aus Lohnindex und realistischem Wartungsbudget ableiten lässt.
Mit einem konsequent eingerichteten Wartungs-Loop (sauberes Test-Setup, CI/CD-Pipeline, ein Coding-Agent, der nachts Dependency- und Security-PRs aufmacht, ein klarer Review-Prozess) ist ein Drittel bis die Hälfte dieses Aufwands ein realistischer Erwartungs-Korridor. Stark abhängig von Testabdeckung und Modellqualität, aber kein Wunsch-Denken. Das Geld geht nicht weg, es verschiebt sich. Statt für 0,8 FTE Wartung zahlst du für 0,3 FTE Wartung plus ein paar hundert Euro im Monat an Tool- und Modell-Kosten.
Vergleich das mit dem proprietären Pendant. Eine Enterprise-Shop-Suite oder eine SaaS-Plattform der Salesforce-Klasse kostet im Mittelstand für vergleichbares Volumen je nach Edition und Umsatz im mittleren bis hohen fünf- bis sechsstelligen Eurobereich pro Jahr, oft als prozentualer Anteil am Umsatz (siehe dazu unsere Detail-Analyse Shopware vs. Salesforce Commerce Cloud). Diese Linie ist garantiert nicht schrumpfend. Wer sein eigenes Wachstum als Bemessungsgrundlage abgetreten hat, zahlt jedes erfolgreiche Jahr doppelt.
Das ist die neue Rechnung in einem Satz: Die Lizenzlinie der proprietären Welt ist konstant teuer geblieben. Die Wartungslinie der Open-Source-Welt ist halbiert worden. Die Schere schließt sich nicht. Sie öffnet sich, in die andere Richtung.
Vendor Lock-in ist das eigentliche Risiko, das die alte Rechnung verdrängt hat
Solange die Wartungs-Frage so dominant war, hat sie die zweite, leisere Frage übertönt: Was passiert eigentlich, wenn dein Anbieter sich verändert, und du nicht mitkommen willst? Preise erhöht, Features abkündigt, ein API-Kontingent halbiert, ein Modul ins teurere Bundle verschiebt, einen Konkurrenten kauft, dem strategischen Investor zuliebe einen Pivot fährt. Diese Frage hatte zwei Jahrzehnte lang den Status eines theoretischen Risikos. Jeder kannte ein abschreckendes Beispiel, aber „uns passiert das schon nicht“.
Es passiert konstant. Wir haben es für den Plattform-Spezialfall an anderer Stelle ausgeschlachtet (Kommentar: Dein Shopify-Shop gehört dir nicht), aber das Muster ist universell. Sobald deine Geschäftsprozesse in einem proprietären Datenmodell leben, ist der Wechsel der nächsten Plattform kein Engineering-Projekt mehr, sondern ein Replatforming, das zwölf bis vierundzwanzig Monate kostet und dessen Risikoprofil sich strukturell nicht von einer Open-Heart-Surgery unterscheidet.
Genau diese Ausweglosigkeit ist der Preis, den du zahlst, wenn du dem Anbieter die Wartung abgekauft hast. Open Source kippt diese Dynamik nicht magisch um. Auch bei Shopware 6, bei PostgreSQL, bei Medusa, bei jeder Node- oder PHP-Codebasis musst du irgendwann migrieren, refaktorieren, ablösen. Der Unterschied ist die Verhandlungsposition.
Niemand kann dir den Quellcode entziehen, den du gerade selbst betreibst.
Niemand kann das Datenmodell ändern, das in deiner eigenen Datenbank liegt.
Niemand kann eine Lizenzklausel erfinden, die du auf einmal nicht mehr erfüllst.
Du bestimmst Tempo und Pfad. Das ist keine Romantik, das ist Architektur.
Die drei Schichten eines ernst gemeinten Open-Source-Fundaments
Wer „Open Source“ sagt, meint je nach Tagesform sehr unterschiedliche Dinge. Damit die Diskussion nicht ins Pauschale rutscht, hilft eine simple Schichtung mit drei Ebenen, an denen die Entscheidung „proprietär oder offen“ jeweils unabhängig fällt, mit jeweils anderem Hebel.
Schicht 1: Plattform und Runtime. Linux, PostgreSQL, Node.js, PHP, Redis, Kubernetes. Diese Schicht ist Open Source so deutlich stabilisiert, dass es bei einer Neuentwicklung heute keinen ernsthaften Grund mehr gibt, anders zu wählen. Wenn dein Stack hier noch proprietäre Altlasten trägt (eine Oracle-Datenbank für eine Anwendung, die ihre Features nicht braucht; ein kostenpflichtiger Application-Server, der nur historische Gründe hat), ist das die billigste und risikoarmste Sanierung, mit der du anfangen kannst. Die Migration auf PostgreSQL ist heute ein gut beschriebenes Pattern, kein Forschungsprojekt mehr.
Schicht 2: Framework und Anwendungssystem. Hier liegt der spannende Markt: Shopware 6 statt SAP Commerce Cloud, Medusa oder Saleor statt Shopify, Mautic statt HubSpot Marketing Hub, Twenty oder EspoCRM statt Salesforce für kleinere Setups, Strapi oder Directus statt proprietärem Headless-CMS. Diese Schicht hat den größten direkten Hebel auf deine Geschäftsprozesse und den größten Schmerz im Wechsel, weil hier die Custom-Logik sitzt. Genau deshalb ist sie der relevanteste Ort für die Vendor-Lock-in-Frage. Wer hier heute noch eine reine SaaS-Wette eingeht, baut die nächsten fünf Jahre Geschäftsprozesse in ein Datenmodell, das ihm nicht gehört.
Schicht 3: Eigene Geschäftsapplikationen. Die innerste Schicht (der Code, den dein Team selbst schreibt) ist per Definition deine. Die Frage ist, ob sie modular und ablösbar gebaut ist. Hier macht der KI-Effekt am meisten Eindruck: Refactors, die früher politisch schwer durchsetzbar waren, weil sie keine neuen Features lieferten, sind in einem agentengetriebenen Workflow auf einmal billig. „Wir können das nicht refaktorieren, wir haben keine Kapazität“ verliert als Begründung an Substanz. Damit fällt das letzte Argument, an Altlasten festzuhalten.
Wo Open Source plus KI heute nicht die Antwort ist
Eine ehrliche Position braucht ihre Grenzen, sonst klingt sie nach Werbung. Drei Bereiche, in denen wir grundsätzlich von einer reinen Open-Source-Strategie abraten.
In stark regulierten Nischen, in denen ein einzelner zertifizierter Anbieter den Markt deckt: Apotheken-Warenwirtschaft mit Securpharm-Anbindung, gewisse Steuer- und Buchhaltungs-Schnittstellen, medizinische Praxis-Software mit KBV-Zertifizierung. Hier kaufst du nicht primär Software, sondern eine Konformitäts-Garantie. Der eigene Stack lohnt sich nur in Sondersituationen.
Bei reinen Commodity-Funktionen mit hoher SaaS-Reife, deren Datenexport sauber definiert ist: Transactional Mail (über einen Anbieter mit IP-Reputation), bestimmte Payment-Provider, Code-Hosting. Da bringt Souveränität dir nichts und kostet dich Zeit. Wer eigene Mail-Server für Order-Confirmations betreibt, weil es „prinzipieller“ ist, optimiert die falsche Variable.
Wenn deine Organisation nicht den Willen und die Disziplin hat, eine eigene Codebasis auch wirklich zu betreiben. Open Source plus KI senkt die Wartungslast, aber nicht auf null. Wer keine CI/CD-Pipeline, keine sauberen Tests, kein Logging hat, bekommt durch einen Agenten kein gutes System, sondern ein schlecht laufendes System mit höherer Frequenz. Die Modernisierung der eigenen Engineering-Praxis ist die Voraussetzung, nicht das Nebenergebnis. Wer hier strategisch aufstellt, findet die nötigen Bausteine in unserer Enterprise-Software-Beratung.
Wie du anfängst, pragmatisch statt ideologisch
Niemand wirft seinen funktionierenden Stack über Nacht um. Aber die nächste Make-or-Buy-Entscheidung steht immer schon im Kalender, meist gebunden an einen Vertragsstichtag. Drei Schritte, mit denen du anfängst, bevor das nächste Renewal kommt.
Erstens: Inventur, ehrlich. Liste deine geschäftskritischen Systeme, die Lizenzkosten pro Jahr, das Vertragsende, das hinterlegte Datenmodell, die Exportierbarkeit. Mach das auf einer Seite, nicht in einem Tool. Du wirst überrascht sein, wie viele Systeme darin auftauchen, deren Kosten niemand mehr aktiv hinterfragt, und wie viele davon eine valide Open-Source-Alternative haben.
Zweitens: Den nächsten ersetzbaren Baustein bestimmen. Nicht den kritischsten, den ersetzbarsten. Eine Mautic-Migration aus HubSpot ist in der Größenordnung eines Quartals machbar (je nach Setup-Tiefe), lehrt deine Organisation den Open-Source-Betrieb und liefert sofort eine sichtbare Kostenlinie. Ein ERP-Replatforming als Erstprojekt ist heroisch und wird scheitern. Der erste Migrationsschritt soll das Pattern etablieren, nicht den Härtetest gewinnen. Und ja, Mautic ist nicht hübsch. Es ist trotzdem deins.
Drittens: Den KI-Wartungs-Loop aufbauen, bevor du Open Source skalierst. CI/CD, automatisierte Tests, ein Coding-Agent im Pull-Request-Loop, ein klares Verfahren, wer welche Agenten-PRs reviewt und merged. Diese Investition zahlt sich auf jedem deiner Repos aus, nicht nur auf den neuen. Sie ist die Grundlage, auf der die ganze Rechnung dieses Posts überhaupt aufgeht. Ohne sie kauft dir der Agent vor allem die Möglichkeit, schneller in die Produktion zu kotzen.
Zurück zur Nacht mit den siebzehn Pull Requests
Genau in der Nacht, in der ein Coding-Agent siebzehn Pull Requests aufmacht und ein Entwickler sie am Vormittag mergt, liegt der gesamte ökonomische Hebel dieses Posts. Was früher 0,8 FTE laufende Pflege gebunden hat, kostet dann 0,3 FTE plus Tool-Budget. Die Lizenzlinie der proprietären Welt daneben ist konstant teuer geblieben. Die Frage hat sich nicht geändert. Die Mathematik dahinter schon.
Wenn dich die Anwendung dieser Logik auf deinen konkreten Stack interessiert (ERP-Anbindung, Shop-System, CRM, Marketing-Automation), sprich mit uns über Open-Source-getriebene E-Commerce-Stacks. Wir bauen offene Stacks, begleiten den Betrieb und kennen den Punkt, an dem die Theorie auf den real existierenden Wartungs-Backlog trifft.