This repository describes the requirements and expectations for OpenFeature.

⚠️ Ongoing research can be found in the
research repo. For definitions of
key terminology, see the glossary.

Design Principles

• Compatibility with existing open source and commercial feature flag offerings
• Simple, understandable API
• Vendor agnostic
• First class Kubernetes support
• Native support for OpenTelemetry

SDKs and Client Libraries

The project aims to provide a unified API and SDK for feature flag management in
various technology stacks. The flag evaluation logic will not be handled in
the OpenFeature SDK itself but provide a mechanism for interfacing with an
external evaluation engine in a vendor agnostic way.

The OpenFeature project will include client libraries for common technology
stacks including, but not limited to:

• Golang
• Java
• JavaScript/TypeScript (Node.js)

Tooling

This specification complies with
RFC 2119 and seeks to conform
to the W3C QA Framework Guildlines.

In accordance with this, some basic tooling (donated graciously by
Diego Hurtado) has been employed to parse the
specification and output a JSON structure of concise requirements, highlighting
the particular RFC 2119 verb in question.

To parse the specification, simply type make. Please review the generated JSON
files, which will appear as siblings to any of the markdown files in the
/specification folder.

Style Guide

• Use code blocks for examples.
  • Code blocks should be pseudocode, not any particular language, but should be
    vaguely “Java-esque”.
• Use conditional requirements for requirements that only apply in particular
  situations, such as particular languages or runtimes.
• Use “sentence case” enclosed in ticks (`) when ide