OpenFeature Update From the Maintainers - Thomas Poignant, Lukas Reining & Alexandra Oberaigner

OpenFeature Update From the Maintainers

Speakers: Thomas Poignant, Head of Engineering, Lonqua; Lukas Reining, IT Consultant and Software Engineer, Codecentric; Alexandra Oberaigner, Software Engineer, Dynatrace

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=lEXm6k2wpG4

Overview

This session provides a comprehensive update on OpenFeature, a CNCF incubating project dedicated to standardizing feature flagging. Presented by core maintainers Thomas Poignant, Lukas Reining, and Alexandra Oberaigner, the talk delves into the latest advancements and future directions for this critical open specification. It highlights how OpenFeature aims to solve common pain points in modern software development by offering a vendor-agnostic, community-driven API for managing application behavior at runtime, regardless of the underlying feature flag management tool.

The speakers introduce key innovations designed to enhance developer experience, enable robust experimentation, and improve observability around feature flags. These include a new Command Line Interface (CLI) for type-safe code generation, a powerful tracking API for correlating business metrics with flag evaluations, and the establishment of OpenTelemetry semantic conventions for feature flags. The presentation underscores OpenFeature's commitment to fostering an open ecosystem where developers can seamlessly integrate feature flagging into their applications without proprietary lock-in.

For organizations grappling with the complexities of managing diverse feature flag solutions or those seeking to implement data-driven development practices, this talk is highly relevant. It not only showcases practical tools to streamline flag implementation and analysis but also emphasizes the strategic importance of standardizing this fundamental DevOps practice. By providing a unified approach, OpenFeature empowers teams to deploy features more safely, conduct sophisticated A/B tests, and gain deeper insights into the impact of their releases on both technical performance and business outcomes.

Background

▶ Watch: Introduction and talk agenda overview (0:00)

Feature flags, also known as feature toggles, are a powerful technique that allows developers to modify the behavior of an application at runtime without requiring a new code deployment. This capability is fundamental for practices like A/B testing, gradual rollouts, canary releases, and personalized user experiences, enabling teams to switch users between different versions of a feature based on defined contexts. Traditionally, implementing feature flags has often led to vendor lock-in, as each feature flag management system (whether commercial or in-house) comes with its own proprietary SDKs and APIs. This fragmentation creates significant challenges, making it difficult for organizations to switch providers, integrate different systems, or maintain a consistent approach across diverse technology stacks.

OpenFeature emerged to address these issues by providing an open specification for feature flagging. As a CNCF incubating project, it offers a vendor-agnostic, community-driven API that works with any management tool or custom solution. The core concept revolves around standardized SDKs that remain consistent across various programming languages and frameworks. For each specific feature flag vendor or in-house system, OpenFeature utilizes a provider, which acts as a translation layer, mapping the generic OpenFeature SDK calls to the vendor's proprietary API. This architecture ensures that developers interact with feature flags in a uniform manner, abstracting away the underlying implementation details.

The project currently supports a wide array of languages and technologies, including Go, React, Python, Kotlin, Swift, and Ruby, with continuous expansion driven by community contributions. The growth in SDK downloads, particularly noting a significant increase in Python SDK adoption, indicates a rising interest and broader integration of OpenFeature within the developer community. This standardization not only simplifies development but also fosters a more resilient and flexible ecosystem for feature flag management, moving beyond the "big if statement" approach to a more structured and observable paradigm.

Key Findings

▶ Watch: OpenFeature's growing language ecosystem and adoption (3:00)

The talk highlights three significant advancements within the OpenFeature project, each addressing a critical aspect of feature flagging: developer experience, data-driven decision-making, and observability.

Firstly, the introduction of the OpenFeature CLI with code generation tackles the perennial problem of error-prone manual feature flag usage. Developers often contend with mistyping flag names (strings), using incorrect data types for flag evaluations, or managing default values, leading to runtime errors and reduced productivity. The CLI aims to resolve this by generating type-safe interfaces. By treating feature flags as compile-time variables rather than runtime function calls with string keys, it eliminates common errors related to typos and type mismatches, significantly improving code reliability and developer velocity. This represents a fundamental shift towards a more robust and compile-time-checked approach to feature flagging.

