cncf
/
toc
mirror of https://github.com/cncf/toc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
toc/projects/openfeature/openfeature-incubation-prop...

13 KiB
Raw Permalink Blame History

OpenFeature Incubation Proposal

Introduction

Overview

OpenFeature provides a shared, standardized feature flagging client - an SDK - which can be plugged into various 3rd-party feature flagging providers. Whether you're using an open-source system or a commercial product, whether it's self-hosted or cloud-hosted, OpenFeature provides a consistent, unified API for developers to use feature flagging in their applications.

Evaluation API The Evaluation API is the primary component of OpenFeature that application authors interact with. The Evaluation API allows developers to evaluate feature flags to alter control flow and application characteristics.

Providers Providers are responsible for performing flag evaluations. They provide an abstraction between the underlying flag management system and the OpenFeature SDK. Providers can wrap a vendor SDK, call a bespoke flag evaluation REST API, or even parse some locally stored file to resolve flag values. This allows the underlying flag evaluation logic to be changed without requiring a major code refactor. An application integrator can register one provider at a time. Registering an additional provider will override any previously configured providers. If no provider is set, OpenFeature will no-op and return the default value passed to the evaluation API. Providers are set through the evaluation API. They're globally registered and a change affects both new and existing OpenFeature clients.

Evaluation Context The evaluation context is a container for arbitrary contextual data that can be used as a basis for dynamic evaluation. Static data such as the host or an identifier for the application can be configured globally. Dynamic evaluation context, such as the IP address of the client in a web application, can be implicitly propagated or explicitly passed to during flag evaluation, and can be merged with static values.

Hooks Hooks are a mechanism that allows for the addition of arbitrary behavior at well-defined points of the flag evaluation life-cycle. Use cases include validation of the resolved flag value, modifying or adding data to the evaluation context, logging, telemetry, and tracking.

Events Events enable the ability to react to state changes in the provider or underlying flag management system. These include changes in provider readiness, error status, or perhaps most interestingly, flag configuration changes.

FlagD Flagd is a feature flag daemon with a Unix philosophy. Think of it as a ready-made, open source, OpenFeature compliant feature flag backend system.

Sponsors from the TOC

Emily Fox

Progress Since Sandbox

Sandbox Acceptance

OpenFeature was accepted into the CNCF Sandbox on June 14th, 2022.

Community

Outreach: As a project, we hold regular community meetings each month, highlighting what is happening in the community with presentations from multiple adopters and discussions on current topics and interests in the community. Community sessions have, on average 12 attendees, are uploaded to a Project meeting playlist hosted on Youtube, and gained over 1700 views.

The community statistics are extracted from CNCF devstats.

Technical

SDK Progress

The project aims to provide a unified API and SDK for feature flag management in various technology stacks. The OpenFeature SDK provides a mechanism for interfacing with an external evaluation engine in a vendor-agnostic way; it does not handle the flag evaluation logic.

Since achieving sandbox, we have progressed in the development of our SDKs:

Introduction of flagD

Released v0.5.4

  • A simple command line tool for fetching and evaluating feature flags for services, designed to conform with the OpenFeature specification.
  • OpenFeature compliant with providers available in many languages
  • Multiple flag configuration sources including files, http, and Kubernetes
  • Accessible over gRPC and HTTP
  • Supports subscriptions to real-time flag change events
  • Flexible targeting rules based on JSON Logic
  • Lightweight daemon, with an emphasis on performance
  • Native support for metrics using Prometheus

Provider Growth

Providers are responsible for performing flag evaluations and provide an abstraction between the underlying flag management system and the OpenFeature SDK. Providers can wrap a vendor SDK, call a bespoke flag evaluation REST API, or even parse some locally stored file to resolve flag values. This allows the underlying flag evaluation logic to be changed without requiring a major code refactor.

Providers
  • .NET: Cloudbees, flagD, Go feature flag, LaunchDarkly, Split
  • GO: Cloudbees, ConfigCat, flagD, Flagsmith, Flipt, Go feature flag, LaunchDarkly, Split
  • Java: Cloudbees, flagD, Flagsmith, Go feature flag, LaunchDarkly, Split
  • JavaScript: Cloudbees, ConfigCat, DevCycle, flagD, Go feature flag, LaunchDarkly, PostHog, Split
  • PHP: Cloudbees, flagD, Split

Incubation Stage Requirements

Adhere to CNCF IP Policy

As an existing Sandbox project, this is already in place

