Skip to content

SYSTEM Cited by 1 source

OpenFeature

OpenFeature (openfeature.dev) is the CNCF open standard for feature flag evaluation — a vendor-neutral API surface that decouples evaluation-call sites in application code from the specific flag provider underneath.

Role on this wiki

The reference for OpenFeature on the wiki is Cloudflare Flagship's 2026-04-17 launch, which is built as an OpenFeature Provider from day one. The launch post frames the standard's value explicitly:

"OpenFeature defines a common interface for flag evaluation across languages and providers — it's the same relationship that OpenTelemetry has to observability. You write your evaluation code once against the standard, and swap providers by changing a single line of configuration."

That's the canonical wiki framing of a vendor-neutral evaluation API — define the call surface as a standard, let each backend plug in as a provider.

Shape of the interface (as used by Flagship)

Server-side pattern (from the Flagship launch post):

import { OpenFeature } from '@openfeature/server-sdk';
import { FlagshipServerProvider } from '@cloudflare/flagship/server';

await OpenFeature.setProviderAndWait(
  new FlagshipServerProvider({ /* … provider config … */ })
);

const client = OpenFeature.getClient();
const showNewCheckout = await client.getBooleanValue(
  'new-checkout-flow',
  false,
  { targetingKey: 'user-42', plan: 'enterprise', country: 'US' }
);

Key surface points:

  • OpenFeature.setProviderAndWait(...) — install a provider once; evaluation-call sites never change when swapping providers.
  • getBooleanValue / getStringValue / getNumberValue / getObjectValue — typed accessors across all variation types.
  • Evaluation context is a structured record (targetingKey, plus arbitrary attributes) the provider matches against rules.

Why "OpenTelemetry for observability" is the right analogue

Both standards solve the same structural problem — teams instrument once against a stable API; vendors compete on the provider-side implementation. The post's framing positions OpenFeature at the API-standard tier, not the product tier. For Flagship specifically: "Adopt Flagship without rewriting your evaluation code. Leave without rewriting it either." — opting into OpenFeature is opting into zero-switching-cost adoption, the same posture AI Gateway-style provider abstractions take at the inference tier.

Caveats

  • Raw capture of OpenFeature internals (spec version, hook model, evaluation-API details, client-vs-server subtleties) is not in the launch post — what's on this wiki is OpenFeature as consumed by Flagship. Independent OpenFeature-first source posts would let this page deepen.
  • The "one line of config" vendor-swap claim is provider- dependent — rule schemas and context-attribute conventions can differ across backends even if the evaluation-call API is stable.

Seen in

Last updated · 200 distilled / 1,178 read