Secondly, OpenFeature has introduced a new Tracking API, designed to bridge the gap between technical feature flag evaluations and their business impact. While feature flags enable dynamic behavior changes, understanding whether these changes actually deliver desired business outcomes (e.g., increased conversions, improved user engagement) has historically required separate analytics integrations. The Tracking API provides a standardized mechanism to record application metrics (e.g., user clicks, purchases) and correlate them directly with the specific feature flag variants a user experienced. This enables robust experimentation capabilities, such as A/B testing, allowing teams to make data-driven decisions based on real user behavior rather than mere assumptions.

Finally, the collaboration with the OpenTelemetry team has led to the development of OpenTelemetry semantic conventions for feature flags. In complex distributed systems, observability is paramount. When feature flags alter application behavior, it's crucial to understand their impact on system performance, errors, and overall health. These semantic conventions provide a standardized way to label and categorize feature flag data within OpenTelemetry traces, metrics, and logs. By assigning common, understandable attributes (like feature_flag.key, feature_flag.variant, feature_flag.context), these conventions ensure that feature flag evaluations can be easily correlated with other observability data, facilitating comprehensive analysis and faster debugging when issues arise. This standardization is vital for debugging, performance monitoring, and understanding the operational impact of feature rollouts.

Technical Deep Dive

▶ Watch: Introducing the OpenFeature CLI for code generation (4:45)

The technical innovations presented in the OpenFeature update represent significant strides in enhancing the usability, effectiveness, and observability of feature flagging.

OpenFeature CLI and Code Generation

The OpenFeature CLI addresses a common developer pain point: the manual, string-based interaction with feature flags. Traditionally, using an OpenFeature SDK might look like client.getBooleanValue("offer-free-shipping", false, evaluationContext). This approach is susceptible to errors such as mistyping the flag name, using the wrong type evaluation function (e.g., getStringValue for a boolean flag), or incorrectly setting default values. These issues typically manifest at runtime, leading to unexpected behavior or application crashes.

The CLI, currently in an experimental phase, aims to transform this by generating type-safe code. Instead of calling a function with a string, developers would interact with flags as strongly typed variables or methods, for example, flags.OfferFreeShipping.enabled(evaluationContext). This paradigm shifts error detection from runtime to compile time, catching issues immediately.

The mechanism relies on a flag manifest, a simple JSON file that lists all available flags. Each flag entry in the manifest includes its name, type (e.g., boolean, string, number), an optional default value, and a description. For instance:

The CLI consumes this manifest and generates language-specific code (currently supported for Go and React). This generated code provides a structured interface that developers can import into their codebase. When a developer attempts to use a non-existent flag name or an incorrect type, the compiler will flag the error, preventing it from reaching production. Default values are also handled automatically behind the scenes, further simplifying the developer's interaction. While currently limited to basic types and not yet supporting object flags, the roadmap includes expanding this capability. Vendors like DevCycle and Go Feature Flag are already supporting the generation of these flag manifests.

Tracking API for Experimentation

The Tracking API is a crucial addition for organizations looking to move beyond simple feature toggling to data-driven experimentation. It addresses the question: "How do we know we built the right feature?" by enabling the correlation of feature flag evaluations with real-world application metrics.

The API introduces a track method on the OpenFeature client: client.track(eventName, eventDetails).

• eventName: A string identifying the specific application metric (e.g., "checkout_clicked", "product_added_to_cart").
• eventDetails: An object containing additional context for the event, such as the amount of a purchase, currency_code, or any other relevant data.

To implement end-to-end experimentation, two OpenFeature components are leveraged:

1. Hooks: These allow developers to intercept flag evaluation data (which flag was evaluated, its variant, and the context). This data is then sent to an observability platform.
2. Tracking Events: These are the application metrics captured using the new track method.

The key to correlating flag evaluations and tracking events is the context ID. This unique identifier, typically representing a user session or a specific user, is included in both the flag evaluation data (via hooks) and the tracking events. By sending both types of data to an observability platform (e.g., Dynatrace, using the OpenTelemetry protocol), teams can join these datasets using the context ID. This allows them to analyze, for instance, how users who saw variant A of a feature behaved compared to those who saw variant B, providing empirical evidence for the feature's impact.

The Tracking API is supported by SDKs compatible with version 0.8 of the OpenFeature spec, including Python, Kotlin, Swift, and Ruby. While it can be used with any observability platform, vendors like DevCycle and LaunchDarkly are already providing integrated support.

OpenTelemetry Semantic Conventions for Feature Flags

