Why OpenFeature Matters: The End of Vendor Lock-in for Feature Flags

Feature flag platforms have traditionally been black boxes. Each vendor provides its own SDK, its own API, its own evaluation model. Switch providers and you rewrite every flag evaluation call in your codebase. This is vendor lock-in, and it's been the status quo for over a decade.

OpenFeature changes this. It's a CNCF (Cloud Native Computing Foundation) project that defines a standard API for feature flag evaluation. Think of it as what OpenTelemetry did for observability — a vendor-neutral interface that lets you swap implementations without changing application code.

The Problem OpenFeature Solves

Consider a typical feature flag integration without OpenFeature:

// Vendor A's SDK
import { VendorAClient } from '@vendor-a/sdk';
const client = new VendorAClient('api-key');
const value = client.getBoolVariation('my-flag', user, false);
 
// Two years later, switching to Vendor B...
// You must find and replace EVERY call across your entire codebase
import { VendorBClient } from '@vendor-b/sdk';
const client = new VendorBClient('different-api-key');
const value = client.isEnabled('my-flag', { user });  // Different API!

This isn't a hypothetical problem. Teams regularly outgrow their initial flag platform — pricing changes, feature gaps emerge, or organizational requirements shift. Without a standard API, migration means touching every file that evaluates a flag.

How OpenFeature Works

OpenFeature defines three core concepts:

1. The Evaluation API

A standard interface for evaluating flags. The same code works regardless of which provider backs it:

import { OpenFeature } from '@openfeature/server-sdk';
 
const client = OpenFeature.getClient();
 
// These calls work with ANY OpenFeature-compatible provider
const enabled = await client.getBooleanValue('dark-mode', false);
const variant = await client.getStringValue('checkout-flow', 'control');
const limit = await client.getNumberValue('rate-limit', 1000);

2. Providers

Providers are the adapters between the OpenFeature API and your chosen flag platform. Swap the provider, keep your evaluation code:

// Today: using Flaggr
import { FlaggrProvider } from '@flaggr/openfeature-provider';
OpenFeature.setProvider(new FlaggrProvider({ endpoint: 'https://flaggr.dev' }));
 
// Tomorrow: switch to another provider
// Change ONE line. All evaluation code stays the same.
import { AnotherProvider } from '@another/openfeature-provider';
OpenFeature.setProvider(new AnotherProvider({ apiKey: 'key' }));

3. Evaluation Context

A standardized way to pass targeting attributes (user ID, email, plan, location) that all providers understand:

const context: EvaluationContext = {
  targetingKey: user.id,
  email: user.email,
  plan: user.subscription.plan,
  country: user.geo.country,
};
 
const value = await client.getBooleanValue('premium-feature', false, context);

Why This Matters for Your Architecture

Multi-Provider Support

Large organizations often need multiple flag sources. Your platform team might manage infrastructure flags in one system while product teams use another for experiments. OpenFeature supports this natively:

// Different providers for different domains
const infraClient = OpenFeature.getClient('infrastructure');
const productClient = OpenFeature.getClient('product');
 
OpenFeature.setProvider('infrastructure', new ConfigProvider());
OpenFeature.setProvider('product', new FlaggrProvider());

Hooks for Cross-Cutting Concerns

OpenFeature hooks let you add logging, metrics, validation, or transformation to every flag evaluation — regardless of provider:

const loggingHook: Hook = {
  after: (hookContext, evaluationDetails) => {
    logger.debug('Flag evaluated', {
      flagKey: hookContext.flagKey,
      value: evaluationDetails.value,
      reason: evaluationDetails.reason,
    });
  },
};
 
OpenFeature.addHooks(loggingHook);

Testing Without Infrastructure

OpenFeature's InMemoryProvider lets you test flag-dependent code without connecting to any backend:

import { InMemoryProvider } from '@openfeature/web-sdk';
 
const testProvider = new InMemoryProvider({
  'dark-mode': {
    defaultVariant: 'on',
    variants: { on: true, off: false },
  },
});
 
OpenFeature.setProvider(testProvider);
// Now all flag evaluations return deterministic values

OpenFeature Protocol: OFREP

Beyond the client SDK standard, OpenFeature defines OFREP — the OpenFeature Remote Evaluation Protocol. This standardizes how flag evaluation requests are made over HTTP, so any OFREP-compatible server works with any OFREP-compatible client.

Flaggr implements OFREP v1 at /api/ofrep/, meaning you can use any OFREP-compatible SDK to evaluate flags — not just Flaggr's own SDK. This is the ultimate decoupling: your evaluation protocol is standardized, not just your client API.

# OFREP evaluation request — works with any OFREP server
curl -X POST https://flaggr.dev/api/ofrep/v1/evaluate/flags/dark-mode \
  -H "Content-Type: application/json" \
  -d '{"context": {"targetingKey": "user-123"}}'

The CNCF Ecosystem

OpenFeature is a CNCF incubating project, which means:

• Governance — neutral, community-driven development
• Longevity — backed by the same foundation as Kubernetes, Prometheus, and OpenTelemetry
• Ecosystem — growing list of providers from major vendors and open-source projects
• Interoperability — designed to work alongside other CNCF projects

OpenFeature SDKs exist for:

• TypeScript/JavaScript (server and browser)
• Go
• Java
• Python
• .NET
• PHP
• Ruby
• Kotlin (Android)
• Swift (iOS)

How Flaggr Implements OpenFeature

Flaggr was built with OpenFeature compatibility from day one, not bolted on after the fact:

• Server Provider — full-featured provider for Node.js with SSE streaming for real-time updates
• Web Provider — browser-optimized provider with cached evaluation and event-driven updates
• OFREP Endpoint — standards-compliant remote evaluation for any OFREP client
• Evaluation Context — all targeting rules work with standard OpenFeature context attributes
• Hooks — built-in OpenTelemetry hooks for automatic evaluation metrics

This means you can adopt Flaggr today and migrate away tomorrow with zero application code changes. We're confident enough in the platform that we don't need lock-in to retain users.

Getting Started with OpenFeature

If you're evaluating feature flag platforms, here's what to look for:

1. Native OpenFeature support — not a wrapper around a proprietary SDK
2. OFREP compliance — for protocol-level interoperability
3. Hook support — for observability and custom evaluation logic
4. Multi-provider capability — for gradual migration or multi-vendor setups

The investment in OpenFeature pays off the first time you need to change providers, add evaluation monitoring, or support a multi-platform architecture. Start with the standard from day one and never worry about lock-in again.

Flaggr is fully OpenFeature-compatible. See the quick start guide to set up your first flag, or read about provider architecture for advanced configurations.