Open specs vs. vendor lock-in: how to actually evaluate a platform decision

Every vendor calls their platform "open." Almost none of them mean the same thing by it. Before a platform decision gets made, it's worth having an actual test for telling a real open specification from marketing language borrowed from one.

The test

A real open specification has three things: an independent governing body that isn't controlled by one company, a public spec document that anyone can read without a sales call, and more than one interoperable implementation built by parties who didn't have to ask each other's permission. The practical version of the test is simple: could a second vendor build a competing product against this same interface tomorrow, legally and technically, with nothing but the public docs? If yes, it's open. If the honest answer involves a partnership agreement, a reverse-engineered client, or "well, technically," it isn't.

By that test, Kubernetes' API, OAuth2 and OpenID Connect, SAML, SQL, OpenTelemetry, and OPA's Rego policy language all pass. Each has a standards body behind it (the CNCF, the IETF, the OpenID Foundation, OASIS, ISO/ANSI), a public spec, and multiple independent implementations that didn't need any single vendor's blessing to exist.

What doesn't count, even when the word "open" is on the box

• A proprietary API with an open-looking SDK bolted on top. The SDK being open source doesn't make the service underneath it a spec. If only one vendor's servers speak the protocol, the protocol isn't open, the client library is.
• "Open core" products. The free tier runs on genuinely open code, but the feature your team actually needs lives behind a paywall in the closed half. That's a pricing strategy wearing an open-source badge.
• A managed offering of a real standard, with proprietary extensions that become load-bearing. A managed Kubernetes service is fine, the API underneath is the real spec. The risk shows up later, when a team quietly starts depending on that vendor's proprietary autoscaler, ingress controller, or policy layer that has no equivalent anywhere else, and the workload is no longer portable even though the orchestration layer technically still is.

Why it actually matters, not just as a principle

• Migration cost. A system built against OIDC can swap a self-hosted Keycloak for a managed identity provider, or the reverse, without rewriting how every service authenticates. A system built against a vendor's proprietary SSO API can't; every integration point has to be touched.
• Hiring and onboarding. An engineer who already knows OAuth2 or SQL is productive on day one. An engineer who has to learn one vendor's proprietary dashboard and query language first is productive whenever that vendor's specific onboarding gets finished.
• Negotiating leverage. When the interface is portable, a vendor's pricing change or a sunset announcement is an annoyance, not an emergency. The team can move, and the vendor knows it, which changes the conversation before it ever needs to happen.
• Auditability. A compliance or security review can check a system's behavior against a public spec document. It can't meaningfully audit a vendor's undocumented internal behavior; it can only trust the vendor's own claims about it.

Where this shows up in a typical stack

• Identity: OAuth2, OIDC, and SAML over a vendor-proprietary SSO integration.
• Data: SQL over a proprietary query language, even when the proprietary one is genuinely faster for one specific workload.
• Observability: OpenTelemetry over a vendor-only agent that only exports to that vendor's own backend.
• Policy enforcement: OPA's Rego over a cloud provider's built-in policy engine that only runs on that provider's platform.
• Orchestration: the Kubernetes API over a proprietary container platform that predates it or competes with it.

It isn't always a binary choice

None of this means the open option always wins. Sometimes the pragmatic call is a proprietary layer, and the real question is which layer in the stack stays open underneath it.

Take container orchestration. AWS's Elastic Container Service is proprietary: there's no other vendor that runs an ECS task definition, and nothing about it is a published standard. For a team starting out, ECS is still very often the right call. It's simpler to operate than a real Kubernetes cluster, has fewer moving parts, and gets a small team shipping without taking on a platform team's worth of operational overhead. Picking it isn't a violation of the framework above, it's a case where the open interface moved down a layer instead of disappearing. The container itself, built to the OCI image spec, is still open. An image built to run on ECS runs unmodified on Kubernetes, on Cloud Run, or on a laptop with Docker installed. What's proprietary is the orchestration layer sitting on top of that image, not the workload itself.

That's the more precise version of the test: not "is every layer of this stack open," but "is the layer my team's actual work product lives in portable." Application code and container images are usually worth keeping open, because that's what has to move if a vendor relationship ends. The orchestration layer on top is often the cheapest one to end up locked into, since migrating off it usually means changing how workloads get scheduled and deployed, not rewriting the workloads themselves, and that's a real, bounded cost rather than an open-ended one.

What this doesn't mean

It doesn't mean avoid vendors, or avoid managed services. A managed control plane built on a real open spec is very often the right call, since it gets the operational convenience without giving up the portability underneath it. The question isn't whether a vendor is involved. It's whether, if that vendor disappeared or doubled their price tomorrow, the system could move to a different implementation without rewriting how its pieces talk to each other. If the answer is yes, it's safe to build on. If the answer is no, that's the lock-in, whether or not the vendor's marketing calls it open.