The collaboration with the OpenTelemetry team to establish semantic conventions for feature flags is vital for enhancing observability in environments using dynamic feature control. Semantic conventions provide a standardized, common meaning to data labels and attributes, making it easier for tools and humans to interpret telemetry data consistently across different systems and vendors.

For feature flags, this means defining specific attributes that should accompany traces, metrics, and logs whenever a flag is evaluated or influences an operation. Key attributes include:

• feature_flag.key: The name of the feature flag (e.g., "offer-free-shipping").
• feature_flag.variant: The specific variant of the flag that was evaluated (e.g., "on", "off", "treatment", "control").
• feature_flag.context: The evaluation context that was used, potentially including user IDs, session IDs, or other attributes.
• feature_flag.error_message: Any error message if the flag evaluation failed.

By adhering to these conventions, developers can ensure that when a service's behavior changes due to a feature flag, this context is automatically captured in the observability data. This allows for powerful analysis, such as filtering traces by specific flag variants to diagnose performance regressions or errors, or correlating flag states with business metrics to understand their impact. The current status is near stabilization, with a few open issues related to data types, and the team is actively seeking industry feedback to ensure comprehensive coverage. A "toy shop" example is available for those wishing to experiment with OpenTelemetry traces incorporating these new conventions.

Other Updates

The talk also touched upon other significant developments:

• CNCF Feature Flagging Course: Plans are underway for a CNCF-approved course providing an introduction to feature flagging theory, mechanics, best practices, and how OpenFeature can solve common challenges.
• Feature Flag Vendor Council: A new initiative to bring together feature flag vendors and tool authors to proactively collaborate on the OpenFeature specification, ensuring broad industry input and alignment.
• OFREP (OpenFeature Remote Evaluation Protocol): The first draft of OpenFeature Remote Evaluation Protocol was released last year. OFREP is a protocol for remotely evaluating feature flags, abstracting the complexities of SDKs and providers, allowing vendors to be compatible with OpenFeature at the network boundary. Experimental implementations exist with flagd, Flip, DevCycle, and Go Feature Flag.

Demo / Proof of Concept

▶ Watch: How CLI solves error-prone feature flag usage (5:15)

Alexandra Oberaigner presented a clear proof of concept for the new Tracking API, demonstrating how OpenFeature facilitates experimentation and data-driven decision-making. The scenario involved a fictional online toner shop wanting to test the effectiveness of a new banner promoting "free shipping on orders over $50."

The core of the demo illustrated how to correlate feature flag evaluations with application metrics to determine if the banner actually encouraged customers to spend more.

1. Flag Evaluation: OpenFeature hooks were configured to capture which users saw the "free shipping" banner (the 'on' variant) and which did not (the 'off' variant). This data included a unique context ID for each user session.
2. Application Metric Tracking: The new client.track() method was used to record when a user completed a checkout. This tracking event included details like the amount of the order and, crucially, the same context ID as the flag evaluation.
3. Data Correlation and Analysis: Both the flag evaluation logs and the tracking event logs were sent to an observability platform (Dynatrace was used in the example, leveraging the OpenTelemetry protocol). Within the platform, these two datasets were joined using the shared context ID. This allowed for a direct comparison of the average checkout amounts between users who saw the banner and those who did not.

The visual representation of the data in a graph clearly showed that users who saw the "free shipping" banner (represented by yellow bars) on average checked out with higher amounts compared to users who did not see the banner (green bars). This fictional data successfully demonstrated that the new feature was indeed "the right feature," increasing customer spending. Lucas Reining also briefly mentioned the availability of a "toy shop" example for exploring OpenTelemetry traces with the new semantic conventions, providing another tangible proof point for the observability aspects.

Defensive Implications

▶ Watch: Code generation using flag manifests with the CLI (6:30)

The advancements in OpenFeature presented in this talk offer several critical implications for developers, SREs, product managers, and feature flag vendors, enabling more robust, observable, and data-driven development practices.

For Developers and Engineering Teams:

