OpenFeature: swap your feature-flag vendor in one line
Evaluation API, providers, hooks, LaunchDarkly migration, CNCF incubating spec
The renewal quote landed in March and the flag vendor wanted roughly triple. Not for new capabilities - for the same targeting rules and the same dashboard, priced against a seat count that had grown while nobody watched. The team I was advising did the estimate everyone does at that point: how much to move off? Someone grepped the codebase. Eleven hundred call sites, every one of them importing the vendor's SDK directly, some of them consuming vendor-specific context objects three layers deep in business logic. The migration priced out at two quarters of platform work. They paid the invoice.
That grep result is the exact thing OpenFeature exists to prevent. I gave it one section in a grab-bag issue a while back - issue #012 - and the pitch back then was "OpenTelemetry, but for feature flags." That's still the right one-liner. What I want to do here is walk the actual architecture, because whether the promise holds depends entirely on where the seam sits.
Three pieces, one seam
The spec splits flag evaluation into three parts, and the split is the whole product.
The Evaluation API is what your code touches: getBooleanValue("new-checkout", false, ctx) and its friends for strings, numbers and objects. It belongs to OpenFeature, not to any vendor. Those eleven hundred call sites, written against this API, contain zero vendor imports.
The provider is the adapter that speaks one vendor's protocol - LaunchDarkly, Flagsmith, PostHog, a JSON file on disk, your own homegrown service. It's registered once, at startup. This line is the only place a vendor name appears in the application, which is why switching backends is a one-line diff plus a config migration, instead of two quarters.
Hooks wrap every evaluation with before/after/error stages. Access logging, OpenTelemetry spans per flag check, validation that a flag actually exists before you bet a request on it - all of it lands in one place instead of being sprinkled across call sites. Teams underuse these badly; a hook that emits an event on every evaluation is how you find the flags nobody has toggled in a year.
The context object rounds it out: user key, region, plan tier, whatever your targeting rules segment on, passed in a standard shape so the provider translates it rather than your code adapting to the provider.
What it doesn't do
Fair's fair: OpenFeature standardizes evaluation, not management. There's no standard API for creating flags, wiring targeting rules or archiving stale ones - that stays in each vendor's dashboard and each vendor's Terraform provider, and moving those rules between systems is still real migration work. The one-line swap covers your application code, which is the part that used to be unmovable. The rules move by hand.
The ecosystem question also answers itself these days: the project is CNCF incubating, SDKs cover the mainstream server and client stacks, and the official provider registry lists 30-plus backends including every vendor whose renewal quote might one day surprise you. When the big flag vendors all maintain providers for the abstraction layer that makes leaving them easy, the standard has won the argument.
The migration that convinced me
The pattern I've now seen work: wrap the current vendor first, migrate nothing. Every new flag check goes through OpenFeature backed by the existing provider; old call sites get converted opportunistically, whenever a file is already open for other reasons. Six months later the vendor import count is near zero and the company has options it didn't have - including the boring option of staying, but negotiating with a grep result that says leaving costs a sprint instead of two quarters.
Flags are infrastructure with a pricing model attached. Infrastructure with a pricing model attached is exactly the place to keep an exit visible.
Links
- Ilia