Picture the morning in a modern open-source team in 2026. In the repository of the main Shopware 6 shop there are seventeen pull requests that were created overnight: three dependency bumps, a CVE patch in a Symfony library, a few small refactors, an update of the API client library to a new major version including the two adjustments needed to keep the tests green. All of it was written by a coding agent. One developer spends the morning reviewing and merging. With that, maintenance is done for the day.
It is in precisely this one night that the most important argument of the last twenty years against open source dies. Nobody notices, because it happens quietly. But every make-or-buy decision that still rests on the old maintenance equation has, since production-ready coding agents became widely available (from mid-2025), been running on a slide that is no longer accurate.
This post is the top-down view of the pattern behind it: what the AI revolution does to your maintenance equation, why ‘vendor lock-in’ thereby returns from an abstract risk to concrete financial damage, and what an open-source foundation beneath your core systems looks like today if you are serious about it.
What the old equation really looked like, and why it worked
Anyone who had to make an ERP, CRM or shop decision in the 2010s was shown the same slide by every vendor. Licence costs are visible, personnel costs are hidden. As an illustrative ballpark figure, a closed-source solution costs 250,000 euros a year for licence and support. A comparable open-source stack costs zero euros in licences, but you need two to four developers to maintain it, plus an agency as backup. If you do the maths fairly, you end up with similar total costs, with less convenience.
That was not vendor propaganda; it was honestly observable. Anyone who ran a Magento 1 shop in the years before the M2 replatforming knew the pain: security patches every few weeks, major upgrades that tie up half a year of engineering, every third extension breaking on update. The same story applied to self-hosted CRMs, to in-house developments on a Java stack, to internal data pipelines. Open source was free, and it constantly cost you people.
It was precisely in this gap between predictable licences and unpredictable maintenance that the big SaaS vendors built their market share: Salesforce, Shopify, ServiceNow, HubSpot. You pay monthly, you do not have to patch anything, you do not have to hire anyone who knows the stack. That was a real promise, and for the most part it was kept.
What fundamentally changed in 2025/26
The break came quietly. While the headlines rushed to image, voice and chat models, coding agents (Claude Code, Cursor, GitHub Copilot Coding Agent and open-source tools such as Aider and OpenHands) took over a different job: the ongoing maintenance of existing codebases. Precisely the work that was the expensive item in the old equation.
What a coding agent reliably handles today with human oversight in the pull request loop: it reads a security advisory, identifies the affected library in package.json or composer.json, bumps the version, adjusts the two places in the code where the interface has changed, and opens a pull request with green tests. It responds to an error in the Sentry log, isolates the stack trace, and writes a reproduction test and a fix for it. It takes on a refactoring task that would have been three days of manual work and delivers, in twenty minutes, a diff that a human only has to review.
In short: the coding agent is not the senior developer who designs the architecture. It is the junior developer who works through the unloved, repetitive maintenance tickets, and it was precisely these tickets that were the real argument against open source.
The before-and-after picture of a typical SME stack: before, Dependabot alerts landed in the backlog, which was worked through once a quarter in a sprint, provided urgent features allowed it. CVE patches arrived late. Test coverage eroded under delivery pressure. After, maintenance runs as a continuous stream of pull requests, CVE patches are often in the branch within hours, and test coverage can be raised to a reasonable level retrospectively with manageable effort. What was still expensive in 2022 is mostly routine in 2026.
The new equation, rough but honest
Let us make this concrete as a model calculation. Take a Shopware 6 shop run by an SME with a handful of custom plugins, connected to an ERP via REST. Two years ago, this stack would realistically have tied up 0.5 to 1 FTE of engineering in pure maintenance, plus an agency kept on standby for major upgrades and emergencies. At DACH senior salary levels plus overhead, that comes to 80,000 to 140,000 euros a year, depending on the seniority mix. This is not an empirical market figure; it is the order of magnitude that can be derived from a salary index and a realistic maintenance budget.
With a consistently set-up maintenance loop (a clean test set-up, a CI/CD pipeline, a coding agent that opens dependency and security PRs at night, a clear review process), a third to a half of this effort is a realistic range to expect. Heavily dependent on test coverage and model quality, but not wishful thinking. The money does not disappear; it shifts. Instead of paying for 0.8 FTE of maintenance, you pay for 0.3 FTE of maintenance plus a few hundred euros a month in tool and model costs.
Compare that with the proprietary counterpart. For comparable volume in an SME, an enterprise shop suite or a SaaS platform of the Salesforce class costs, depending on edition and revenue, in the mid-to-high five- to six-figure euro range per year, often as a percentage of revenue (see our detailed analysis of Shopware vs. Salesforce Commerce Cloud). This line is guaranteed not to shrink. Anyone who has handed over their own growth as the basis of assessment pays twice in every successful year.
That is the new equation in one sentence: the licence line of the proprietary world has stayed consistently expensive. The maintenance line of the open-source world has been halved. The gap is not closing. It is opening, in the other direction.
Vendor lock-in is the real risk that the old equation pushed aside
As long as the maintenance question was so dominant, it drowned out the second, quieter question: what actually happens when your vendor changes and you do not want to go along with it? Raises prices, discontinues features, halves an API quota, moves a module into the more expensive bundle, buys a competitor, pivots to please a strategic investor. For two decades, this question had the status of a theoretical risk. Everyone knew a cautionary example, but ‘it won’t happen to us’.
It happens all the time. We have dissected it elsewhere for the special case of platforms (Commentary: Your Shopify shop doesn’t belong to you), but the pattern is universal. As soon as your business processes live in a proprietary data model, switching to the next platform is no longer an engineering project but a replatforming that costs twelve to twenty-four months and whose risk profile is structurally no different from open-heart surgery.
It is precisely this lack of a way out that is the price you pay when you have bought maintenance from the vendor. Open source does not magically reverse this dynamic. With Shopware 6, PostgreSQL, Medusa, or any Node or PHP codebase, you too will have to migrate, refactor or replace at some point. The difference is your negotiating position.
Nobody can take away the source code that you are running yourself.
Nobody can change the data model that sits in your own database.
Nobody can invent a licence clause that you suddenly no longer meet.
You set the pace and the path. That is not romanticism, that is architecture.
The three layers of a serious open-source foundation
When people say ‘open source’, they mean very different things depending on the day. To keep the discussion from becoming too sweeping, a simple layering into three levels helps, at each of which the ‘proprietary or open’ decision is made independently, each with a different lever.
Layer 1: platform and runtime. Linux, PostgreSQL, Node.js, PHP, Redis, Kubernetes. This layer has stabilised so clearly as open source that, for new development today, there is no longer any serious reason to choose otherwise. If your stack still carries proprietary legacy here (an Oracle database for an application that does not need its features; a paid application server that is only there for historical reasons), this is the cheapest and lowest-risk clean-up you can start with. Migrating to PostgreSQL is a well-documented pattern today, no longer a research project.
Layer 2: framework and application system. This is where the exciting market lies: Shopware 6 instead of SAP Commerce Cloud, Medusa or Saleor instead of Shopify, Mautic instead of HubSpot Marketing Hub, Twenty or EspoCRM instead of Salesforce for smaller set-ups, Strapi or Directus instead of a proprietary headless CMS. This layer has the greatest direct leverage on your business processes and causes the most pain when switching, because this is where the custom logic sits. That is exactly why it is the most relevant place for the vendor lock-in question. Anyone who still makes a pure SaaS bet here today will spend the next five years building business processes into a data model they do not own.
Layer 3: your own business applications. The innermost layer (the code your team writes itself) is yours by definition. The question is whether it is built to be modular and replaceable. This is where the AI effect makes the biggest impression: refactors that used to be politically hard to push through, because they delivered no new features, suddenly become cheap in an agent-driven workflow. ‘We can’t refactor that, we don’t have the capacity’ loses substance as a justification. With that, the last argument for clinging to legacy systems falls away.
Where open source plus AI is not the answer today
An honest position needs its limits, otherwise it sounds like advertising. Here are three areas in which we generally advise against a pure open-source strategy.
In heavily regulated niches where a single certified vendor covers the market: pharmacy inventory management with a Securpharm connection, certain tax and accounting interfaces, medical practice software with KBV certification. Here you are not primarily buying software but a compliance guarantee. Your own stack only pays off in special situations.
For pure commodity functions with high SaaS maturity whose data export is cleanly defined: transactional mail (via a provider with IP reputation), certain payment providers, code hosting. Here sovereignty gets you nothing and costs you time. Anyone who runs their own mail servers for order confirmations because it is ‘more principled’ is optimising the wrong variable.
If your organisation lacks the will and the discipline to actually run a codebase of its own. Open source plus AI lowers the maintenance burden, but not to zero. If you have no CI/CD pipeline, no clean tests and no logging, an agent will not give you a good system, but a badly running system at a higher frequency. Modernising your own engineering practice is the prerequisite, not the by-product. If you want to set yourself up strategically here, you will find the building blocks you need in our enterprise software consulting.
How to get started, pragmatically rather than ideologically
Nobody overturns a working stack overnight. But the next make-or-buy decision is always already in the calendar, usually tied to a contract deadline. Here are three steps to start with before the next renewal comes round.
First: an honest inventory. List your business-critical systems, the licence costs per year, the contract end, the underlying data model and the exportability. Do it on one page, not in a tool. You will be surprised how many systems show up whose costs nobody actively questions any more, and how many of them have a valid open-source alternative.
Second: identify the next replaceable building block. Not the most critical one, the most replaceable. A Mautic migration from HubSpot is feasible within roughly a quarter (depending on the depth of the set-up), teaches your organisation how to run open source and immediately delivers a visible cost line. An ERP replatforming as a first project is heroic and will fail. The first migration step should establish the pattern, not win the stress test. And yes, Mautic is not pretty. It is still yours.
Third: build the AI maintenance loop before you scale open source. CI/CD, automated tests, a coding agent in the pull request loop, a clear procedure for who reviews and merges which agent PRs. This investment pays off across every one of your repos, not just the new ones. It is the foundation on which the whole equation in this post works out at all. Without it, what the agent mainly buys you is the ability to spew into production faster.
Back to the night of the seventeen pull requests
It is in that very night, when a coding agent opens seventeen pull requests and a developer merges them in the morning, that the entire economic lever of this post lies. What used to tie up 0.8 FTE of ongoing maintenance then costs 0.3 FTE plus a tool budget. The licence line of the proprietary world next to it has stayed consistently expensive. The question has not changed. The maths behind it has.
If you are interested in applying this logic to your specific stack (ERP integration, shop system, CRM, marketing automation), talk to us about open-source-driven e-commerce stacks. We build open stacks, support their operation and know the point at which theory meets the maintenance backlog as it really exists.