Open Isn't Ownership

Blueprints Aren't Ownership

I've been trying to pin down a pattern I've seen for years, but never really named clearly.

It shows up whenever a system lives long enough. Not in the first month. Not during the exciting build phase. More like year two, year five, year ten.

The organization still "has the code". Everything is technically running. But the number of things you can change without asking permission from something outside your org keeps shrinking.

At some point you realize: this isn't just "lock-in" as a buzzword. It's a change in what the system is.

I keep coming back to a house analogy: open source is often just the blueprints to a house you don't own.

You can read the code. You can even run it. But being able to operate it tomorrow depends on rights that can be revoked, not files you can download.

Accessible Code vs Irrevocable Rights

Open source is usually discussed like it's binary: open vs closed.

But the difference that actually matters over time is simpler: accessible code vs irrevocable rights.

Some software is open today, but can be taken over tomorrow.

Some software is designed so nobody can ever do that.

That distinction changes engineering decisions. A lot.

(If you want to test where a project sits on this spectrum, I built a small checker here.)

I've started using the word sovereignty for this: the durability of your right to operate.

How Control Shifts

I recently read Dries Buytaert, founder of Drupal, describing a "software sovereignty scale". It's a helpful framing because it forces a more honest question:

If the vendor disappears, changes terms, or becomes hostile… can we still run the system anyway?

Not "can we migrate in a year". Can we keep operating next week?

When you look at stacks through that lens, the world looks very different.

The pattern behind most "open source rug pulls" is not mysterious.

A project grows.

A company forms around it.

The community creates value (adoption, plugins, docs, mindshare).

Then the business eventually needs more control than the original license and governance allow.

Open source isn't a property right. It's a community norm.

So the terms change.

It's not always dramatic. Sometimes it's a new license. Sometimes it's "open core". Sometimes it's a hosted product that becomes the only realistic way to run it.

But the outcome is similar: the future gets privatized.

We've watched this happen with major infrastructure projects:

• MySQL → MariaDB
• OpenOffice → LibreOffice
• Elasticsearch → OpenSearch
• Terraform → OpenTofu
• Redis → Valkey

None of these were random events. They were the predictable result of a structure where one steward could decide the future.

When "Open" Still Isn't Owned

Modern stacks add a new twist: you can be "open source" and still not own anything important.

If your stack depends on:

• hosted identity,
• hosted data,
• hosted search,
• hosted edge logic,
• vendor-specific cloud primitives,

…then the system might be source-available, but it isn't sovereign.

You're not operating software. You're operating agreements.

That's not automatically wrong. Sometimes it's the right trade.

The problem is when people talk about sovereignty while designing systems that can't survive outside those agreements.

Field observation

This is something I've noticed a lot in Denmark (and it seems broader across Europe):

Organizations talk seriously about autonomy, but they are deeply embedded in Microsoft for identity, devices, productivity, collaboration, sometimes cloud… to the point where turning it off would halt daily operations.

So I get stuck on a basic question:

What does sovereignty mean if your organization can't function without a single external platform?

Again, not as ideology. As an operational property of the system.

When this topic comes up in conversations, it almost always drifts toward cost.

Not loudly. Not defensively. Just practically.

And the refrain is familiar:

Open source is expensive.
Self-hosting is expensive.
Running your own platform is expensive.

And in the short term, that's often true.

But I've started to notice that the framing is incomplete.

Managed platforms don't remove cost. They reshape it into:

• dependency,
• reduced optionality,
• and eventually, negotiation.

The visible costs are easy to track. Headcount. Infrastructure. Invoices.

The invisible ones are harder to quantify. Permission. Portability. Internal competence.

Over time, those invisible costs accumulate quietly.

And years later, the conversation has shifted without anyone quite noticing.

It stops being:

"How do we build this?"

And starts being:

"What are we allowed to run?"

That shift is the real cost.

A Simple Audit

When I reduce all of this down, sovereignty feels layered.

• License structure.
• Governance exposure.
• Operational capture.
• Dependency surface.

A Git repo isn't sovereignty. A license alone isn't sovereignty.

The Sovereignty Checker I built only evaluates the first layer. It's a starting signal, not a full diagnosis.

Real sovereignty is the combination of:

• software you are allowed to run,
• systems you can actually reproduce elsewhere,
• and internal competence you haven't outsourced away.

If sovereignty is a real goal, architecture has to reflect it.

Otherwise "sovereignty" becomes branding while the stack continues moving in the opposite direction.

And the moment you need to change direction is usually the moment you realize you can't.

What Remains

I don't think sovereignty is a moral stance. It's a structural one.

Every system makes tradeoffs. Speed for control. Convenience for optionality. Managed simplicity for long-term independence.

The question isn't whether you use vendors. Everyone does.

The question is whether you still have the ability to operate without them.

That answer isn't ideological. It's architectural.

Rob Dean

Platform architect focused on long-lived systems, software sovereignty, and enterprise web infrastructure.

Based in Denmark. Contact