I. The Decision That Does Not Look Like a Decision
Picture the moment as it usually happens. A team is standing up a new service. They need a database, a queue, a search engine, a managed cache, a vendor SDK that handles some specialized concern. Someone runs a comparison: features, pricing, documentation quality, integration ease, time-to-first-result. A managed proprietary service wins on most of the axes that matter at that moment. The team picks it. The contract is signed. The service is in production within the week.
Nobody at the table thinks of this as an architectural decision. It feels procurement-shaped. The company already has procurement processes for this kind of thing — vendor risk review, security questionnaire, legal sign-off, line item in the cloud bill. A box gets checked. Work continues.
This is the failure. Not the choice itself — sometimes the choice is correct, sometimes it is not — but the category it has been sorted into. What was treated as a procurement decision was an architectural commitment. The team just bought a future rewrite. They do not yet know its size, its date, its trigger, or its cost. They will find out later, on a schedule chosen by the counterparty.
The argument of this essay is that vendor lock-in is the most common form of architectural failure in modern software, and the least often recognized as such. It does not crash production. It does not appear in post-mortems. It does not show up on dashboards. It accumulates silently over years, compounds quietly, and becomes visible only at the moment when leaving costs more than staying — at which point the choice is no longer architectural. The discipline of open source first, properly understood, is not an ideological preference. It is the engineering decision to keep the cost of changing one's mind bounded by one's own capacity rather than by a counterparty's willingness.
II. The Anatomy of Lock-in: How Coupling Accumulates
To see lock-in clearly, it helps to stop thinking about it as a single thing — a bad license, a sticky vendor — and start thinking of it as a layered phenomenon that compounds. Every proprietary dependency couples a system to a counterparty across at least five distinct dimensions, each of which raises the eventual cost of leaving.
The first is surface coupling: application code that calls vendor-specific APIs. This is the visible layer — the imports, the SDK initializations, the configuration patterns that assume a particular vendor's idioms. It is also the easiest layer to refactor, which is why it gets disproportionate attention and disproportionately understates the real lock-in.
The second is data coupling: data living in proprietary formats, schemas, or stores with no neutral export path. This is the deepest layer of lock-in, because data outlives every other component. Code can be rewritten in a quarter. Operational tooling can be rebuilt in a year. Data accumulated over five years of business operations cannot be wished into a different format. A proprietary data format is a long-duration commitment whether the team understood it that way at procurement time or not.
The third is operational coupling: runbooks, monitoring patterns, deployment pipelines, on-call procedures, and disaster-recovery practices that all assume the vendor's tooling. This layer is invisible to the procurement decision because it does not exist yet at procurement time. It accrues through years of operating the system. By the time it is substantial, it is also institutional knowledge — distributed across many people, documented incompletely, and difficult to relocate.
The fourth is skills coupling: team expertise specialized in the vendor's product rather than in the underlying concepts. An engineer who has spent three years mastering a particular cloud provider's identity-and-access management model has learned a great deal — much of it transferable to other systems, some of it not. The non-transferable portion is, in expected-value terms, an investment in the continued relationship with that vendor. When the relationship terminates, that portion of the skill investment terminates with it.
The fifth is integration coupling: second-order systems built on the assumption that the vendor will continue to exist and behave as expected. Reporting systems that read from the vendor's data warehouse. Identity systems that federate with the vendor's IAM. Billing reconciliation that depends on the vendor's invoice format. Each of these is a separate piece of work to redo if the vendor relationship ends, and each was built without any explicit accounting of the dependency it introduced.
None of these layers is visible at procurement time. All of them compound silently. By the time the cost of leaving is large enough to be noticed, the team is already deep inside it. This is the architectural shape of lock-in: a series of coupling decisions, each individually small, each individually defensible, accumulating into a system property — exit cost — that nobody designed and nobody owns.
III. Why "Best Tool for the Job" Is the Wrong Frame
The dominant decision criterion in engineering culture, when choosing dependencies, is best tool for the job. Pick the database that fits the workload. Pick the queue that fits the throughput. Pick the SDK that fits the use case. This criterion is correct at the level of the individual decision and incomplete at the level of the system.
The incompleteness shows up as follows. Best tool for the job, applied dependency by dependency over the lifetime of a system, produces a system whose total exit cost is the sum of every individual lock-in, taken jointly. Each decision was locally optimal. The aggregate is globally fragile. This is a classic systems-thinking failure: the assumption that good local decisions compose into a good global outcome, when in fact the system property that matters — in this case, optionality — is emergent and is precisely the property nobody was tracking.
Donella Meadows formalized this distinction in Thinking in Systems: a system's behavior is determined by its structure, not by the quality of its individual components, and an obsession with component-level optimization while ignoring structural properties produces predictable failure modes [1]. The structural property at stake here has a name in finance — optionality — and it is worth borrowing the term because it captures something engineering vocabulary tends to miss. Optionality is the value of being able to make a different choice later. It does not show up on a feature comparison sheet. It does not appear on a procurement spreadsheet. It is invisible until the day it becomes the only thing that matters.
Open-source dependencies do not eliminate exit cost. They make it possible to bound exit cost by the team's own engineering capacity. The work of leaving an open-source dependency is large, but the work is yours, internal, visible to your engineers, and executable on your schedule. The work of leaving a proprietary dependency is whatever the vendor decides it is on the day you finally try. These are not differences of degree. They are categorically different risk profiles.
The architecturally correct frame, then, is not "best tool for the job." It is best tool for the job, weighted by exit cost, considered jointly across all dependencies. Most teams do not work this way. Most teams cannot, because the second clause requires modeling something the procurement process does not surface and the dashboard does not measure. This is the work that systems thinking demands and that the everyday rhythm of engineering tends to skip.
IV. Lock-in Cashing In: A Recent Empirical Record
The argument above is theoretical. The last several years have produced a sequence of natural experiments in vendor relicensing that make the same argument in concrete terms. They are worth examining in detail, because the pattern is more consistent than any individual story.
In January 2021, Elastic announced that Elasticsearch and Kibana — both previously distributed under the Apache 2.0 license — would be relicensed under a dual model combining the proprietary Elastic License and the Server Side Public License (SSPL), neither of which the Open Source Initiative recognizes as open source [2]. Elastic stated the change was intended to prevent cloud providers from offering Elasticsearch as a managed service without commercial agreement. Within weeks, Amazon Web Services forked the last Apache-licensed version of Elasticsearch into OpenSearch and continued development under the original terms. Three years later, in August 2024, Elastic added AGPLv3 — an OSI-approved open-source license — back as a third option, with founder Shay Banon publicly framing the move as a return to open source [3]. Industry observers noted what the Elastic data already showed: many of the customers who had migrated to OpenSearch in 2021 were not coming back. Trust, once spent, is not cheap to rebuild.
In August 2023, HashiCorp announced that Terraform and its other core products would move from the Mozilla Public License 2.0 to the Business Source License (BUSL) 1.1 [4]. BUSL is a source-available license, not an open-source license; it permits most internal use but restricts the ability of third parties to offer competing managed services. Within two weeks, a coalition of companies whose business depended on Terraform — Spacelift, Gruntwork, Harness, env0, Scalr, and others — published the OpenTF Manifesto requesting reversal, and when none came, they forked the last MPL-licensed version of Terraform. The fork, renamed OpenTofu, was accepted by the Linux Foundation on September 20, 2023 [5]. By 2025, HashiCorp had been acquired by IBM, and a separate announcement clarified that even continued use of the BUSL-licensed Terraform community edition would be discontinued under that arrangement after July 2025 [6] — meaning that customers who had accepted the original BUSL transition under the assumption of continuity faced a second forced migration within two years.
In March 2024, Redis Ltd. moved the Redis project from the permissive BSD-3-Clause license — the license under which it had operated for fifteen years — to a dual-license model combining SSPL and the Redis Source Available License (RSALv2) [7]. The Linux Foundation announced Valkey, a BSD-licensed fork of the last open-source Redis version, on April 1, 2024, with founding backing from AWS, Google Cloud, Oracle, Ericsson, and Snap. Within months, a large fraction of Redis-using enterprises had begun migration: a Percona survey reported in late 2024 that 83% of large enterprises using Redis had adopted or were actively evaluating Valkey [8]. In May 2025, fourteen months after the original relicensing, Redis Ltd. announced Redis 8 with AGPLv3 added as a third license option — an explicit reversal of the strategic direction that had triggered the fork [9]. By that point, the major cloud providers had launched Valkey-based managed services (AWS ElastiCache for Valkey, Google Memorystore Valkey, Azure Cache for Valkey support), and the architectural question for new deployments had effectively shifted from Redis or alternative? to which Redis-compatible store?
These three cases are not isolated. They follow MongoDB's earlier 2018 transition to SSPL, which established the pattern, and they are bracketed by other moves — CockroachDB, Sentry, Confluent — operating on similar logic. The aggregate pattern is unambiguous. A vendor that holds the license to a dependency you depend on can, and sometimes will, change the terms of the relationship unilaterally. The triggers vary — competitive pressure from cloud providers, public-market pressure for revenue growth, acquisition events that change strategic priorities — but the customer's experience is structurally identical: the dependency you signed up for is no longer the dependency you have. Your options reduce to accept the new terms, migrate, or rewrite, on a schedule the vendor controls.
The two reversals in this sequence — Elastic and Redis returning to OSI-approved licenses after sustained competitive pressure from forks — deserve specific attention. They demonstrate the optionality argument with unusual clarity. The customers who had migrated to OpenSearch and Valkey did not need to migrate again. The customers who had stayed on the proprietary path had now experienced two relicensing events within a span of years. The architectural lesson is not that the vendor was right or wrong to relicense; the architectural lesson is that being subject to the licensing decision at all turned out to be the cost. Customers whose architectures had bounded that exposure — through abstraction, through data portability, through forkable dependencies — paid the cost of vigilance and were largely insulated. Customers whose architectures had not paid the cost of repeated, non-optional migrations.
This is what slow architectural failure looks like. The decisions that produced these outcomes were made years before the trigger. At the time they were made, they did not look like architectural decisions. They looked like reasonable choices among similar-seeming options, scored on the criteria visible at procurement time. The criterion that turned out to matter — exit cost when the relationship changes terms — was not on the comparison sheet.
V. Open Source Is Not Free; It Is a Different Cost Structure
The argument so far would be incomplete without honest treatment of the counter-position, because the counter-position has real force.
Open source is not free. The marketing slogan "free as in beer, free as in freedom" obscures more than it clarifies. What open source actually does is shift cost — from licensing to operations, from external invoice to internal payroll, from contractually-bounded vendor obligation to internally-bounded engineering capacity. The team running its own Postgres cluster pays in expertise, on-call burden, capacity planning, backup and restore engineering, performance tuning, and the irreducible time that operating production data infrastructure consumes. The team paying for a managed proprietary equivalent pays in invoice. Both are real costs. Neither is zero. The honest comparison is not free-versus-paid. It is which cost structure does the architecture prefer over a multi-year horizon, given the team's capacity and the system's optionality requirements?
For some teams, in some situations, the proprietary managed offering is correctly chosen. A small team with high product velocity and low operational expertise may rationally pay an external invoice rather than acquire the internal capacity to run a database well. The argument of this essay is not that this is wrong. The argument is that this decision should be made as an architectural decision, with explicit understanding of what is being purchased — operational simplicity now, in exchange for exit-cost exposure later — rather than as a procurement decision with no accounting for the second half of the trade.
There is also an honest middle ground that the dichotomy can obscure. Managed open source — running your workload on a managed service that is itself an open-source project, with neutral governance and a viable migration path to self-hosting — is structurally different from managed proprietary. The cost of leaving the former is bounded by your engineering capacity; the cost of leaving the latter is bounded by the vendor's willingness. The two should not be conflated. A managed Postgres offering on a major cloud provider is not the same architectural commitment as a proprietary database running on the same provider, even if the operational experience feels similar at the procurement-decision moment.
The discipline this demands is not absolutism. It is honesty about what each dependency commits the system to and on what time horizon. A team that can articulate, for every critical dependency, what it would take to leave — and that has actually written that down somewhere — is doing architecture. A team that cannot has an arrangement of components, no matter how sophisticated each component is.
VI. The Architectural Discipline: Designing for Exit
The constructive form of the argument is that designing for exit is a discipline, not a slogan, and it has identifiable practices. None of these practices is novel; what is uncommon is treating them as part of the architecture rather than as something to consider after the fact.
Treat every dependency choice as an architectural decision. This means writing it down. It means documenting, at the moment of selection, what the dependency is for, what its known alternatives are, what would trigger a migration, and what the rough cost of migrating would be. Most teams do not do this, and the absence of the document is itself the failure. A dependency without a documented architectural rationale is a dependency without an architectural owner, which is a dependency the system has imported the risk of without the corresponding deliberation.
Isolate proprietary dependencies behind interfaces you own. If a vendor SDK must be used, wrap it. The application code should call your interface; your interface should call the vendor. This containment limits surface coupling to a small, well-defined set of files. It will feel like overhead at the time of writing. It is the cheapest insurance available against the day you discover you need to swap the vendor out.
Keep data in open formats, even when the runtime is proprietary. Data outlives runtimes. A proprietary data format is the deepest lock-in available, because it commits the system to keeping the runtime around for as long as the data is needed — which is usually longer than the team plans to keep the runtime around. Whenever a choice is available between a proprietary data format and a neutral one (Parquet, JSON, Avro, plain SQL with portable types, etc.), the neutral format should be preferred even at some operational cost. The data is the asset; the runtime is the consumable.
Maintain a written exit plan for every critical dependency, even if you never execute it. The plan does not need to be detailed. It needs to exist. Its function is diagnostic: the act of writing it surfaces the parts of the dependency you do not actually understand, the second-order systems you had not realized depended on it, and the migration paths that turn out to be impossible. A team that cannot write a credible exit plan for a dependency does not understand the dependency. That is useful information, available at zero cost, on demand.
Prefer dependencies whose interfaces are standardized or trivially reimplementable. Standards exist for this exact reason. SQL, S3-compatible object storage, OAuth, OpenTelemetry — these are not features; they are escape paths. A dependency that conforms to a standard is one whose replacement exists in principle. A dependency with a unique proprietary interface is a dependency whose replacement does not exist until somebody builds it, which is a different kind of risk.
Recognize that "open source" alone is not a guarantee. The Redis-to-Valkey transition succeeded because the project was forkable: an OSI-approved license, a community of contributors, neutral or potentially-neutral governance. Not every project marked "open source" has those properties. Single-vendor projects with copyright assignment policies and centralized governance retain most of the lock-in dynamics of fully proprietary projects, because the entity that controls the project can change the license. The architectural property that matters is not the current license — it is whether the project is forkable in practice if the license changes. That property comes from license choice, governance structure, and contributor diversity, not from the marketing.
These practices are not exotic. Most experienced engineers can recite them. The question is not whether they are known but whether they are applied as architecture — as part of the deliberation that produces the system, rather than as advice consulted after a problem has already occurred. A team that applies these practices consistently will, over years, build a system whose exit costs are bounded and whose optionality is preserved. A team that does not will build a system whose exit costs grow silently and whose optionality is gradually consumed, until the day arrives when there is none left to spend.
VII. The Asset Is the Optionality
Vendor lock-in is the architectural failure that does not look like one. It does not produce a single visible event that the team can point to and learn from. There is no incident report titled "we became dependent on a vendor that later changed terms." The failure is distributed across hundreds of small decisions, each made for a defensible local reason, each contributing a small increment to a system property nobody was tracking. The arrival of the consequence is delayed by years from the decisions that produced it, which is exactly the timing structure that prevents organizational learning.
The discipline of open source first, as a practical matter, is not a moral commitment to particular licenses. It is the recognition that every dependency is a coupling, that every coupling has an exit cost, and that the structurally robust position is the one in which exit cost is bounded by your own capacity rather than by a counterparty's discretion. This is an architectural principle, not an ideological one, and it is justifiable on the same grounds as any other architectural principle: it produces systems that survive their environment over a longer time horizon.
The dependencies are not the asset. The optionality is. A system whose architecture preserves the freedom to choose differently later is a system that can adapt to whatever its environment becomes — vendor relicensing, acquisition, price escalation, deprecation, regulatory change, strategic pivot. A system that has spent its optionality on short-term convenience can adapt only to the futures its remaining counterparties will permit. The first kind of system ages well. The second kind ages into a forced migration whose timing is decided elsewhere.
Every proprietary dependency really is a future rewrite. The only open question is when, on whose terms, and at what price. Knowing how things work — how the dependency is structured, what alternatives exist, what the migration path looks like, what would trigger the need to take it — is what allows that question to be answered on the architect's schedule rather than the vendor's. It is also what makes open source first the engineering discipline it actually is, rather than the ideological position it is sometimes mistaken for.
References
[1] Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing. ISBN: 978-1-60358-055-7.
[2] Elastic (2021). Doubling Down on Open, Part II. (License change announcement, January 2021.) Background and FAQ: https://www.elastic.co/pricing/faq/licensing
[3] Elastic (2024). Elasticsearch is Open Source, Again. (AGPLv3 addition announcement, August 29, 2024.) Industry analysis: InfoQ, "Elastic Returns to Open Source: Will the Community Follow?" https://www.infoq.com/news/2024/09/elastic-open-source-agpl/
[4] HashiCorp (2023). HashiCorp adopts Business Source License. (License change announcement, August 10, 2023.) Background: Wikipedia, "Business Source License." https://en.wikipedia.org/wiki/Business_Source_License
[5] OpenTofu (2023). OpenTofu Announces Fork of Terraform. (Fork announcement, August 25, 2023; Linux Foundation acceptance, September 20, 2023.) https://opentofu.org/blog/opentofu-announces-fork-of-terraform/
[6] ControlMonkey (2026). Terraform License Change: Impacting IaC Teams in 2026. (Includes timeline of HashiCorp license change and IBM acquisition, with discontinuation date for Terraform OSS under BUSL.) https://controlmonkey.io/resource/terraform-license-change-impact-2025/
[7] Redis (2024). Redis Adopts Dual Source-Available Licensing. (License change announcement, March 20, 2024.) Background and license analysis: https://redis.io/blog/agplv3/
[8] Cited in: Techzine (2025). "Redis returns to open source after damaging community relationship." Reporting Percona's 2024 enterprise survey. https://www.techzine.eu/news/infrastructure/131056/redis-returns-to-open-source-after-damaging-community-relationship/
[9] Redis (2025). Redis is now available under the AGPLv3 open source license. (Redis 8 release, May 2025.) https://redis.io/blog/agplv3/ — Industry analysis: The Register, "Redis 'returns' to open source with AGPL license." https://www.theregister.com/2025/05/01/redis_returns_to_open_source/