There is a sophisticated mechanism by which proprietary technology ecosystems maintain their grip on users and institutions, even when those users and institutions believe they are making free choices, using open standards, and building independent digital infrastructure.
The mechanism does not work through force, but through a subtler and more durable strategy: the layering of dependencies, in which each layer obscures the one beneath it, so that when the system fails the apparent cause is something other than the real one.
It is a structural pattern with identifiable components and predictable failure modes, and with a single political consequence: the systematic attribution of interoperability failures to open alternatives rather than to the proprietary dependencies that actually cause them.
Understanding all of this is essential for anyone working on a genuine interoperability policy, because without it even the best-intentioned policy interventions address the visible symptom while leaving untouched the larger problem of the underlying architecture, which goes on working exactly as designed.
The perception of malfunction
Let us start from the user’s experience, because this is where the political damage occurs.
A document is created in Microsoft Word and sent to a colleague who uses LibreOffice on a Linux desktop. The colleague opens the file. Something is wrong: a table has shifted, the text has reflowed, a font looks different, the page breaks have moved.
The experience is familiar to millions of people in institutional settings that have adopted, or are considering adopting, open source software. It is the experience that generates the helpdesk tickets, the emails of pure frustration to the IT department, the conversations that end with “can you just send me a PDF?”, and the broader sentiment, consolidating over time, that open source software is not ready for professional use.
What is the cause of this failure? Users will blame LibreOffice, IT managers will blame format incompatibility, policymakers will blame the immaturity of open standards.
These are all wrong answers. Or rather, they are all answers to the wrong question, because they describe where the failure manifests rather than where it originates.
The actual cause is a set of interdependent technical systems, each contributing a different failure mode, all producing a single visible result.
The format contains proprietary structures that only Microsoft’s implementation handles correctly. The rendering introduces platform-dependent variations that the format specification does not control. The proprietary fonts cannot be legally bundled with open source software.
Three distinct failure modes producing the same symptom, and equally invisible to the user, who perceives only that things worked in Word and do not work in LibreOffice.
This is the architecture of layered dependency. Each layer absorbs the causal chain and emits a different signal, one that points toward the open alternative.

Layer One: the format and its hidden features
The first layer is the most discussed and the most politically visible: the document format. The conflict between ODF and OOXML has been extensively documented, litigated within standards bodies, and debated in national parliaments and in the …