Why Dropsolid AI’s Open DXP is a sovereignty strategy that survives ownership changes, even ours
Europe’s “buy European” reflex is understandable. But it’s not a sovereignty guarantee.
As Dries Buytaert wrote earlier in The Software Sovereignty Scale, sovereignty is not primarily about where a company is headquartered. It’s about whether you retain “freedom of action” over the technology you depend on, even if a vendor changes strategy, gets acquired, or disappears. The real test is simple: if conditions change, can you keep using, modifying, and maintaining what you run?
We agree. And we want to take that principle one step further.
Because in 2026, “the software” you depend on is no longer just a CMS. It’s your entire Digital Experience Platform, and increasingly, your AI layer: models, vector databases, orchestration, prompts, evaluation, and the data that makes your organization smarter over time.
So here is the position we’re taking at Dropsolid AI:
We apply “the freedom to leave” to the whole stack, not just to Drupal.
And that changes everything.
sovereign stack.png
The original image at https://dri.es/the-software-sovereignty-scale , this is an expansion on it.
The uncomfortable (but necessary) sovereignty question
If you are a government agency, a regulated enterprise, or any organization with long-term accountability, there’s one question that matters more than the marketing:
What happens if your vendor changes ownership?
Dries used the Skype example to illustrate how “European” can change with a single acquisition, and why that makes “Buy European” an incomplete sovereignty strategy.
Now let’s ask the harder version:
What happens if we change ownership?
What if one day Dropsolid AI were acquired by a non-European company?
We can’t pretend acquisitions never happen in tech. But we can design so that our customers don’t become collateral damage of someone else’s jurisdiction, roadmap, pricing, or policy constraints.
That’s the heart of sovereign architecture:
Your sovereignty cannot depend on our continued “Europeanness”.
It must depend on your ability to move.
Dries’ principle: the exit door is what creates trust
In The freedom to leave is what makes customers stay, Dries described how Acquia Source allows customers to export their entire Drupal site, code, theme, configuration, content, and data, and run it on any infrastructure they choose. He argues that when leaving is easy, customers stay because they want to, not because they’re trapped.
We strongly agree with that philosophy.
But we also believe the market has outgrown applying it to “the website” alone.
A modern digital platform includes:
- Content management
- Marketing automation
- Customer data and personalization
- Integration hubs and APIs
- And now: AI capabilities across content, search, support, and operations
If you can export Drupal, but your customer data platform is locked in… you’re still trapped.
If your content is portable, but your AI intelligence is not… you’re still trapped.
So we asked ourselves:
What would it look like to implement the freedom to leave across the entire DXP, including AI?
Our answer: sovereignty that survives worst-case scenarios
Here is the simplest way to describe Dropsolid AI’s strategy:
Dropsolid AI is so open that even if we change ownership, the whole stack, including AI and the intelligence you’ve built, can be moved to a different infrastructure provider.
That is not a slogan. It’s a product commitment. And it is exactly why we are committed to an Open DXP.
On our platform pages we explicitly position the architecture as open and sovereign, designed to avoid lock-in, with containerized hosting and hybrid/on‑prem/sovereign deployment options, including sovereign options for running LLMs and vector databases on‑prem.
This is what “sovereignty” means to us in practice:
- If a vendor changes terms, you can move.
- If jurisdictional risk increases, you can move.
- If your organization outgrows our platform, you can move.
- If we ever change ownership… you can move.
And because leaving is possible, staying becomes a choice, and that creates real trust.
What does “the whole stack” mean?
When we say “the whole stack”, we mean more than a database export.
A real “freedom to leave” promise must cover:
1) The platform layer
Not just your Drupal site, but all the core components.
Our approach is built around an open DXP foundation, described publicly as Drupal-based and integrated with other open components, with a cloud‑agnostic posture.
2) The infrastructure layer
Sovereignty collapses if you can’t change infrastructure providers.
That’s why we talk openly about hybrid patterns and connecting the platform to your infrastructure of choice, including cloud‑to‑cloud, cloud‑to‑prem, and Kubernetes-based setups (even across different providers).
3) The data layer
Your sovereignty is only as strong as your data portability.
Content is obvious, but the real lock-in risk typically sits in:
- Customer profiles and behavioral data
- Segmentation logic
- Campaign and journey data
- Consent and compliance artifacts
- Personalization rules and outcomes
An open DXP only matters if it keeps this layer under your control.
4) The AI layer
This is the new sovereignty battleground.
If your AI features rely on a single proprietary model endpoint, a single proprietary vector database, or a closed orchestration system, then “open source CMS” is not enough.
This is why we explicitly design for sovereign AI deployment options, including the ability to run LLMs and vector databases on‑prem in sovereign setups.
And it’s why “freedom to leave” must cover AI assets such as:
- Prompts, guardrails, and workflows
- Retrieval pipelines and indexes
- Evaluation and quality measures
- The operational patterns that make the system safe and reliable
- And the organizational intelligence created through usage over time
If you can’t move that, you don’t have AI sovereignty, you have AI dependency.
5) Is there nothing proprietary then?
It’s true that not every part of our platform is open source today. Some elements, for example the CDP interface and parts of the orchestration layer are Dropsolid IP. That raises a fair question:
“If we leave, and those pieces are not open source, aren’t we stuck with a frozen version and no updates?”
Here is how we design the platform layer to keep your freedom of action, even with proprietary components:
-
Open core, open standards, portable runtime
The operational platform is built around an open DXP core (Drupal and other open components), packaged in a cloud‑agnostic, containerized runtime.
The same artefacts we use to run your stack on Dropsolid infrastructure can be deployed on other Kubernetes‑based or cloud environments. This is not a theoretical promise: the platform is engineered to:- expose standard APIs and data formats for the CDP and AI services
- separate configuration, data, and runtime so they can be exported and re‑attached elsewhere
- use infrastructure‑as‑code and reference architectures that can be replayed on different providers
That’s how we reduce the “it works only in our SaaS” risk at the platform level.
-
Contractual exit rights for non‑open‑source components
For the parts of the platform that are not open source, we don’t pretend they magically become open. Instead, we offer contractual freedom:
- For a clearly defined fee and process, you can obtain a perpetual license (with a perpetual license for internal use only, with commercial redistribution expressly prohibited) to the then‑current version of the proprietary platform components you are using (e.g. CDP UI/orchestration). This is Grade C on the scale.
- We pair this with exit services: assistance to install, configure, and validate the stack on your own infrastructure (or a provider of your choice).
- From that point on, you own the fork: you can maintain it yourself, work with a partner, or negotiate separate support arrangements with us.
This means that even the non‑open‑source pieces cannot be used to trap you in a contract. You can keep running what you have, on infrastructure you control.
-
Clarity about updates and responsibilities
It’s correct that, once you exercise this exit option and run your own fork, you are no longer on our standard release track. That is the trade‑off:
- You retain operational continuity: you can keep your existing platform and data running without having to rebuild your DXP, CDP and AI stack from scratch.
- You gain full control over timing, change management, and further evolution.
- You take on shared responsibility for future updates: you can evolve the fork yourself, work with an implementation partner, or contract us for paid upgrade or advisory services, if available under the then‑current commercial model.
In other words: leaving doesn’t give you free lifetime product development. It gives you a viable, supported way to take the full stack with you, including the proprietary bits, and then decide how much you want to invest in its further evolution.
-
From “guaranteed perfection” to “guaranteed feasibility”
Migrating a full DXP + CDP + AI platform is non‑trivial. We don’t market “one‑click exit”. What we guarantee at the platform layer is:
- Feasibility: the architecture, packaging and licensing are deliberately designed so that an exit to your own infrastructure is technically and legally possible.
- Co‑operation: we commit to reasonable technical support and exit services so the platform can be stood up and validated in your new environment.
- Portability of your intelligence: your data, configurations, journeys, segments, prompts, retrieval logic, and evaluation pipelines can move with you.
That’s what we mean when we say we apply “freedom to leave” to the whole stack. Even where the code is not open source, the platform components are structured so that you can take it with you, run it elsewhere, and keep operating on your own terms.
What is not open source:
What you don’t take with you is the orchestration platform itself. That layer, the part that makes it easy to manage many DXPs, its environments, components on a cloud agnostic infrastructure from a single control plane is proprietary Dropsolid IP.
What we do give you is a full export of the building blocks that matter for your sovereignty: the DXP components, data, configurations, and AI/CDP assets you run on top. In other words, you can take the entire stack you depend on and operate it elsewhere, but not our multi‑tenant orchestration platform that sits behind the scenes to run it at scale.
We just happen to orchestrate applications that form the AI powered DXPs very good at scale with security and that is why you should stay. Subscribing to Dropsolid buys you all the knowledge and evolution power to maximally leverage the open source components that power the open DXP. We keep things up to date for you, we evolve the integrations, we tune the infrastructure and provide the tools for developers and we keep it secure and compliant. We contribute heavily to the roadmaps of projects like for example Drupal and Mautic. Our customers don't have to have a team that understands all these applications, how they are working together and how to run them at scale.
This core open DXP still allows us to run proprietary SaaS layers and add-ons to increase ease of use for customers that do not really care about sovereignty. The product core open DXP we are offering is exportable. Of course it is mostly enterprises that choose this formula. So by having the customers to choose the open DXP option we guarantee their freedom.
Open DXP as a sovereignty guarantee, not a feature list
Dries’ sovereignty scale draws a crucial line between open source and proprietary systems: open licensing gives you durable rights that cannot be revoked by a vendor decision.
We take that thinking and apply it to a modern DXP reality:
- Structural sovereignty (license + community) is foundational.
- Operational sovereignty (deployability + portability) is what makes it real.
- AI sovereignty (control over the intelligence layer) is what makes it future-proof.
That’s why our platform positioning emphasizes full portability and avoiding vendor lock-in, and why we’ve invested in hybrid patterns and sovereign options.
Our commitment: the exit must work, even when you don’t need it
It’s easy to say “open” in a brochure.
The hard part is being willing to design your business so customers can actually leave.
That’s the same principle Dries describes: the exit door is what creates confidence, and paradoxically, loyalty.
At Dropsolid AI, we are committing to that logic at the level that matters today:
not just Drupal, but the entire DXP and AI intelligence layer.
Because the ultimate sovereignty test isn’t whether your vendor is European today.
It’s whether you can keep operating tomorrow, regardless of what happens to the vendor.
A procurement-ready sovereignty checklist
If you are evaluating DXPs, AI layers, or “sovereign” platforms, here are a few questions that cut through the noise:
- If your company is acquired, can we move the full stack (not just content)?
- Can we run the platform on our own infrastructure (or a provider of our choice)?
- Can we migrate without rebuilding personalization, segmentation, and journeys from scratch?
- Can we run AI components in sovereign modes (including on‑prem options for LLMs and vector databases)?
- Do we keep the intelligence, prompts, workflows, retrieval logic, and evaluation, or is it trapped in your SaaS?
If a vendor can’t answer these clearly, “sovereignty” is just branding.
Closing: the Dropsolid AI powered Open DXP
We respect the direction Dries is pushing the industry: sovereignty is about durable freedom of action, not marketing labels.
Our contribution is straightforward:
We apply “the freedom to leave” to the whole stack, the DXP and the AI, so that your digital autonomy survives policy shifts, vendor strategy changes, and even ownership changes.
That is the power of the Open DXP.
That is why Dropsolid is committed to it.
And that is what we mean by the Dropsolid AI powered Open DXP.