What Is OpenFeature? Architecture, Providers and Vendor Portability

Foundation 3

Imagine that an organization has hundreds of applications using feature flags. Some are frontend applications, some are backend services, some are serverless workloads, and some are mobile applications.

If each application calls a vendor specific SDK directly, the code can begin to look like this:

Application
   ↓
Vendor SDK
   ↓
Vendor feature platform

That works. But the feature management vendor has now become part of the application's programming model.

OpenFeature introduces a standard API between application code and the feature management provider.

Application
   ↓
OpenFeature API
   ↓
Provider
   ↓
Feature management platform

OpenFeature is an open specification under the Cloud Native Computing Foundation. It is not another hosted feature flag dashboard, and it does not store your flags. Its job is to standardize how software asks for feature flag values.

The shortest useful definition

OpenFeature is a vendor neutral API for feature flag evaluation.

Your application asks OpenFeature for a value. A provider connects OpenFeature to the actual feature management system.

What a provider does

The provider is the adapter between the standard API and the vendor implementation.

Application
     │
     ▼
 OpenFeature
     │
     ▼
   Provider
     │
     ├─ Datadog
     ├─ LaunchDarkly
     ├─ Harness
     ├─ Unleash
     └─ another compatible system

Application developers can use a consistent evaluation API even though the provider underneath may change.

A Boolean example

Conceptually, application code asks for a typed value and supplies a default:

enabled = client.getBooleanValue(
  "new-checkout",
  false,
  context
)

The application is interested in three things:

the flag key: new-checkout
the fallback value: false
the evaluation context used to make the decision

The application does not need to embed the vendor's dashboard model into every call.

OpenFeature supports typed values

Feature management is not limited to Boolean values. The OpenFeature specification defines typed evaluation for values such as:

Boolean
string
number
object or structured value

This matters as feature management grows into runtime configuration.

new-checkout = true
search-model = "semantic-v3"
timeout = 2500
configuration = { ... }

What is evaluation context?

A feature decision often needs information about the current request or user.

userId = 84217
region = "US"
accountType = "enterprise"
appVersion = "8.3"

OpenFeature calls this information evaluation context. The provider can pass the relevant context to the underlying feature system, which applies its targeting rules.

request context
     ↓
OpenFeature evaluation context
     ↓
provider
     ↓
targeting rules
     ↓
resolved variation

This also creates a responsibility: evaluation context can contain sensitive information. Applications should pass only what the targeting decision actually needs, and organizations should understand where that data is evaluated and transmitted.

Hooks provide extension points

OpenFeature also defines hooks around flag evaluation. Hooks can support cross cutting behavior such as telemetry, logging or additional context processing.

Conceptually:

before evaluation
      ↓
resolve flag
      ↓
after evaluation
      ↓
telemetry or other hook behavior

This is useful because feature evaluation often needs to participate in observability and experimentation without every application team inventing a different integration pattern.

Why people compare OpenFeature with OpenTelemetry

The comparison is useful, but it should not be taken too literally.

	OpenTelemetry	OpenFeature
Primary purpose	Standardize telemetry instrumentation	Standardize feature evaluation
Application direction	Application emits signals	Application consumes decisions
Vendor connection	Exporter or collector ecosystem	Provider ecosystem
Replaces vendor platform?	No	No

The architectural similarity is that both create a vendor neutral layer at an important application boundary.

What OpenFeature does not provide

This is where the distinction is most important.

OpenFeature does not give you:

a management dashboard
flag storage
targeting rules
percentage rollout infrastructure
experimentation statistics
production health monitoring
approval workflows
audit history

Those capabilities still come from a feature management platform.

CONTROL PLANE
Datadog / LaunchDarkly / Harness / Unleash / another system
                       │
                       ▼
                    Provider
                       │
───────────────────────┼───────────────────────
                       │
APPLICATION            ▼
                  OpenFeature API
                       │
                       ▼
               application behavior

Does OpenFeature eliminate vendor lock in?

It can reduce code level coupling, but it does not make every feature management platform interchangeable.

Suppose an application uses only common capabilities:

Boolean evaluation
typed variants
standard evaluation context

Moving between providers can be much easier because application code is written against OpenFeature.

But an organization may also depend on vendor specific capabilities such as:

specialized experimentation models
automatic release guardrails
proprietary targeting constructs
vendor specific observability correlation
workflow and governance features

Those dependencies live above or around the evaluation API. OpenFeature cannot make them disappear.

Why this still matters for enterprise architecture

An enterprise can separate two decisions that are often mixed together.

Application programming standard:

OpenFeature

Feature management control plane:

Datadog
or LaunchDarkly
or Harness
or Unleash
or another approved provider

That separation can make future migrations more manageable and can give application teams a consistent API even when the enterprise evaluates different providers over time.

Should every organization adopt OpenFeature?

Not automatically.

A small application with one vendor, a handful of flags and no realistic migration concern may value the vendor's native SDK more than an abstraction layer.

A large organization with many applications, multiple languages, long platform lifecycles, acquisitions, regulatory constraints, or an explicit portability strategy has a much stronger reason to consider a standard API.

The important question is not whether abstraction is always good. It is whether the organization benefits from owning the application facing contract instead of allowing each vendor SDK to become that contract.

Where the series goes next

With the foundation established, the implementation articles move through frontend applications, backend services, serverless workloads and mobile applications. Those environments have different constraints even when they use the same feature management platform.

Later, the series will return to OpenFeature when we compare vendor portability, enterprise control planes and the tradeoff between a common API and access to vendor specific capabilities.

What Is OpenFeature?