OpenFeature & Feature Flag Governance

The OpenFeature standard for feature flagging, flag lifecycle management, technical debt from long-lived flags, and progressive rollout governance.

Overview

Deploy is not release

Feature flags (feature toggles) let teams deploy code to production without activating it for users, decoupling deployment from release. They are a foundation for trunk-based development, A/B testing, progressive delivery and dark launching. Without governance, flags pile up into technical debt.

OpenFeature: a vendor-neutral API

OpenFeature is an open standard (a CNCF incubating project) that defines a vendor-neutral API for flag evaluation. You code against the OpenFeature SDK instead of a vendor such as LaunchDarkly, Split.io, Unleash or Flagsmith.

> [!TIP] Switching vendors only changes the provider, not the application code: valuable for organizations evaluating or migrating between flag systems.

SDK — Standard evaluation API ("getBooleanValue", "getStringValue", ...) in Go, Java, Node.js, Python, .NET, PHP
Provider — Implements the SDK interface for one backend: LaunchDarkly provider, Unleash provider, in-memory provider for testing
Hooks — Intercept the evaluation lifecycle for logging, tracing and metrics

The accumulation problem

Flags never cleaned up after a full rollout become permanent conditional branches. Each one adds cognitive load for every developer who reads the code.

> [!WARNING] Studies find teams with no flag hygiene policy create flags 10-15x faster than they remove them.

Lifecycle policy

1. Owner and expiry at creation — Every flag has both from day one
2. Automated cleanup ticket — Flags 100% on or 100% off for 30 days trigger one
3. Evaluation metrics — The share of requests evaluating each flag state surfaces stale flags automatically
4. Labeled permanent flags — Kill switches and ops controls are explicitly exempt from expiry

Progressive rollout patterns

Percentage rollout — 1% → 10% → 50% → 100%
Canary — The flag targets only a canary user cohort
Ring deployment — Internal → beta → production
Geographic rollout — US first, then EU

> [!IMPORTANT] Flags plus SLO monitoring enable automatic rollback: if the error rate crosses a threshold at 5% rollout, flip the flag back to 0%.

Key concepts

OpenFeature SDK: CNCF-sandbox vendor-neutral SDK for feature flag evaluation. Available in 8+ languages. Application code evaluates flags via a standard API; the provider implements the backend. Switching vendors requires no application code changes.
Feature flag provider: OpenFeature component that implements flag resolution for a specific backend (LaunchDarkly, Unleash, Flagsmith, environment variables). Swappable without changing evaluation call sites.
Flag lifecycle: Create (with owner, expiry, jira ticket) → gradual rollout → 100% on → cleanup (remove flag + conditional code). Without an explicit lifecycle policy, flags accumulate indefinitely.
Targeting rules: Logic that determines which flag variant to serve based on context (user ID, email domain, geography, plan tier). Enables percentage rollouts, beta programs, and canary releases without code changes.
Kill switch: A permanent-intent feature flag designed to disable a feature quickly in production without a deployment. Labeled explicitly as long-lived and exempt from expiry policies.
Dark launch: Running new code in production without exposing the results to users — useful for load testing new infrastructure, validating correctness of shadow path, or warming caches before a feature launch.

When to use it

Designing progressive rollout systems for new features without requiring separate deployment pipelines
Evaluating or migrating between feature flag vendors (LaunchDarkly, Unleash, Split)
Building a flag governance policy to prevent flag accumulation and technical debt
Interview questions about decoupling deployment from release, dark launches, and A/B testing infrastructure
Implementing kill switches for critical features without requiring a deployment

Interview questions

How do you design a feature flag governance policy for a 200-engineer organization?