Critical External Dependency: When a Vendor Becomes a Risk
Every company today depends on external technologies and vendors. We use cloud, SaaS services, payment gateways, accounting systems, hosting, or external developers.
That is not a problem in itself. The problem starts the moment we cannot function without one particular vendor.
That is called a critical external dependency.
When does it become a problem?
Picture an e-shop that has been running on a single platform for several years. It holds the website, the products, the orders, the stock, and the link to accounting.
Then the vendor raises the price sharply.
The company can leave. But migrating to another platform means moving the data, rebuilding the integrations, reworking the website, and testing all of it again. It can cost hundreds of thousands and take months.
So the company technically has the option to leave, but practically cannot afford it.
That is vendor lock-in — a dependence on a vendor that is too expensive or too complicated to escape.
And it is not only about price. The vendor can discontinue the product, change the terms, or simply cease to exist.
Why open source is interesting
One way to reduce this risk is open source.
From the point of view of vendor risk, its main advantage is not that it is free. What matters is that the source code is not the property of a single vendor.
Drupal is an example.
A company can have one Drupal partner or freelancer. If the cooperation ends, it can find another. It does not have to change the CMS itself because of that.
That creates replaceability of the vendor.
The technology stays the same; what changes is only the company or the person looking after it.
With a proprietary platform, by contrast, the technology and the vendor often merge into one in practice.
Open source does not remove the risk, of course. If, for example, one developer builds a company’s entire system and nobody else understands it, a dependence on that specific person appears.
That is why what matters is not only open code, but also documentation, standard technologies, and the availability of other specialists.
What about AI agents?
AI adds a new variable to this equation.
An AI agent can now go through source code, look for bugs, explain how it works, or help a new developer get oriented in an unfamiliar system quickly.
And here open source has another advantage.
Open projects have public source code, documentation, and a large volume of historical discussion and examples. So the AI has far more information available.
That can significantly shorten the time a new vendor needs to understand the system.
Being open may therefore mean not just more available developers. It may also mean better availability of knowledge for AI tools.
How big is your dependency?
For every important system, I would ask four simple questions:
- How many other companies or people could take us over?
- Do we have the source code, the data, and the documentation under our control?
- How much time and money would changing vendors cost?
- Is the technology open, widely used, and does it have an active community?
If the answer to the first question is “nobody” and to the third “we don’t know”, that is a good reason to start addressing the risk.
The point is not to remove every dependency. That is not realistic.
The goal is that a critical vendor is not at the same time the only possible way to run your system.
And that is exactly where open source can be an important part of digital sovereignty.
It is not only about who supplies the technology.
It is about whether you can take it over, change it, or replace it if you need to.