• Reduce Runtime Errors and Improve Developer Experience: By adopting the OpenFeature CLI for code generation, developers can move from error-prone string-based flag access to type-safe variables. This shifts error detection from runtime to compile time, preventing typos and type mismatches from reaching production, thereby increasing code quality and reducing debugging time.
• Enable Data-Driven Decisions: The Tracking API empowers developers to easily instrument their applications to capture business metrics alongside feature flag evaluations. This is crucial for conducting effective A/B tests and other experiments, allowing product and engineering teams to validate hypotheses and make informed decisions based on real user behavior rather than intuition.
• Enhanced Observability and Troubleshooting: Integrating OpenFeature with OpenTelemetry semantic conventions means that feature flag states and evaluations are automatically included in traces, metrics, and logs. This provides critical context when diagnosing performance issues, errors, or unexpected behavior, allowing SREs and developers to quickly identify if a particular feature flag variant is the root cause.
• Future-Proofing and Vendor Agnosticism: Continuing to use OpenFeature ensures that applications remain decoupled from specific feature flag vendor implementations. This provides flexibility to switch providers, integrate homegrown solutions, or manage a multi-vendor environment without extensive code refactoring.
• Strategic Migration for Legacy Systems: Teams with existing homegrown feature flagging solutions (like the example of using Vault secrets) can leverage OpenFeature's provider model to create custom providers. While this allows for a gradual transition, the recommendation is to use this as a migration strategy rather than a long-term solution, eventually moving to dedicated feature flag management tools for better scalability and functionality. The multi-provider initiative further supports this migration path.

For Feature Flag Vendors and Tool Authors:

• Increase Interoperability and Adoption: By supporting the flag manifest generation for the CLI, implementing the Tracking API in their SDKs, and adhering to the OpenTelemetry semantic conventions, vendors can make their products more compatible and attractive to the growing OpenFeature community.
• Simplify Integrations with OFREP: The OpenFeature Remote Evaluation Protocol (OFREP) offers a standardized network protocol for feature flag evaluation. Vendors can implement OFREP to drastically reduce the effort required to create OpenFeature providers, as they can leverage existing OpenFeature SDKs and focus solely on the network boundary. This lowers the barrier to entry for new providers and encourages a richer ecosystem.
• Influence the Standard: Participation in the Feature Flag Vendor Council provides a direct channel for vendors to contribute to the evolution of the OpenFeature specification, ensuring that it meets industry needs and reflects best practices.

In essence, OpenFeature's latest updates provide a robust toolkit for building more resilient, data-informed, and observable applications, while simultaneously fostering an open and collaborative ecosystem for feature flagging.

Key Takeaways

• OpenFeature standardizes feature flagging: As a CNCF incubating project, OpenFeature provides a vendor-agnostic API and SDKs, abstracting away proprietary solutions and reducing vendor lock-in for dynamic application behavior changes.
• Improved Developer Experience with CLI Code Generation: The new OpenFeature CLI generates type-safe code from flag manifests, eliminating error-prone string-based flag access and catching issues at compile time rather than runtime, particularly for Go and React applications.
• Enabling Data-Driven Experimentation with the Tracking API: The new Tracking API allows developers to easily correlate application metrics (e.g., user checkouts) with specific feature flag evaluations using a shared context ID, facilitating robust A/B testing and informed business decisions.
• Enhanced Observability via OpenTelemetry Semantic Conventions: Collaboration with OpenTelemetry has led to standardized attributes for feature flag data in traces, metrics, and logs, providing a common language for understanding the operational and performance impact of flags.
• Growing Adoption and Ecosystem Development: OpenFeature continues to expand its language and framework support (notably seeing significant growth in Python SDK downloads) and is fostering community engagement through initiatives like the Feature Flag Vendor Council and the OFREP protocol.
• Strategic Path for Legacy Systems: While custom providers can integrate legacy flag management (e.g., Vault), OpenFeature encourages a migration strategy towards dedicated flag management solutions for long-term scalability and functionality.

About the Speaker(s)

Thomas Poignant is the Head of Engineering at Lonqua and plays a significant role within the OpenFeature community as a member of its Technical Committee (TC). His expertise lies in leading engineering teams and contributing to the open-source standardization of feature flagging.

Alexandra Oberaigner is a Software Engineer at Dynatrace. Her contributions to the OpenFeature project, particularly in developing and presenting the new Tracking API, highlight her focus on bridging the gap between technical implementations and business objectives through experimentation and data analysis.

Lukas Reining works as an IT Consultant and Software Engineer at Codecentric. As a member of the OpenFeature Technical Committee, he actively contributes to the project's technical direction, including the crucial work on OpenTelemetry semantic conventions for feature flags, emphasizing the importance of observability.