OpenFeature

There are three pieces. The OpenFeature SDK for your language exposes the standard evaluation API and holds the evaluation context. A provider is a thin adapter that implements the spec against one flag service. And your application sets the provider once at startup, then calls the standard API everywhere else. The provider does the real work of resolving a variation, so flag evaluation semantics like targeting, defaults, and evaluation reasons still come from the underlying service. Featureflip ships providers for Node.js and .NET today, with more languages planned. The OpenFeature integration guide covers installation and context mapping for both, and a worked setup for both runtimes walks through the provider code and the context field that drives rollout bucketing.

The usual reason is switching cost. A proprietary SDK spreads vendor-specific calls through the codebase, so migrating means editing every call site; coding against OpenFeature confines the vendor to one line of setup. It also makes a gradual migration practical, since you can run one provider in one service while another is still live elsewhere, and it gives multi-language shops one evaluation vocabulary instead of a different SDK idiom per stack. The trade is that the standard covers the common surface, so vendor-specific extras may still need the native SDK. Note that OpenFeature standardises evaluation only, not flag management: creating, targeting, and archiving flags stays with each vendor API, the same split remote config draws between reading a value and administering it.