Document that it is being used successfully in production by at least three independent end users which, in the TOC’s judgement, are of adequate quality and scope

A list of public adopters can be found here. There are ~ 10 companies in various stages of adopting, many of whom are non-public in their adoption. The following are some examples of adopters:

  • Split - Split is excited to announce participation in OpenFeature, an initiative led by Dynatrace and recently submitted to the Cloud Native Computing Foundation (CNCF) for consideration as a sandbox program - Check out the full article here
  • Go Feature Flag - GO Feature Flag believe in OpenSource and offer providers for the new standard for feature flags OpenFeature - check out a more detailed explanation here
  • eBay - As part of eBay’s tech-led reimagination, we are investing heavily in improving software delivery so that we can launch features more rapidly and safely to our customers. Over the past few months, we have been developing feature flagging capabilities internally, powered by OpenFeature. - read more details here
  • Proofpoint - Our team recently needed to use one of the largest feature management cloud services. This service has a documented SDK with usage guidelines. Thinking about how to define the exposed interfaces, while keeping it simple and generic, we started doing some research, and encountered OpenFeature. Gladly, the mentioned feature management cloud service has already created an OpenFeature provider. Let me explain why and how it was adopted. - read more details here

Clear versioning scheme & release methodology

As outlined by our Repository requirements, OpenFeature artifacts adhere to semantic versioning and include meaningful change logs. The OpenFeature specification includes Document status definitions, which are used to indicate the stability level of each specification section.

Demonstrate a substantial ongoing flow of commits and merged contributions.

  • Commit Activity
    • In June 2023 there were a total of 820 contributions from 29 contributors. Up from a total of 64 contributions by 6 contributors the year before.
  • New Contributors over past year
    • On average we have 2 new contributors joining each week
  • There are on average 30 new PRs on the project per week
  • In the last 30 days the average time to close PRs was 14 hours 4 minutes

Full details can be found at CNCF devstats dashboards for OpenFeature.

Security

Security processes are documented here

Statement on Alignment with the CNCF Mission

OpenFeature provides a standardized, vendor-neutral specification and tooling for feature flagging. Feature flags are becoming an essential aspect of the modern software development lifecycle because they allow teams to make decouple deployments from feature releases. This reduces many risks associated with traditional deployments, allowing engineers to make high-impact changes frequently and predictably.

Standardizing feature flags unlocks increased observability at the feature level, providing additional pathways for increased automation, including intelligent deployment and rollback orchestration. This aligns with the CNCF mission of democratizing state-of-the-art patterns, making innovations in feature flagging, feature observability, and intelligent deployments accessible to everyone.

Alignment with Other CNCF Projects

Contributions to other CNCF projects:

CNCF project used by OpenFeature:

  • gRPC
  • Helm
  • Kubernetes
  • Cert Manager
  • Operator Framework
  • OpenTelemetry
  • Artifact Hub

Future Plans

A world where feature flagging is a core principle of the software development lifecycle, enabling teams to test and release high-quality software with a high degree of safety and confidence.

OpenFeature can achieve this vision by:

Vendor neutrality

OpenFeature aims to provide a standardized interface for an application author to use feature flags in a vendor-neutral way. This provides flexibility for the application integrators to choose the tooling that best fits their current requirements while avoiding code-level lock-in.

The vendor-neutral ecosystem enables additional integration options for framework and library authors. Using the standardized interface, they can include feature flagging natively, allowing users to choose the provider that best fits their needs.

Extensibility

OpenFeature is extensible while still being easy to work with. It is quick to get started with while providing application authors the flexibility to customize the functionality based on their business requirements and workflows.

Community

OpenFeature is a collective effort that benefits from years of experience across multiple verticals, including many of the top feature flag vendors and practitioners. The patterns, idioms, and techniques developed by this collaboration support feature flagging as a core principle of the software development lifecycle.

Education

Feature flagging is a simple yet powerful mechanism that improves the entire software development lifecycle by decoupling feature releases from a deployment. It isn't, however, ubiquitously used throughout the industry. OpenFeature is an opportunity to promote good software practices in a vendor-neutral way through developing feature flag awareness.

The direction of travel for OpenFeature is highly influenced by community contributions, and the core maintainers will continue to support the requests, as it has been until today. Saying that, the clear commitment is to continue to be “community-driven”, scaling the community support accordingly with the increasing number of adopters, requests of support (in forums, chats, github issues, etc.) and contributions.

As a tangible plan for the enhancements developed by the core maintainers, but not only by them, you can check the OpenFeature roadmap