Why digital dependence is not just a tech problem, and how open technology changes the balance of power
Most of us can easily relate to a particular kind of frustration that belongs to the digital age. It is the moment when a device still works, but only on someone else’s terms. When the file exists, but cannot be opened outside the platform. The photo is yours, but the album belongs to the cloud. The lesson is yours, but the learning history belongs to the LMS. The health data comes from your own body, but the meaningful trend is locked behind a subscription. The municipality owns the public responsibility, but the workflow lives inside a supplier’s interface. The organisation paid for the platform, but cannot leave it without losing years of memory.
Digital dependence usually enters our lives as convenience. A smoother dashboard. A bundled service. A free tier. A platform everyone else already uses. A procurement decision that seems sensible because the vendor is established and the interface looks modern. A device that promises to make life easier, healthier, safer, more connected, more efficient. At first, the tool feels like help. Only later do we discover that help has become habit, habit has become infrastructure, and infrastructure has become dependency.
We do not usually notice who owns the tools until the day we try to leave them.
That is the strange politics of the digital world. Ownership no longer means what we think it means. We can buy the object and not control the system. We can pay for the service and not control the data. We can use the platform every day and not understand the rules that shape what we are allowed to do inside it. We can digitize a public service and accidentally hand over the living memory of an institution to a vendor whose business model depends on being hard to replace.
The question, then, is not only whether a tool is useful. Many locked systems are useful. Many proprietary platforms are polished, stable, and professionally supported. The question is deeper: what happens when the tools we depend on are designed in ways that make understanding difficult, repair expensive, migration painful, and exit almost unthinkable?
This is where open technology enters the conversation. Not as a magic cure, and certainly not as a romantic fantasy in which every organisation becomes a software collective overnight. Open source does not automatically make a system fair, secure, cheap, or democratic. But it changes the ownership question. It asks whether the systems we rely on can be inspected, adapted, repaired, reused, supported by more than one provider, and governed by the people and institutions whose lives they shape.
The first article in this series argued that open source is not just for developers. This second article begins where that one left off. If we already live inside software, then we must ask who owns the rooms, who holds the keys, who wrote the rules, and whether the doors still open from the inside.
The invisible rent we pay
Most digital dependence begins with a perfectly reasonable decision. A family chooses a cloud service because it keeps photos safe. A freelancer chooses a design platform because clients use it. A school adopts a learning platform because it solves an urgent administrative problem. A charity starts using a donor database because spreadsheets are no longer enough. A municipality contracts a case-management system because citizens expect digital services and staff are overwhelmed by paper. A company builds its operations around a suite of tools because the tools integrate well enough and everyone can be trained quickly.
None of these decisions are foolish. In fact, most of them are rational. Organisations do not choose dependence because they enjoy losing control. They choose tools under pressure: budget pressure, time pressure, staff pressure, compliance pressure, public expectation, managerial anxiety, and the simple need to get work done. A platform that works today is hard to resist when the alternative is weeks of evaluation, internal debate, and uncertainty.
Dependence is usually invisible at the moment of adoption. It accumulates slowly. A few workflows are configured. A few templates are created. A few integrations are added. Staff learn where to click. Reports begin to depend on the platform’s categories. Historical data grows inside the system. A manager asks for a custom field. A department creates a workaround. A supplier adds a useful feature. Another tool connects through an API. New staff are trained not in the organisation’s process, but in the platform’s version of the process.
After a while, the tool is no longer simply supporting the organisation. It is describing the organisation back to itself.
This is the invisible rent we pay. It is not only the monthly subscription, the licence renewal, the service contract, or the cloud bill. It is the rent paid in lost optionality. The rent paid in weak documentation. The rent paid in formats that do not travel. The rent paid in staff knowledge that cannot easily transfer elsewhere. The rent paid in data that can be downloaded but not meaningfully reconstructed. The rent paid in decisions shaped by what the platform makes easy rather than what the organisation actually needs.
For individuals, this rent feels personal. The playlists that represent a decade of memory. The phone ecosystem that holds photos, messages, notes, passwords, health data, and family logistics. The e-books that cannot be moved freely. The smart home devices that depend on remote servers. The fitness watch that turns the body into a stream of information, then sells interpretation back to the person who produced it.
For institutions, the rent is structural. A public body may pay for a system to manage permits, benefits, education records, procurement, or citizen requests, only to discover later that the deeper logic of the work now lives in a supplier’s configuration. A small NGO may discover that project evidence, donor history, beneficiary data, and reporting workflows are spread across platforms chosen for convenience rather than care. A company may realise that its apparent productivity stack has become a maze of subscriptions, integrations, and contract renewals that nobody fully sees.
Digital dependence is not only about software. It is about the quiet transfer of control: control over data, formats, repair, rules, knowledge, workflow, memory, and exit.
A person can buy a device and still not control its function. An organisation can pay for a platform and still not govern its own operational memory. A public body can contract a system and still be unable to inspect, adapt, reuse, or replace it without excessive cost. The cage, when there is one, does not always look like a cage. Sometimes it looks like a dashboard.
What lock-in actually means
Vendor lock-in is often discussed as if it were a technical nuisance, something for IT departments to complain about after a bad procurement decision. But lock-in is not simply a technical problem. It is a condition in which leaving becomes expensive, risky, slow, or operationally painful. The product may be good. The vendor may be competent. The platform may be genuinely useful. Lock-in does not require villainy. It only requires dependency without a realistic path out.
A locked-in organisation may technically own its data, but not in a form that can be used elsewhere. It may have a contract that allows export, but only at great cost. It may be able to download records, but not the relationships, rules, templates, workflows, permissions, audit trails, and integrations that make those records meaningful. It may have staff who know the platform well, but not the underlying process well enough to rebuild it. It may have a procurement department that can buy systems, but not evaluate whether those systems preserve future freedom of movement.
Lock-in is not always a locked door. Sometimes it is a room where every exit has a fee.
For individuals, the fee may be emotional and practical: losing years of photos, messages, game worlds, notes, health records, annotations, playlists, or learning progress. For organisations, the fee can be operational: retraining staff, interrupting services, rebuilding integrations, cleaning data, renegotiating contracts, explaining delays to clients or citizens, and accepting months of uncertainty. For public institutions, the fee may become democratic: reduced ability to explain, audit, adapt, or control the infrastructure through which public responsibilities are delivered.
This is why regulators have started to treat portability and switching as more than consumer conveniences. The OECD has described data portability as a way to increase interoperability, stimulate competition, and reduce switching costs and lock-in effects. The EU Data Act, applicable from September 2025, includes measures intended to support access to data and switching between data-processing services, including cloud services. The language may sound legalistic, but the human issue is simple: choice means very little if leaving is technically possible but practically punishing. [1] [2]
A market where people cannot leave is not a fully competitive market. A public service that cannot migrate is not fully governed. A school system that cannot preserve and move learning records is not fully in control of its educational memory. A company that cannot change providers without risking operational collapse is not simply a customer. It is a tenant with expensive furniture bolted to the floor.
The deeper issue is not whether a system is proprietary or open source. There are open systems that create dependence through poor documentation, weak governance, or scarcity of support. There are proprietary systems that provide strong export tools, clear APIs, and honest migration support. The real question is whether people and institutions can understand, govern, repair, adapt, and leave the systems they depend on without losing the substance of their own work.
Open technology matters because it gives us a language for asking these questions before dependence becomes normal.
Buying is not the same as owning
We still carry an older idea of ownership into a world that no longer quite honors it. In the physical world, if we buy a chair, the chair is ours. We can move it, repair it, paint it, lend it, sell it, keep it for decades, or let it become part of the household mythology. The object may wear down, but its use does not usually depend on a remote server, a licence agreement, or a subscription tier.
Digital objects and connected devices are different. A person may buy a smart watch, a heart monitor, a car, a speaker, a television, a home security device, or a printer and still discover that the real functionality depends on software updates, cloud services, account permissions, approved repair channels, and terms of use that can change. The object is physically present, but the authority over its continued usefulness is distributed elsewhere.
This does not mean every subscription is abusive or every cloud service is exploitative. Services cost money. Security updates, infrastructure, customer support, design, and maintenance require resources. But there is a difference between paying for ongoing service and losing practical control over the things that structure one’s life. There is a difference between a fair exchange and a dependency that becomes visible only when the user tries to preserve, move, repair, or understand what they have created.
A person may buy access to a music service and build a library that feels intimate, only to realise that the library is not a library in the old sense. It is a rented arrangement of permissions. A reader may highlight and annotate books inside a platform, but find that the notes do not travel easily. A student may spend years inside a digital learning environment, but the evidence of learning may remain trapped in institutional systems. A family may trust a cloud platform with photographs, comments, facial recognition tags, dates, and albums, but later discover that leaving means dismantling an emotional archive.
The same pattern scales upward. A municipality may buy a system and still not own the workflows that define how public requests move through the administration. A university may buy a learning platform and still not control the data structures that shape academic records. An NGO may pay for a case-management tool and still not be able to extract the full context of beneficiary support, consent histories, risk notes, and reporting logic in a usable form. A company may purchase a customer relationship system and slowly discover that its sales process has become inseparable from one vendor’s architecture.
In each case, the issue is not simply possession. It is meaningful control.
This is why repairability belongs in the same conversation as open source and data portability. The European Union’s right-to-repair directive, adopted in 2024 and due to be applied by Member States from 2026, reflects a growing recognition that sustainable ownership requires the ability to repair goods rather than discard them prematurely. But in a digital society, repair is not only physical. It is also informational and organisational. It means being able to maintain software, recover records, migrate data, document rules, preserve knowledge, and keep systems useful beyond the business plan of a single provider. [3]
The question for the digital age is no longer only “Did we buy it?”
The question is: can we keep using it with dignity, knowledge, and choice?
The institution as a memory system
For organisations, dependency becomes more serious because digital systems do not merely store files. They store memory.
A municipality is not only made of buildings, staff, elected officials, regulations, and budgets. It is also made of procedures, classifications, maps, registries, templates, permissions, archives, financial records, case histories, approval chains, audit logs, and reporting structures. A school is not only classrooms and teachers. It is timetables, attendance records, learning histories, assessment structures, safeguarding notes, parent communications, curriculum materials, and administrative routines. An NGO is not only a mission statement and a team. It is donor history, beneficiary relationships, consent processes, project evidence, volunteer coordination, grant reporting, risk management, and local trust.
All of that increasingly lives inside software.
The platform may begin as a container, but over time it becomes part of how the organisation remembers itself. It shapes what counts as a category, what counts as completed, what counts as a valid request, what counts as evidence, what counts as progress, what counts as a report. It teaches staff what the organisation is by teaching them where to click.
This is why institutional lock-in is not only about data export. Data is essential, but data is not the whole system. A database may contain names, dates, locations, payments, cases, documents, and decisions. But the meaning of those records often depends on rules: workflows, approval chains, legal deadlines, document templates, fee calculations, permissions, notifications, validations, classifications, and status changes.
This hidden layer is sometimes called parametrisation: the configuration of a system so it reflects an organisation’s procedures. It is the difference between a pile of records and a living administrative process. It is also one of the least visible forms of dependency.
A municipality may export a table of licensing processes and still be unable to reconstruct the system that made those processes work. It may have the names and dates, but not the workflow logic, fee rules, approval conditions, audit history, template library, geographic links, notification rules, or reporting categories. The institution has recovered records, but not the living grammar of its own administration.
This is why “Can we download the database?” is an insufficient question. It is like asking whether a city can be preserved by exporting a list of street names. The names matter, but they do not contain the traffic rules, water pipes, property boundaries, bus routes, school catchments, emergency protocols, zoning logic, or memories of how people actually move through the place.
The better questions are deeper. Can we understand the data model? Can we document the rules? Can we export records in usable formats? Can another provider rebuild the interface? Can the institution continue operating if the supplier changes? Can we audit what happened, who did it, and why? Can we separate the organisation’s memory from the supplier’s software?
These are not merely technical questions. They are governance questions. They decide whether an institution remains the author of its own procedures or becomes the operator of someone else’s machinery.
A digital transformation strategy that ignores this layer is not really a strategy. It is a shopping list with a logo.
Open source and the redistribution of possibility
Open source does not automatically solve dependence. We need to say this clearly because romantic narratives are dangerous. An organisation can use open-source tools badly. It can install systems without support, choose immature software because it is fashionable, fail to train staff, neglect backups, ignore security updates, depend entirely on one consultant, or publish code that nobody maintains. An open tool without governance can become another fragile dependency, only with fewer invoices and more confusion.
But when open source is done seriously, it changes the ownership question.
Open source allows inspection. It allows adaptation. It allows reuse. It allows shared maintenance. It can allow more than one provider to support the same system. It can make public investment reusable. It can help institutions build internal knowledge instead of only purchasing access. It does not guarantee freedom, but it creates conditions in which freedom can be organised.
This is the key distinction. Open source is not simply a category of software. It is part of a wider autonomy stack: open standards, open formats, data portability, repairability, documented APIs, interoperability, transparent procurement, reusable public code, local capacity, exit planning, and institutional learning. These are the floorboards beneath digital sovereignty. Without them, sovereignty remains a speech. With them, it begins to become an operating practice.
The point is not that every tool must be open source. That would be too crude. Some closed tools may be appropriate, secure, efficient, and worth paying for. Some open tools may not be ready for a particular context. Organisations need judgement, not purity. The point is that people and institutions should not be trapped inside systems they cannot inspect, adapt, repair, export from, or replace.
Open source does not remove responsibility. It redistributes possibility.
It also changes the relationship with suppliers. In a closed model, a supplier can become irreplaceable by design. In a healthier open model, a supplier remains valuable because it is competent, reliable, responsive, and trusted. People can still be paid. Companies can still build businesses. Developers, trainers, maintainers, cybersecurity experts, designers, hosting providers, and integration specialists can all earn money in open ecosystems. The difference is that value moves away from selling permission and toward providing capability.
That shift is not anti-business. It is anti-captivity.
A good supplier should not need a locked door to keep a client. A good supplier should be chosen because they help the organisation become stronger, not because leaving them would be unbearable.
Public money, public code, public capacity
The public sector makes this question unavoidable. If public money pays for digital infrastructure, should the result become a private box that every municipality, school, or agency must buy again? Or should public investment build reusable capacity?
This is not a romantic question. It is practical. Public institutions often need similar functions: forms, registers, workflows, authentication, payments, notifications, maps, archives, reports, case management, document exchange, citizen portals, and consultation tools. Of course, local needs differ. Legal contexts differ. Procedures differ. Languages differ. But many foundations are shared.
When every public body buys isolated systems that cannot be reused, inspected, or adapted by others, society pays repeatedly for similar work. Worse, it may pay in a way that increases dependency rather than capacity. The same type of public form should not have to be reinvented, repurchased, and reclosed by every municipality. The same basic workflow logic should not have to become proprietary again and again. The same accessibility improvement should not benefit only one administration if public money funded it.
The Free Software Foundation Europe’s “Public Money? Public Code!” campaign expresses this principle directly: software financed by taxpayers and developed for the public sector should be made publicly available under free and open-source licences. One does not have to apply this principle blindly in every possible case to understand its force. The deeper argument is that public digital infrastructure should be designed for reuse, inspection, learning, and accountability. [4]
The Interoperable Europe Act, which entered into force in 2024, points in the same direction from a policy angle. Its aim is to strengthen interoperability across public administrations so that digital public services can function across territorial, sectoral, and organisational boundaries while maintaining sovereignty. That may sound like institutional language, but underneath it lies a simple civic idea: public systems should not become islands. [5]
An island system is expensive. It cannot easily speak to other systems. It is hard to audit. It is difficult to reuse. It traps expertise in narrow channels. It makes every administration solve the same problem separately. It turns public digital transformation into a landscape of disconnected rooms.
Open public code, shared standards, and interoperable architectures do not mean that every public institution must use the same platform. They mean that the foundations should be designed so knowledge can travel. A municipality should be able to learn from another municipality. A school system should be able to reuse publicly funded improvements. A public agency should be able to change provider without losing its operational memory. Citizens should not pay again and again for closed boxes built around common needs.
A government that cannot leave its vendors cannot fully govern its infrastructure.
That is why open technology is not only a developer issue. It is a public-interest issue.
The politics of leaving
Leaving dominant ecosystems is possible, but it is not easy. This must be said without romanticism. Migration is not a weekend project. Serious change requires inventories, pilots, training, communication, documentation, support, budget, leadership, and patience. Staff resistance is real. Compatibility issues are real. Legacy files are real. Procurement constraints are real. Security and continuity risks are real. A careless migration can harm trust, overload staff, interrupt services, and make people understandably hostile to future change.
The German state of Schleswig-Holstein has become one of Europe’s most visible recent examples of this difficult path. After a pilot, the state decided to move around 30,000 government PCs from Microsoft Windows and Microsoft Office toward Linux, LibreOffice, and other free and open-source software, framing the shift around independence, sustainability, security, and digital sovereignty. The significance of this case is not that every administration should copy it immediately. The significance is that it treats leaving as a political and organisational project, not as a symbolic software swap. [6]
This is the part many slogans hide. Digital autonomy is not achieved by announcing a migration. It is achieved through the boring, necessary, human work of making migration survivable: training staff, documenting workflows, testing compatibility, preparing fallback plans, communicating honestly, budgeting for support, and accepting that the first months may be uncomfortable.
But the difficulty of leaving is not an argument against autonomy. It is evidence of why autonomy matters.
If a school, company, NGO, or municipality cannot even imagine leaving a system, then the dependency is already strategic. If the cost of migration is so frightening that no one wants to calculate it, then the organisation should calculate it. Unknown dependency is not safer than known dependency. It is just less visible.
The goal is not to abandon every existing tool immediately. The goal is to stop entering new systems blindly.
Every serious digital decision should include an exit question: how do we leave if we need to?
If there is no answer, the organisation is not buying a tool. It is entering a long-term dependency without a map.
What this means for individuals
For individuals, the first step is not to become extreme. Most people will continue to use mainstream tools. That is normal. A person should not need to be a technician to live with dignity in a digital society. The responsibility cannot be placed entirely on individuals who are already exhausted by passwords, updates, settings, notifications, scams, subscriptions, and devices that ask for attention like needy pets.
But people can ask better questions, and better questions are the beginning of agency.
Can I export my data in a format I can actually use? Can I keep a local copy of what matters? Can this device work without a cloud account? Can it be repaired? Can I move my photos, playlists, notes, contacts, or health records? What happens if I stop paying? What happens if the company closes the service? What does the platform know about me? What would I lose if I left?
These questions do not solve everything, but they change the relationship. They move the user from passive dependence to informed choice. A person may still choose the mainstream service, and that may be the right decision. But the decision becomes more honest when the trade-off is visible. Perhaps the platform is convenient, but the data should be backed up elsewhere. Perhaps the device is useful, but repairability should matter next time. Perhaps the subscription is worth paying, but the user should know whether years of work, memory, or health information can be exported.
Digital awareness is not about refusing convenience. It is about refusing invisible dependence.
We do not need digital purity. We need digital literacy for the systems beneath daily life. We need to know when we are buying a tool, when we are renting access, and when we are slowly building our lives inside a room we may not be able to leave.
What this means for democracy
Digital infrastructure now shapes public life. It shapes how people access services, how schools teach, how municipalities process requests, how public bodies store evidence, how NGOs report impact, how companies organise work, and how citizens interact with institutions.
If these systems are closed, non-interoperable, and impossible to leave, public life becomes dependent on tools that citizens cannot inspect and institutions cannot fully govern. Open technology is not democracy by itself. It does not solve corruption, inequality, bureaucracy, bad design, surveillance, exclusion, or weak institutions. But democratic infrastructure should be inspectable, accountable, reusable, and governable.
A society that cannot understand its digital tools cannot fully understand how it is being administered. A public institution that cannot control its data, rules, and exit path cannot fully control its responsibilities. A community that cannot adapt the systems shaping its participation is being asked to live inside someone else’s assumptions.
This is why tool ownership matters. Not because tools are more important than people, but because tools increasingly shape what people and institutions are able to do.
The question is not only “Which software should we use?”
The deeper question is: who gets to shape the tools that shape public life?
For individual readers, this is the first step: learning to recognise digital dependence before it becomes normal. For organisations, the question becomes more practical and more urgent. Where are we locked in? What would it cost to leave? Which dependencies are acceptable, and which ones are becoming strategic risks? Which systems contain sensitive data, institutional memory, or public responsibility? Which providers are building useful services around our organisation, and which ones have quietly become the owners of our operational memory?
That is where the professional briefing begins.
For individual readers, this is already enough to begin seeing the systems differently. The next time a device asks for an account, a platform promises convenience, a subscription becomes unavoidable, or an export button produces something almost useless, the question changes. We stop asking only, “Does this tool work?” and begin asking, “What does this tool make me depend on?”
That shift matters. Digital autonomy begins with perception.
For organisations, however, perception is only the beginning. A company, school, NGO, municipality, university, funder, or public agency cannot rely on awareness alone. It needs governance. It needs to know where its data lives, which suppliers hold operational power, which contracts are hiding exit costs, which systems contain institutional memory, and which dependencies are acceptable — or quietly becoming strategic risks.
So now we move from civic diagnosis to professional practice.
The next section looks at how organisations can identify and manage digital dependency before it becomes a crisis. We examine dependency as a management risk, the three kinds of lock-in — technical, contractual, and cultural — and the architecture organisations should demand if they want to separate their data, rules, applications, integrations, and audit trails. We also look at procurement questions that protect freedom of movement before a contract is signed, and when open-source alternatives help or fail, in real organisational conditions.
Want the professional briefing and toolkit?
Subscribe to the REDefine newsletter to continue reading the full article and receive future essays, practical resources, and civic technology briefings from The Code Beneath the Floorboards.
