Sessions​

OpenFeature had three sessions on the schedule this year:

• Building Secure Package Pipelines: André Silva walked through how to build a secure open-source package pipeline at the Maintainer Summit, covering OIDC authentication, SBOM generation, cryptographic attestations, and automated releases.

• OpenFeature Update From the Maintainers: Lukas Reining, André Silva, Thomas Poignant, and Alexandra Oberaigner shared updates on the MCP server, the OpenFeature GitHub Action for flag cleanup, and the stable release of OFREP. The session was part of the Maintainer Track on Wednesday.

• 18 Bluetooth Controllers Walk into a Bar: Simon Schrottner and Manuel Timelthaler gave one of the more memorable talks of the week, demonstrating OpenFeature and OpenTelemetry in action with 18 PlayStation Move controllers, tackling observability in a physical distributed system.

Slides and recordings (when available) can be found at the session links above.

Booth​

Our kiosk (P-10B) in the Project Pavilion was busy throughout the week. We had conversations with teams already using OpenFeature in production, folks evaluating it for the first time, and contributors looking to get more involved. We even learned that OpenFeature is helping feature flag kitchen appliances, turns out your next recipe might be behind a flag. It's always valuable to hear directly from users about what's working and where the gaps are.

In-Person Discussions​

One of the highlights of having so many maintainers and contributors in one place was the opportunity to hold focused, in-person discussions on key topics. We scheduled these throughout the week near our booth, and the turnout and quality of conversation was excellent. Below are summaries of each discussion.

Experimentation​

The experimentation discussion focused on what OpenFeature needs to better support experimentation use cases. Today, the SDK surface area for experimentation is limited to custom hooks and the tracking API, with an implicit link through the targeting key.

Key themes:

• Standardized context for experimentation: Multiple participants identified that having only a targeting key is limiting. There may be a need for well-understood metadata fields (browser, geo, device type) similar to semantic conventions in OpenTelemetry, so systems can map these consistently. This aligns with the existing Feature Flag Semantic Conventions SIG work in OTel.

• Evaluation metrics in the SDK: There was interest in having the SDK produce basic evaluation metrics (e.g. per flag key, by targeting reason, unique targeting keys) that analytics vendors could consume. This could be an official hook we publish rather than new API surface, since it's buildable with hooks today.

• Experiment grouping: Several participants described models where experimentation is a separate concept from feature flags, with a 1-to-N mapping between experiments and flags. There's currently no standard way in OpenFeature to describe grouped flags that share targeting under a shared experiment ID. Flag metadata could carry experiment associations, but this isn't standardized yet.

• Tracking API in OFREP: The question of whether OFREP should have an endpoint for collecting tracking events is an open topic.

• Making experimentation more visible: The group agreed OpenFeature should more explicitly communicate that it supports experimentation. Better messaging, blog posts, and validation with vendors are next steps.

Action items:

• Gather feedback from vendors on what's missing in the SDKs (spec#370)
• Explore an OFREP API for tracking/event collection (protocol#71)
• Add tracking to the OFREP demo
• Improve experimentation messaging/documentation on the website (openfeature.dev#1362)

OFREP​

The OFREP discussion covered several active topics as the protocol approaches its 1.0 target.

Key themes:

• SSE for change notifications: The SSE proposal has been merged and implementation is starting. The goal is a generic interface for notifying OFREP clients that their configurations are stale and they need to refetch. Polling will remain as an option but won't be the default.

• Local caching for client-side SDKs: Currently there's no standardized way to do caching with OFREP. A caching API needs to be defined so clients can persist configurations and know when to flush.

• Routing and session affinity: The current POST-based API makes load balancing harder since routing requires parsing the body. The group discussed adding a hash of the targeting key to a request header to enable routing without exposing PII. An ADR will be created for this.

• Tracking support: The group discussed whether OFREP should define an event endpoint. Pre-aggregation on the client side, configurable flush intervals, and bulk payloads were discussed as implementation considerations. The evaluation response could include the events endpoint URL, letting the provider enable tracking conditionally.

• OpenAPI vs gRPC: Some participants noted that their organizations require gRPC for public APIs. An issue will be opened to explore gRPC definitions for OFREP.

• Timeline: The target is OFREP 1.0 by Q2 2026.

Action items:

• ADR for targeting key hash in request headers (protocol#70)
• Tracking endpoint for OFREP (protocol#71)
• gRPC definitions for OFREP (protocol#72)
• Reintroduce OFREP SIG meetings

flagd​

The flagd discussion covered both the current feature roadmap and a longer-term vision for the evaluation engine.

Current priorities:

• Feature set, precision, nesting, and rollouts: Todd outlined the active work areas. There's consensus on what needs to land, including fractional precision improvements.

• Vision: stay minimalistic. The group reaffirmed that flagd should remain focused. There were discussions around making manual writing of rule sets easier and how targeting rules are authored with rule-builders.

Pain points:

• OpenTelemetry integration gaps
• Inconsistent behavior across language implementations
• Missing language support (e.g. Perl)
• Inconsistent reason codes across languages

Shared evaluation engine:

The biggest topic was reducing cross-language inconsistencies by sharing the evaluation engine implementation. The group explored two approaches:

• WASM: Could provide a single engine across all languages, but there are real challenges around type behavior between languages, and support across platforms. The value of having a single shared code-base is real; how do we achieve it?

The consensus was to drive toward a v1.0 milestone with defined test cases for evaluation behavior, ensuring consistency regardless of implementation approach.

Action items:

• Performance benchmarks and load testing, gate PRs on performance where applicable (flagd#1915)
• Enhance the ADR for the sync API; modularize and define what services are actually needed (flagd#1781)
• Changes to the sync API for 1.0 (agreed in principle)
• Case-insensitive matching for evaluation (flagd#1916)
• Explore CNCF support for performance testing on dedicated machines (flagd#1915)

OTel Observability​

The observability discussion focused on deepening the integration between OpenFeature and OpenTelemetry.

Key themes:

• Move OTel into the SDKs: The group proposed moving telemetry from hooks into the SDKs natively. This would mean traces and metrics are built-in rather than requiring separate hook setup. Likely makes sense to include it in the flagd providers by default.

• Native vs hooks: There's a question of whether to extend the SDK API to include traces and metrics directly, or continue with the hook-based approach.

• Connecting flags and telemetry: A push for metrics semantic conventions specific to feature flags.

• flagd observability: Check existing ADRs and add OTel support to flagd providers directly. An ADR for event tracking is needed, including how computation/aggregation should work in flagd.

Action items:

• Increase participation in the existing Feature Flag Semantic Conventions SIG in OTel
• Stabilize telemetry conventions to "stable" status
• Push for feature flag metrics semantic conventions through the SIG
• ADR for event tracking and computation in flagd

AI Workflow Integrations​

The AI discussion explored how OpenFeature can better serve AI application developers and how the project itself can leverage AI tooling.

OpenFeature for AI developers:

• MCP and Skills: The OpenFeature MCP server and related tooling can help AI application developers work with feature flags more naturally. The group discussed how to make these tools more discoverable and useful.

• Experimentation for AI workflows: How can developers use OpenFeature's experimentation capabilities to tweak models and manage AI workflow rollouts? This ties back to the experimentation discussion.

• Standards for flag creation: Can we define a standard way for AI tools to create and manage feature flags? This would enable tighter integration with AI-assisted development workflows.

OpenFeature using AI:

• Engage with the community to understand where AI tooling (e.g. write permissions, automated flag management) can add value to the project itself.
• Validate that the community sees value in these directions before investing heavily.

Expanding the Technical Committee​

The group discussed growing the Technical Committee (TC) to ensure broader representation and sustainable governance.

• Target size: The consensus is that the TC needs at least 5 members (currently 3).
• Recruitment: Several maintainers will reach out to potential candidates within their organizations and the broader community. The goal is to bring in people who are already active contributors.
• Vendor representation: The group would like to see representation from more vendors who are adopting OpenFeature, though timing depends on their level of involvement in the project.

What's Next​

The discussions in Amsterdam gave us good direction on several fronts. Expect to see movement on OFREP 1.0, experimentation support, the shared flagd evaluation engine, and deeper OTel integration through the rest of the year. If any of these areas interest you, the best way to get involved is to join the relevant discussions:

• CNCF Slack #openfeature
• Bi-weekly community meetings
• GitHub

Thanks to everyone who visited the booth, attended sessions, or joined our discussions throughout the week. We'll be at KubeCon NA 2026 in Salt Lake City this November. Hope to see you there.

Sessions at KubeCon​

OpenFeature maintainers and contributors are presenting across several sessions throughout the week:

Building Secure Package Pipelines​

Andre will walk through creating a secure package pipeline that any open-source maintainer can achieve -- covering OIDC authentication, automated SBOM generation, cryptographic attestations, and automated releases with Release Please.

OpenFeature Update From the Maintainers​

Get the latest updates from the OpenFeature maintainers on what's new in the project and where things are headed. Bring your questions.

18 Bluetooth Controllers Walk into a Bar: Observability & Runtime Configuration with CNCF Tools​

What happens when your "distributed system" is 18 PlayStation Move controllers on Bluetooth? Simon and Manuel explore observability challenges you'd never expect, using OpenFeature and OpenTelemetry to manage context-aware flags, intelligent sampling, and real-time telemetry in a physical party game.

Visit Our Booth​

Stop by and chat with OpenFeature maintainers at our kiosk in the Project Pavilion (Halls 1-5).

Kiosk Number: P-10B

Schedule:

• Tuesday, March 24: 15:10 - 19:00 CET
• Wednesday, March 25: 14:00 - 17:00 CET
• Thursday, March 26: 12:30 - 14:00 CET

We'll be there to answer questions, demo the latest features, and hear how you're using OpenFeature in your organization.

Meet the Community​

A number of OpenFeature maintainers and contributors will be in Amsterdam throughout the week, and we're organizing informal evening meetups -- including drinks. If you'd like to join or help coordinate, hop into the #openfeature-kubecon channel on the CNCF Slack. It's a great opportunity to connect face-to-face with the people building the project.

What's New in OpenFeature​

A lot has happened since KubeCon NA 2025. Here are some of the highlights:

• New Governance Committee members -- The 2026 elections have concluded and we're excited to welcome Andre Silva (LexisNexis Risk Solutions), Jonathan Norris (Dynatrace), Maks Osowski (Google), and Thomas Poignant (Gens de Confiance) to the Governance Board for the 2026-2028 term.

• CNCF Training (LFS140) -- The official Feature Flagging with OpenFeature course is available on the Linux Foundation Training Platform.

• C++ SDK -- A new C++ SDK is being bootstrapped with core API surfaces, provider management, and a Bazel build system.

• OpenFeature CLI -- The CLI continues to mature with a new push command for syncing local flag definitions to remote providers, an improved compare command, and updated code generators.

• Multi-Provider support across SDKs -- Multi-Provider has shipped or is actively being developed in JS, Java, Go, .NET, Python, Swift, and Kotlin, enabling powerful new use cases for combining multiple flag sources.

• flagd -- flagd has shipped several releases with major features including multi-project selectors, OAuth support for HTTP sync, array flag configurations, and a new memdb-based flag store.

• OpenFeature MCP Server -- A new MCP server for integrating feature flags with AI/LLM tooling, now stabilizing with protocol schema updates and reliability improvements.

• Platform modernization -- .NET SDK upgraded to .NET 10, Angular SDK reached v1.0+, Go SDK moved to Go 1.25, and Python dropped 3.9 support.

• React <FeatureFlag> component -- The React SDK added a new declarative <FeatureFlag> component for cleaner flag evaluation in React applications.

In-Person Discussions​

With so many maintainers and contributors in Amsterdam at the same time, we're organizing informal in-person discussion sessions around key topics for the project. If any of these topics interest you, come find us in the #openfeature-kubecon channel on the CNCF Slack.

Topics on the agenda include:

• Experimentation support -- advancing experimentation capabilities in OpenFeature
• flagd changes -- rollout strategies, fractional granularity, and more
• flagd common evaluation engine -- exploring a shared evaluation engine across flagd languages
• OFREP -- SSE support and local caching changes
• AI workflow integrations -- integrating feature flags into AI/ML workflows
• Expanding the TC and growing maintainers -- building out the Technical Committee and onboarding new maintainers
• OTel observability -- deeper integration with OpenTelemetry
• C++ SDK -- roadmap and direction for the new C++ SDK

These are open discussions -- all are welcome regardless of experience level.

We're looking forward to seeing you in Amsterdam. If you haven't registered yet, there's still time:

Register for KubeCon + CloudNativeCon Europe 2026

Follow us on Bluesky, LinkedIn, and join the CNCF Slack to connect with the community. See you in Amsterdam!

New Governance Board Members​

André Silva -- LexisNexis Risk Solutions​

André is a software engineer at LexisNexis Risk Solutions based in Dublin, Ireland. He is a maintainer of the OpenFeature .NET SDK and a participant in the OpenTelemetry Semantic Conventions SIG, giving him a cross-project perspective on how observability and feature flagging standards intersect. André is committed to growing the community through public speaking and blog posts, and brings firsthand experience with the challenges enterprises face when adopting feature flagging standards.

Jonathan Norris -- Dynatrace (re-elected)​

Jonathan is a Director of Software Engineering at Dynatrace, where he is helping lead the effort to build an OpenFeature-native feature management platform into the core Dynatrace product following the acquisition of DevCycle. Previously Co-Founder and CTO of DevCycle and Taplytics, Jonathan has spent over twelve years building A/B testing and feature flagging products and has been a regular contributor to the OpenFeature project. He was first elected to the Governance Board in 2024 and continues his service for a second term.

Maks Osowski -- Google​

Maks is a software engineer at Google, where he is building Google's OpenFeature-first first-party and third-party feature flagging platform. He brings a dual perspective to the board: strategic vision from a decade as a Product Manager across GKE, YouTube, and Google Docs, combined with hands-on technical depth as an OpenFeature contributor. Maks is focused on flagd 1.0 readiness, multi-language reliability, and sustained community growth.

Thomas Poignant -- Gens de Confiance​

Thomas is the CTO of Gens de Confiance, based in Paris, France, and a long-time member of the OpenFeature Technical Committee. He is the creator and maintainer of GO Feature Flag, an open-source flag management system that gives him a unique position bridging the gap between high-level specifications and practical implementation. Thomas represents the voice of the open-source community in the feature management ecosystem. He'll step down from role on the Technical Committee to join the Governance Board.

Full Governance Board​

With the new members seated, the full Governance Board for 2026 is:

For more details on the Governance Board's role and charter, see the Governance Charter.

Congratulations to André, Jonathan, Maks, and Thomas!

We also want to offer our sincere thanks to those who previously served on the Governance Committee. Your time, care, and leadership helped shape OpenFeature into the healthy, collaborative community it is today.

Thank you to the broader community for participating in the election process.

Over the next few weeks, the Governance Committee will share its goals for the year ahead. Stay tuned!

A Successful Summit​

First off, a huge thank you to everyone who joined us at the OpenFeature Summit. It was great to see a room full of users and contributors to the project. We loved seeing so many of you there, asking thoughtful questions, and sharing your own experiences with feature flagging. Thanks again to our summit sponsor, LaunchDarkly!

Check out the summit summary page for recordings and slide presentations.

Feature Flag Talks​

We also hosted two incredible talks that were all about feature flags and OpenFeature. Both sessions were well-attended, and questions and conversations kept going long after the talks ended. It's clear that feature flagging is a hot topic, and we're thrilled to see so much interest in the space.

🔥 Feature Flags Suck! - The Problems With Feature Flagging and How To Avoid Them

📈 Feature Flag Driven Development: Seamlessly Integrate Feature Flags Into Your SDLC

New CNCF Training Course: Feature Flagging with OpenFeature​

We're happy to announce the launch of our official CNCF training course: Feature Flagging with OpenFeature (LFS140). This course is perfect for developers and platform engineers who want to learn how to integrate feature flags into their workflows or enhance their apps and platforms with OpenFeature. It covers everything from the basics of feature flagging to advanced use cases, and it's a great way to level up your skills. Check it out!

As always, we were excited to hear about new adopters, stories, and usage of the OpenFeature project at the booth. Thanks again to everyone who made KubeCon NA 2025 such an unforgettable experience. Whether you joined us in person or follow along online, we're so grateful for your support. Here's to continuing the conversation and building the future of feature flagging together!

OpenFeature Summit Agenda​

📅 Date: Monday, November 10, 2025
📍 Location: Building B | Level 2 | B213-214

Doctor Flag: Into the Kubernetes Featureverse with k0rdent and OpenFeature​

Prithvi Raj (Mirantis)
Time: 1:35 PM EST

Discover how Kubernetes and OpenFeature can work together to create powerful feature flagging solutions. Learn about the integration of k0rdent with OpenFeature to simplify feature flagging in Kubernetes environments.

AI Ships Fast and Breaks Things — Feature Flags Keep It Controlled​

Jonathan Norris (DevCycle)
Time: 2:10 PM EST

Explore how feature flags can help manage the risks of deploying AI-driven changes at scale. Jonathan will share insights on using feature flags to enable faster iterations and controlled rollouts.

Feature Flag-Driven Development… in Reverse​

Robert Erez (Octopus Deploy)
Time: 2:45 PM EST

Robert Erez will explore the concept of "reverse engineering" feature flag-driven development and provide a unique perspective on improving software delivery pipelines.

From “What Broke?” To “What Changed?”: Unlocking Feature Flag Observability​

Parth Suthar (DevCycle) & Michael Beemer (Dynatrace)
Time: 3:25 PM EST

Learn how feature flags can enhance observability, helping teams quickly identify and address issues in their applications. Parth and Michael will share practical examples of integrating feature flag observability into your workflows.

Blueprint for Building Programmable CI Pipelines Using OpenFeature​

Gaurav Saxena
Time: 4:00 PM EST

Gaurav Saxena will share a detailed blueprint for creating programmable CI pipelines using OpenFeature, showcasing how to streamline development workflows and improve efficiency.

Skip the Deployment Queue: Automated Rollouts and Rollbacks Using OpenFeature​

Ekansh Gupta (SigNoz) & Shivay Lamba (Couchbase)
Time: 4:35 PM EST

Ekansh Gupta and Shivay Lamba will discuss strategies for automating rollouts and rollbacks with OpenFeature, enabling teams to deploy more confidently and effectively.

Lightning Talk: No More If-Else Soup: Scalable Feature Flag Architecture With Design Patterns​

Gaurika Poplai (Microsoft)
Time: 5:05 PM EST

Gaurika Poplai will deliver an engaging lightning talk on how to design scalable feature flag architectures using proven design patterns.

Key Feature Flag Talks at KubeCon​

In addition to the OpenFeature Summit, don’t miss these exciting feature flag-focused sessions during KubeCon + CloudNativeCon:

Feature Flags Suck! - The Problems With Feature Flagging and How To Avoid Them​

Speaker: Pete Hodgson (PH1)
Time: Thursday, November 13, 11:00 AM - 11:30 AM EST
Location: Building B | Level 5 | Thomas Murphy Ballroom 2-3

Pete Hodgson will dive into the common pitfalls of feature flagging and how to avoid them. Learn how to manage feature flags effectively and leverage CNCF's OpenFeature project to streamline your workflows.

Read more about this session here.

Feature Flag Driven Development: Seamlessly Integrate Feature Flags Into Your SDLC​

Speakers: Kris Coleman (TestifySec) & Michael Beemer (Dynatrace)
Time: Thursday, November 13, 3:15 PM - 3:45 PM EST
Location: Building B | Level 4 | B406b-407

Kris Coleman and Michael Beemer will introduce Feature Flag Driven Development (FFDD), a groundbreaking workflow that integrates feature flag management into the SDLC. Their demo will showcase how FFDD leverages CNCF's OpenFeature spec and tools like the OpenFeature CLI to enable type-safe, GitOps-driven flag promotion.

Read more about this session here.

We’re excited to see you at KubeCon + CloudNativeCon North America 2025 and the OpenFeature Summit! Don’t miss this chance to connect with the OpenFeature community, learn from industry leaders, and explore the future of feature flagging.

👉 Register for KubeCon + CloudNativeCon North America 2025 👈

Follow us on Twitter or Bluesky for live updates during the event. See you in Atlanta!

As engineering teams contend with the constant demand for increased speed and efficiency in their development practices, the rules around compliance and security remain rigid. This presents one of the core problems we see teams struggling with today:

How can we move fast, with safety?

Pete Hodgson, OpenFeature Governance Board Member, poses this question in his foreword for the new guide the Flagsmith team put together with OpenFeature and eBay.

For large organisations operating in complex or regulated environments, the question is particularly salient. Feature flags form part of the answer (in support of Continuous Delivery), but only if introduced in the right way. Large organisations face a steep learning curve when introducing any new technology, and feature flags are no exception.

Because feature flags live deep in your codebase, it’s important to introduce them in a thoughtful and strategic way, avoiding locking you into bad habits or specific vendors.

Feature flags are more of a social innovation than a technical one. Their real magic is revealed when they’re introduced to an organisation at scale—impacting the very way software gets built. The technology is only half the battle. Determining how to use it, who can use it, and how to drive adoption successfully is just as important.

Building a strong foundation for feature flags​

Doing a good job of introducing any new technology into a large organisation starts with people—the people behind the technology and the internal teams who will adopt it.

Introducing feature flags will fundamentally change the way you build software, so pulling in the right stakeholders from the beginning is important. Start by creating a working group with representatives from your engineering, QA, product, and DevOps/infrastructure teams.

Additionally, you’ll need full executive buy-in to bring flags on at scale. This is true from a budget perspective but, just as importantly, from a time perspective, too. Part of the reason the eBay team was so successful with their OpenFeature adoption is because they were given full license to use engineering hours to get it done.

Budget for this time up front and create a plan with specific milestones and owners—as well as a strict timeline, so that the project keeps moving forward. Ensure this plan is shared at a company level, so that those involved are motivated to stay on time and on track.

eBay leaned into three main levers to drive organisational-wide adoption:

1. Identifying initial influencers to pilot with: They identified key internal influencers, working to form a group of diverse and motivated individuals. Gradually, as the team collected and iterated on initial feedback from these developers, they prepared to scale it to other teams.
2. Scaling the pilot programme: They identified 21 different teams to run multiple pilots with to learn and create the roadmap for a feature flag MVP. They did three rounds of pilots over three quarters, focusing on building product-market fit internally:
3. Finding success & building the MVP: Once they had completed the final round of feedback, they started preparing the MVP, which, once ready, they had to roll out to everyone. No small feat at a company the size of eBay.

Tailoring feature flags to your organisation’s needs​

As you begin to determine how to introduce feature flags into your release processes, ensure your team is familiar with the different kinds of flags as well as best practices to keep your flags healthy and reduce tech debt. Feature flags can become an anti-pattern if over-engineered, so be sure to familiarise yourself with the different types of flags and lifecycles.

Another best practice for getting up and running with flags is to identify the simplest possible use case, start there, and then gradually introduce them more widely and in more complex use cases.

Creating governance for your feature flag usage is going to be a key part of this adoption. This article is a sneak preview of the full guide on scaling feature flags.

If you enjoyed it and want to read on, you can download the full (ungated) guide with the case study here.

TLDR: KubeCon EU 2025​

This year's KubeCon EU was located in London, where I happen to live, giving me the opportunity to attend KubeCon EU for the first time. I had a wonderful time finally meeting fellow OpenFeature maintainers face-to-face and connecting with users of OpenFeature.

This year we saw a growth of interest in OpenFeature, and heard stories of people using OpenFeature in their own products. The OpenFeature booth at the project pavillion buzzed with activity, plenty of knowledge shared and the power of OpenFeature shared with interested people.

For a second time at KubeCon our dedicated, co-located event, The OpenFeature Summit took place the day before KubeCon EU 2025 itself. The summit featured great talks and speakers. I would like to point of a few of these talks:

• ▶️ OpenFeature Update From the Maintainers - Thomas Poignant, Lukas Reining & Alexandra Oberaigner Latest updates what happened in the world of OpenFeature.

• ▶️ OpenFeature’s Positive Impact on Confidence at Dynatrace - Simon Schrottner & Todd Baert, Dynatrace by Simon Schrottner & Todd Baert from Dynatrace gave a great presentation about how they internally use the different OpenFeature offerings like flagd, OpenFeature SDKs

• ▶️ Canary Deployments Are a Myth - True Progressive Delivery Occurs Via OpenFeature - Bob Walker, Octopus Deploy by Bob Walker from Octopus Deploy described how they solved they delivery problems using OpenFeature and feature flags. A deep dive how flags can help with deploying releases in a safe and convenient manner. Tip! A longer version of this talk is available as part of KubeCon EU 2025.

• ▶️ Lightning Talk: OpenFeature Multi-Provider: Enabling New Feature Flagging Use-Cases by Jonathan Norris from DevCycle. A talk about ways you can use the new Multi-Provider to your benefit, like to migrate away from feature flag solution to your new one.

• ▶️ Challenges in Distributed Feature Flag Evaluation and How To Solve Them Lukas Reining & Christopher Bohlen, codecentric AG by Lukas Reinig & Christopher Bohlen from codecentric AG. In this talk we got into the nitty gritty of feature flags that span multiple services, and saw multiple proposals how we can ensure the feature flag evaluations are consistent between the services.

Introducing OpenFeature CLI​

During the conference we also introduced our latest creation, OpenFeature CLI, which streamlines how feature flags are managed within your codebase. The tool generates a type-safe OpenFeature client based on a flags manifest file that either can be pulled from supported feature flag systems or sourced from a JSON file.

With OpenFeature CLI, developers can:

• Generate a strongly-typed client, custom-built for your specific feature flags, in Typescript, Python or C# (with more to come!)
• Validate flag configurations against schemas
• Seamlessly integrate with existing CI/CD pipelines

The CLI represents our commitment to improving developer experience and making feature flag management more accessible to teams of all sizes. It's designed to work alongside your existing tools and workflows with minimal friction.

In a separate article, we will dive deeper into the goals of openfeature-cli and how it can improve a developer's experience working with feature flags. Stay tuned for a hands-on tutorial.

Conclusion​

KubeCon EU 2025 was a milestone event for the OpenFeature community. The growing adoption of OpenFeature across diverse organizations demonstrates the industry's recognition of standardized feature flagging as a critical component of modern software delivery.

We'd like to thank everyone who visited our booth, attended the summit, or participated in OpenFeature-related discussions throughout the conference. Your enthusiasm and feedback drive our project forward.

We'd love to welcome you into the OpenFeature community. You can join our Slack channel, attend our bi-weekly community meeting or just check out our GitHub repository.

Impressions​

What is the Sentry OpenFeature Integration?​

The Sentry OpenFeature Hook allows Sentry to track feature flag evaluations within your application. When an error occurs, Sentry will include the state of all evaluated feature flags in the error report, providing crucial context for debugging and troubleshooting.

This integration is currently in beta and only supports boolean flag evaluations. See their changelog for details on how feature flags are integrated into their platform.

JavaScript Integration​

To use the Sentry OpenFeature Hook in your JavaScript application:

import * as Sentry from "@sentry/browser";
import { OpenFeature } from "@openfeature/web-sdk";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  integrations: [Sentry.openFeatureIntegration()],
});

OpenFeature.setProvider(new MyProviderOfChoice());
OpenFeature.addHooks(new Sentry.OpenFeatureIntegrationHook());

const client = OpenFeature.getClient();
const result = client.getBooleanValue("test-flag", false); // evaluate with a default value
Sentry.captureException(new Error("Something went wrong!"));

Requirements: Sentry SDK version 8.43.0 or higher

Python Integration​

For Python applications, you can use the Sentry OpenFeature Hook as follows:

import sentry_sdk
from sentry_sdk.integrations.openfeature import OpenFeatureIntegration
from openfeature import api

// Initialize Sentry with the OpenFeature integration
sentry_sdk.init(
    dsn="https://examplePublicKey@o0.ingest.sentry.io/0",
    integrations=[
        OpenFeatureIntegration(),
    ],
)

// Get your OpenFeature client
client = api.get_client()

// Evaluate a feature flag
client.get_boolean_value("hello", default_value=False)

// If an error occurs, Sentry will include the feature flag state
sentry_sdk.capture_exception(Exception("Something went wrong!"))

Requirements: sentry-sdk >= 2.19.2, openfeature-sdk >= 0.7.1, Python >= 3.8

Benefits of Feature Flag Observability​

The Sentry OpenFeature integration provides several key benefits:

1. Contextual Error Reporting: When errors occur, you'll see exactly which feature flags were active, helping you identify if a flag change contributed to the issue.

2. Performance Monitoring: Track how feature flags impact your application's performance.

3. Debugging Efficiency: Reduce the time spent reproducing issues by having feature flag state automatically included in error reports.

4. Release Confidence: Make data-driven decisions about feature rollouts by correlating errors with specific flag states.

The Value of Open Standards​

This integration exemplifies the power of open standards in the feature flagging ecosystem. By implementing the OpenFeature specification, Sentry can provide a seamless integration that works with any OpenFeature provider, without requiring vendor-specific implementations.

This aligns with OpenFeature's vision of reducing integration effort by moving from effort(N*M) to effort(N+M). OpenFeature delivers a standardized feature flagging SDK, already implemented by most providers, and Sentry can focus on building a great performance monitoring and error-tracking platform for their users.

Next Steps​

If you're using Sentry and OpenFeature, we encourage you to try out this integration. The feature flag state will be automatically included in your error reports, providing valuable context for debugging.

For more information, check out the official Sentry documentation:

• JavaScript Integration
• Python Integration

Using another platform? Sentry is planning expanding support for more platforms, starting with mobile. We're excited to see how this integration helps teams better understand the impact of their feature flags on application stability and performance.

The Flags SDK is an exciting development for standardizing feature flagging in Next.js and SvelteKit, as it takes an opinionated approach to how feature flags should be used:

• Feature Flags are just functions
• Feature Flags are only evaluated on the server-side, no client-side flag evaluation is supported to improve performance, avoid layout shifts, and other non-optimal user experiences.
• Integration with the Vercel Toolbar, allows local overrides of flag values during development, testing and even in production.

OpenFeature Provider Example​

// flags.ts
import { createOpenFeatureAdapter } from "@flags-sdk/openfeature"
import { dedupe, flag } from "flags/next";
import type { EvaluationContext } from "@openfeature/server-sdk";

// pass an init function, and return the client
const openFeatureAdapter = createOpenFeatureAdapter(async () => {
  const provider = new YourProviderOfChoice()
  await OpenFeature.setProviderAndWait(provider);
  return OpenFeature.getClient();
});

const identify = dedupe((async ({ headers, cookies }) => {
  // Your own logic to identify the user
  // Identifying the user should rely on reading cookies and headers only, and
  // not make any network requests, as it's important to keep latency low here.
  const user = await getUser(headers, cookies);
 
  const context: EvaluationContext = {
    targetingKey: user.id,
    // .. other properties ..
  }; 
  return context;
}));

export const exampleFlag = flag<boolean, EvaluationContext>({
  key: "example-flag",
  defaultValue: false,
  identify,
  adapter: openFeatureAdapter.booleanValue(),
});

// page.tsx
import { exampleFlag } from "../flags";

export default async function Page() {
  const banner = await exampleFlag();
  return (
    <div>
      {banner ? <Banner /> : null}
      {/* other components */}
    </div>
  );
}

This adapter will allow most Node.js OpenFeature Providers to work with the Flags SDK, though there may be some compatability issues with certain Node.js OpenFeature Providers with the Vercel Edge Runtime that should be tested per-provider.

The Value of Open Standards​

The integration demonstrates a key aspect of OpenFeature's vision - moving from effort(N*M) to effort(N+M). OpenFeature delivers a standardized feature flagging SDK, already implemented by most providers, and Vercel can focus on building a wonderful framework-specific developer experience on top of that foundation.

Future of Next.js Support​

We are excited to continue working with the team at Vercel that is leading this effort, and to help expand the efforts of open standards in feature flagging for Next.js and SvelteKit. One of the visions of OpenFeature has always been deeper integration into the language / framework level as the adoption of OpenFeature continues to grow, we are happy to work with language and framework authors who strive to offer feature flagging built-in.

While the Flags SDK is offering Next.js and SvelteKit developers with an opinionated and performance optimized open-source feature flagging SDK, we recognize that its structure may not work for all Next.js developers out there relying on a mixture of client-side rendering in their applications. If you are knowledgeable about Next.js and would like to help OpenFeature develop our Next.js SDK, please reach out to us in the CNCF #openfeature Slack.

If you'd like to test out the Flags SDK OpenFeature Adapter check out their example project.

This year, teams tackled projects ranging from OpenFeature CLI improvements to using OpenFeature Remote Evaluation Protocol with CloudFlare Workers. Let's take a closer look at how our team hacked, what we learned, and why these projects matter.

DevCycle's Hackathon Projects​

OpenFeature Remote Evaluation Protocol with Cloudflare Workers​

At DevCycle, we were an early supporters of the OpenFeature Remote Evaluation Protocol (OFREP), and long-time users of Cloudflare Workers. Naturally, we were curious if we could use the OFREP API as a bridge interface to better support Feature Flags in these edge environments. As one of our hackathon projects, Elliot from our team built a DevCycle OFREP Worker, which we could publish for customers to run in their own environment. This worker can use a service binding to bind this worker to any of their own internal workers.

This implementation provides a Cloudflare Worker template that synchronizes and caches DevCycle flags configuration within your Cloudflare environment. The worker fetches the flag configuration from the DevCycle's CDN once, which is served by Cloudflare's CDN / R2, and then processes the project configuration locally to evaluate flags for individual users. This means that feature flags can be accessed almost instantaneously within any Worker in your environment, eliminating processing delays and reducing external API calls.

Then, in your internal worker, you can use the existing OpenFeature SDKs with the OFREP Provider to bind the fetch call to the DevCycle OFREP Worker:

import { OpenFeature } from '@openfeature/server-sdk'
import { OFREPProvider } from '@openfeature/ofrep-provider'

const provider = new OFREPProvider({ 
    baseUrl: 'https://ofrep-bucketing-worker.devcycle.com', 
    fetchImplementation: (input: RequestInfo | URL, init?: RequestInit) => env.OFREP_BUCKETING.fetch(input, init),
    headers: [
        ['Content-Type', 'application/json'],
    ]
})
await OpenFeature.setProviderAndWait(provider);
const client = OpenFeature.getClient();

Integrating OFREP with Cloudflare Workers offers a scalable and high-performance solution for feature flag evaluation at the edge built on open standards. This was a great demo during our Hackathon; there is still some work to do to productize this OFREP worker; reach out to us if you think this is an interesting use-case for OFREP as we continue to work on it.

OpenFeature CLI Contribution​

Strongly typed feature flags are essential for teams managing feature flags at scale across large codebases. DevCycle has long supported the dvc generate types command in our CLI, which generates Typescript Types for our DevCycle SDKs. When we heard about the development progress of the OpenFeature CLI in generating types for OpenFeature SDKs, we were eager to contribute to its development.

While the OpenFeature CLI is in its early development, type generation for Go and React is already functional. However, there was no built-in way for vendors to integrate their platforms with the CLI’s type generation feature.

The openfeature generate react command runs by generating a typed interface for your OpenFeature SDK from a known list of flags from a standard flags manifest file. To support this standard as a vendor, the CLI would need a way to pull and sync the flag manifest file directly from a vendor’s platform. Jason from DevCycle stepped in and created an openfeature pull method to pull flag data from DevCycle's API and generate a manifest file for the CLI to use.

> openfeature pull
> openfeature generate react

This will result in an openfeature.ts file with populated variable hooks:

'use client';

import {
  type ReactFlagEvaluationOptions,
  type ReactFlagEvaluationNoSuspenseOptions,
  type FlagQuery,
  useFlag,
  useSuspenseFlag,
} from "@openfeature/react-sdk";

/**
* 
* 
* **Details:**
* - flag key: `a-newer-feature`
* - default value: `false`
* - type: `boolean`
*/
export const useANewerFeature = (options?: ReactFlagEvaluationOptions): FlagQuery<boolean> => {
  return useFlag("a-newer-feature", false, options);
};

/**
* 
* 
* **Details:**
* - flag key: `a-newer-feature`
* - default value: `false`
* - type: `boolean`
*
* Equivalent to useFlag with options: `{ suspend: true }`
* @experimental — Suspense is an experimental feature subject to change in future versions.
*/
export const useSuspenseANewerFeature = (options?: ReactFlagEvaluationNoSuspenseOptions): FlagQuery<boolean> => {
  return useSuspenseFlag("a-newer-feature", false, options);
};

...

We are excited to keep working on the CLI with the folks from Dynatrace, Google Cloud, and others leading this effort. Our PR adding the pull command

Codemod: Convert Codebase from Vendor SDK to OpenFeature SDK​

Building a Codemod for OpenFeature migrations has been on our radar for a while. After connecting with the Codemod team, we saw its potential for helping customers migrate from vendor SDKs to OpenFeature SDKs. Codemod has gained great adoption among teams upgrading to the latest versions of React or officially supported upgrade paths - such as the transition from Nuxt 3 to Nuxt 4 (Nuxt 3 → 4).

This hackathon finally gave us the chance to experiment with Codemod’s tooling and publish a codemod. Think of the codemod platform as tooling around open-source code transformation tools like jscodeshift, while adding AI-powered tooling for generating codemods, plus an NPM-like repository for distributing them.

Our first set of codemods focussed on helping teams transition their codebases from DevCycle or Launchdarkly Node.js SDKs to using the OpenFeature SDK, using the respective vendor’s OpenFeature Provider. To do this, we discovered it best to break down the problem into smaller, testable steps and then run all the codemods together in a workflow:

• Update Imports CodeMod - transforms file and packages imports to use OpenFeature + Provider.
• Initialization Transform - transforms the SDK initialization from using initializeDevCycle() to setting up the DevCycleProvider and creating the OpenFeature Client
• User Context Transform - updates DevCycleUser to EvaluationContext objects, rename user_id param to targetingKey
• Variable Transform - replaces DevCycle variableValue() and variable() calls with get<Type>Value() and get<Type>Details() calls to OpenFeature

After installing codemod: npm i -g codemod, these can be run using:

codemod devcycle-to-openfeature-nodejs-workflow

The codemod CLI will download the latest version of the codemods and run them against your codebase.

These codemods are a great starting point for anyone looking to do much of the heavy lifting, updating a codebase from DevCycle or Launchdarkly Node.js SDKs to OpenFeature. We are interested in feedback from the community about the value of these codemods and if we should continue developing them for more languages / vendors, as well as if these codemods would make sense as an OpenFeature-supported project.

Docusaurus OpenFeature Wrapper​

Docusaurus is a popular framework for building documentation websites, making it easy to create and maintain interactive docs using Markdown and React. Since both DevCycle and OpenFeature rely on Docusaurus for their documentation, integrating feature flagging directly into the platform makes perfect sense. With this approach, documentation can dynamically update based on feature flags, allowing teams to release code and docs together—an essential capability for feature-driven development.

For the OpenFeature Hackathon, one of our engineers, Parth, built an OpenFeature Docusaurus plugin, leveraging the OpenFeature React SDK and flagd to enable feature management within documentation sites. He created a Docusaurus provider and applied it to a barebones Docusaurus site to showcase its functionality. The plugin allows developers to use feature flags to dynamically toggle sections of documentation, ensuring content remains in sync with evolving product features. By integrating OpenFeature, this project bridges the gap between documentation and feature flagging, improving flexibility, maintainability, and release coordination for teams using Docusaurus.

DevCycle Provider Updates for Go, .NET & Ruby​

DevCycle has been supporting OpenFeature for several years, and as part of this hackathon, Jamie took the time to review our OpenFeature providers across our SDKs to ensure they were up-to-date with the latest OpenFeature SDK features.
This included adding event tracking support and handling initialization/close when applicable.

We also worked on building and publishing our much requested DevCycle OpenFeature Ruby Provider. Our goal is to provide OpenFeature support across all DevCycle SDKs, with only Next.js, iOS, Android, React Native, Flutter, and Roku remaining for full coverage.

Dogfooding OpenFeature SDK Nest.js SDK + Providers​

In the spirit of dogfooding OpenFeature and our own Providers, Kaushal from our team took up the task of updating the usage of DevCycle's Nest.js SDK in our main API service to use the OpenFeature Nest.js SDK with DevCycle's Nest.js Provider.

To accomplish this, we introduced a wrapper service that used a single instance of the OpenFeature Client, making it accessible across our Nest.js service. This straightforward migration allowed the OpenFeature Client to replace any existing calls to DevCycle's SDK.

One of the key takeaways from this project was realizing how much our API development relied on Nest.js decorators, which simplified our feature flagging of API endpoints:

• @RequireFlagsEnabled(["flag1", "flag2"], ForbiddenException)
  • This would check if the targeting context evaluated multiple Boolean values to true for all the flags passed in else return the exception (default exception of NotFound)
• @RequireFlagValues({ "flag1": "apples", "flag2": true }, ForbiddenException)
  • This would check if the targeting context matched multiple flags to the corresponding values to true for all the flags passed in, else return the exception (default exception of NotFound)

We started a PR here to enhance the Nest.js SDK with these decorators.

We also lean heavily on the mock interfaces provided by the DevCycle Nest.js SDK to mock and set flag values, which allows us to test different branching code paths in our API service. Adding similar mocking capabilities would be a useful addition to make testing all the OpenFeature SDKs easier. Dogfooding the OpenFeature SDKs and our own providers was a valuable learning experience, sparking new ideas on how to contribute to and improve these SDKs in the future.

Projects that Didn't Make the Cut This Time Around​

• Evaluation Reasons for SDKs – Enhancing our SDKs with evaluation reasons, bringing us closer to full OpenFeature spec compliance.
• Feature Flag Observability – Improving insights into how feature flags impact performance and decision-making.
• Add Tracking support to more SDKs - OpenFeature SDK Tracking Support
• Multi-Provider Expansion – Bringing multi-provider support to more languages.

And many more! Each project aimed to strengthen the OpenFeature ecosystem and provide better tools for developers. Let us know what projects you found the most interesting and we should continue developing further, please reach out to us in the CNCF #openfeature Slack.

About OpenFeature​

OpenFeature is a CNCF-incubating project that's defining open standards for feature flagging and experimentation. As a vendor-agnostic initiative, we're committed to improving the developer experience across the feature flagging landscape.

Key highlights:

• A vendor-agnostic open standard for feature flagging
• Open-source project under Apache 2 license
• Supported under the CNCF (alongside projects like Kubernetes and OpenTelemetry)
• Designed to work with any feature flag management tool - commercial, open-source, or in-house
• Broad industry support with many feature flagging vendors already providing official integrations
• Support for multiple tech stacks, both server-side and frontend - 12 and counting

Why Join the Vendor Council?​

As key players in the feature flagging ecosystem, your insights are invaluable to shaping our specifications and improving the developer experience of consuming feature flags in codebases.

Areas Where We're Seeking Input:​

• Enhancing flagd, our lightweight feature-flagging daemon that enables dynamic configuration updates without code changes
• Adding event tracking capabilities to OpenFeature, to improve experimentation and A/B testing within feature flag implementations
• The OpenFeature Remote Evaluation Protocol (OFREP), an initiative aimed at reducing SDK authoring burden on vendors and standardizing communication between flag evaluation systems
• Future initiatives that would help flagging platforms adopt OpenFeature or make it more valuable for your users

Participation Involves:​

• Quarterly virtual meetings (approximately 1 hour)
• Occasional email correspondence for feedback
• Optional participation in our Slack community

We're flexible and open to structuring participation in a way that works best for our advisors.

Benefits for Vendors:​

• Early access to new features and specifications
• Direct influence on the project's direction
• Networking opportunities with other industry leaders
• Shared marketing opportunities to promote OpenFeature features in your products
• Recognition as a contributor to this open-source initiative

How to Join​

If your organization is involved in the feature flagging space - whether as a commercial vendor or an open-source maintainer - and you're interested in joining the OpenFeature Vendor Council, we'd love to hear from you!

Please reach out to us by:

• Emailing Pete Hodgson (a member of the Open Feature Governance Committee) at workwith@thepete.net
• Posting in the #openfeature Slack channel
• Opening an issue in our GitHub repository

In your message, please include:

1. Your name and organization
2. Your role within the organization
3. A brief description of your interest in OpenFeature
4. Contact information for follow-up

Join Us in Shaping the Future​

The OpenFeature project is committed to creating standards that benefit the entire feature flagging ecosystem. By bringing together diverse perspectives from across the industry, we can build something truly valuable for developers and organizations alike.

We look forward to collaborating with you!

OpenFeature Summit​

The OpenFeature Summit is the ultimate gathering for feature flagging enthusiasts to exchange insights, best practices, and success (and a few horror) stories. This event is a fantastic opportunity to network, engage in lively discussions, and explore the latest innovations in feature flagging.

Event Details:

• Date: April 1, 2025
• Location: ExCeL London, Royal Victoria Dock, 1 Western Gateway, London E16 1XL, United Kingdom

Schedule Highlights:

• 13:25 BST: Welcome + Opening Remarks
• 13:35 BST: OpenFeature's Positive Impact on Confidence at Dynatrace - Simon Schrottner & Todd Baert, Dynatrace
• 14:15 BST: ⚡ Lightning Talk: Bridge Infrastructure & Application - OpenFeature for Dynamic Feature Management in K8 Deployments - Nikunj Goyal, Adobe & Aditi Gupta, Disney Plus Hotstar
• 14:30 BST: ⚡ Lightning Talk: Look Into the Hooks of OpenFeature - Saurav Jain, Apify
• 14:50 BST: Canary Deployments Are a Myth - True Progressive Delivery Occurs Via OpenFeature - Bob Walker, Octopus Deploy
• 15:20 BST: Challenges in Distributed Feature Flag Evaluation and How To Solve Them - Lukas Reining & Christopher Bohlen, codecentric AG
• 15:55 BST: Flag-tastic and Fearless: Feature Flags Meet Kubernetes for Deployments That Sing - Aditya Soni, Forrester & Anshika Tiwari, AWS
• 16:45 BST: ⚡ Lightning Talk: OpenFeature Multi-Provider: Enabling New Feature Flagging Use-Cases - Jonathan Norris, DevCycle
• 15:45 BST: Beyond Boolean: Solving Hard Problems in Feature Flag Architecture at Scale - Ryan Feigenbaum, GrowthBook
• 17:15 BST: ⚡ Lightning Talk: The Permutations and Combinations of Managing Features: Beyond the Toggle - Prerit Munjal, InfraOne
• 15:25 BST Closing Remarks

For more details, visit our OpenFeature Summit page.

KubeCon EU Sessions​

In addition to the OpenFeature Summit, there will also be several sessions during KubeCon EU:

• OpenFeature Update from the Maintainers - Thomas Poignant, Adevinta & Lukas Reining, codecentric AG

  • Date: Wednesday, April 2, 2025
  • Time: 11:15 - 11:45 BST
  • Location: Level 3 | ICC Capital Suite 10-12

• How We Progressively Deliver Changes To Kubernetes Using Canary Deployments and Feature Flags - Bob Walker, Octopus Deploy

  • Date: Thursday, April 3, 2025
  • Time: 16:00 - 16:30 BST
  • Location: Level 0 | ICC Capital Hall | Room 2

• Type-safe Feature Flagging in OpenFeature: Lessons Learned From Using Feature Flags at Google - Michael Beemer, Dynatrace & Florin-Mihai Anghel, Google

  • Date: Friday, April 4, 2025
  • Time: 11:45 - 12:15 BST
  • Location: Level 1 | Hall Entrance N10 | Room H

Visit Our Booth​

Don't miss the chance to visit our booth in the project pavilion! We'll be there to answer your questions, demonstrate our latest features, and discuss how OpenFeature can help your organization.

Booth Location: Solutions Showcase

Schedule:

• Wednesday, April 2: 15:30 - 19:45 BST
• Thursday, April 3: 14:00 - 17:00 BST
• Friday, April 4: 12:30 - 14:00 BST

Call for Sponsors​

We are still looking for sponsors for our co-located event. If you're interested in supporting the OpenFeature Summit and gaining visibility among a highly engaged audience, please review the sponsorship prospectus.

We look forward to seeing you at KubeCon EU and the OpenFeature Summit!

KubeCon NA 2024 Wrapped​

As usual, we had a great time at the OpenFeature booth in the project pavilion. We always appreciate the chance to connect with maintainers face-to-face, sometimes for the first time! Each year we hear from more users who've made use of OpenFeature within their organization or project.

This was also our first time having our own dedicated, colocated event: The OpenFeature Summit! There were some great talks here; a couple of highlights:

• ▶️ Migrating to OpenFeature at Scale: 0 to Billions, by Chetan Kapoor & Justin Abrahms from eBay
  • a great presentation about using OpenFeature at massive scale, and a notable example of how to effectively (and empathetically) promote the internal adoption of a tool at enterprise scale
• ▶️ Experimentation Programs at Scale: Lessons Learned from Top Companies, by Graham McNicoll from GrowthBook
  • if this doesn't convince you that you need to be using experimentation to validate your features and roadmap, nothing will!
  • particularly relevant to some of our newest features 👀

The full list of videos and slides from the OpenFeature Summit are available here.

Additionally, don't sleep on Pete Hodgson's SDLC track presentation on undertaking big, hairy migrations, and how feature flags can help.

Robust Experimentation Support with Tracking Events​

Teams spend a lot of time talking about developing, deploying, monitoring and maintaining features, but how do you know if you've built the right features in the first place? Without data to evaluate the success and adoption of features, aren't you just guessing? The best teams bake experimentation into their product development cycle, so that they can use data to drive their decisions.

Some feature flag vendors provide functionality to help address this issue, and we knew OpenFeature needed to as well. With the latest enhancements to our specification, OpenFeature now supports this sort of experimentation! The new Tracking API defines interfaces and functions to allow application authors to "close the gap" between feature flags and business objectives; helping to assert that a particular flag variant actually corresponds to increased usage, for instance.

In fact, if your vendor or home-grown feature flag solution doesn't support equivalent functionality, hooks and tracking compose a flexible solution to associate flag evaluations with usage data, regardless of whatever customer data platform or telemetry backend you use. For more information, see tracking concepts.

These enhancements were brought to you by the hard work of many feature flag vendors, enterprises, and subject matter experts... Thanks to all who helped!

Implementations and Future Plans​

Tracking event functionality is already implemented in our React, Javascript, Java, and Go SDKs, with more on the way. For an up-to-date list of implementations, check out the SDK Compatibility Overview. Download the latest release in your language of choice and try it out!

How Max Got Involved with OpenFeature​

Max’s journey with OpenFeature began around a year ago while working at Justworks, where his team was re-evaluating their flagging strategy. He noticed that the Ruby SDK existed and had the basics of flag evaluation implemented but was not yet released or highlighted on the website.

“At Justworks, I wrote our implementation to get us going, but I started to upstream many of our learnings into the Ruby SDK. We dropped support for our internal implementation last month and are now entirely on the main SDK,” Max explains.

Motivation to Contribute​

Max is passionate about increasing Ruby’s presence within Cloud Native Computing Foundation (CNCF) projects, where he feels it doesn’t get as much attention as other languages. As he puts it, “Ruby is largely underrepresented in many CNCF projects; the Ruby community tends to have its own handful of competing libraries but doesn’t interact externally as much as other languages like Golang and Java.”

Beyond his focus on Ruby, Max also feels a strong sense of responsibility to give back to the open-source community. “I owe a great deal to the open-source community and feel like OpenFeature is an excellent project to give back on, as the implementation is straightforward, and I actively use it at Justworks,” he says.

Key Contributions​

Max’s key contributions to the OpenFeature project have focused primarily on the Ruby SDK. Some of his major achievements include:

• Reviving the dormant Ruby SDK project and getting it to a releasable state, which led to it being officially listed on the OpenFeature.dev website
• Implementing the InMemoryProvider utility in the Ruby contrib project
• Contributing to the MetaProvider in the Ruby contrib project, including working on the specification language for it

These contributions have greatly improved the usability and functionality of the Ruby SDK, helping it gain more traction within the OpenFeature ecosystem.

Most Rewarding Experience​

For Max, one of the most fulfilling moments in his OpenFeature contributor journey was seeing the Ruby SDK officially listed on the OpenFeature website. As he reflects, “Definitely getting the Ruby SDK listed on the website was a big milestone.”

What made this achievement even more meaningful for Max was that it marked his debut in large-scale open-source contributions. “It was my first time participating in a large open-source project, and that was very rewarding,” he shares, emphasizing the impact of his work on the broader OpenFeature community.

Advice for Newcomers​

When offering advice to newcomers, Max suggests starting with the foundation. “Start with the basics in the specification!” he advises, noting that, “Unlike other standards and specs around the web, OpenFeature is very straightforward and digestible, and you can read the whole thing in less than an hour.”

Max encourages new contributors to explore whether their primary language is represented or if the vendor they use has a provider. Once you find something that sparks your interest, his advice is simple: “Just start coding!”

He adds that contributors shouldn’t hesitate to ask for support, because “the OpenFeature community is very friendly, and welcomes all questions on Slack or GitHub.”

Thank You, Max!

We’re grateful for Max’s dedication and contributions to the OpenFeature project. His work has had a significant impact, and we look forward to seeing how he continues to shape the future of feature flagging standards.

OpenFeature Summit: A New Era in Feature Flagging​

The OpenFeature Summit is the ultimate gathering for feature flagging enthusiasts to exchange insights, best practices, and success (and a few horror) stories. This event is a fantastic opportunity to network, engage in lively discussions, and explore the latest innovations in feature flagging.

Event Details:

• Date: November 13, 2024
• Location: Salt Palace Convention Center, Salt Lake City, UT

Schedule Highlights:

• 9:10am MST: Welcome + Opening Remarks
• 9:45am MST: How to Rollout an Update for a CNI Without Breaking the World Wide Web - Reza Ramezanpour & Jen Luther Thomas, Tigera
• 10:40am MST: Test Smarter, Not Harder: QA Enhancements with OpenFeature - Meha Bhalodiya, Red Hat
• 11:15am MST: Migrating to Open Feature at Scale: 0 to Billions - Chetan Kapoor & Justin Abrahms, eBay
• 11:45am MST: Experimentation Programs at Scale: Lessons Learned from Top Companies - Graham McNicoll, GrowthBook
• 12:00pm MST: ⚡ Lightning Talk: The Hidden Costs of Feature Flags: Understanding and Managing Adoption Challenges - Shreya Shivratriwar, Software Engineer
• 12:15pm MST: ⚡ Lightning Talk: Mocking Feature Flags in Unit Tests - Aman Gadadare, Jio
• 12:25pm MST: ⚡ Lightning Talk: Would a Gradual Rollout by Any Other Hashing Algorithm Still Smell as Sweet? - Chris Griffing, GitKraken
• 12:35pm MST: Closing Remarks

For more details, visit our OpenFeature Summit page.

KubeCon NA Sessions​

In addition to the OpenFeature Summit, there will also be several sessions during KubeCon NA:

• Taming Your Application’s Environments - Marcos Lilljedahl, Dagger & Mauricio "Salaboy" Salatino, Diagrid

  • Date: Wednesday, November 13, 2024
  • Time: 5:25pm - 6:00pm MST
  • Location: Salt Palace | Level 2 | 250

• Migratory Patterns: Making Architectural Transitions with Confidence and Grace - Pete Hodgson, PartnerSlate

  • Date: Friday, November 15, 2024
  • Time: 4:00pm - 4:35pm MST
  • Location: Salt Palace | Level 2 | 255 EF

Visit Our Booth​

Don't miss the chance to visit our booth at the Solutions Showcase! We'll be there to answer your questions, demonstrate our latest features, and discuss how OpenFeature can help your organization.

Booth Location: Salt Palace | Level 1 | Halls A-C + 1-5 | Solutions Showcase

Schedule:

• Wednesday, November 13: 3:15pm - 8:00pm
• Thursday, November 14: 1:45pm - 5:00pm
• Friday, November 15: 12:30pm - 2:30pm

Call for Sponsors​

We are still looking for sponsors for our co-located event. If you're interested in supporting the OpenFeature Summit and gaining visibility among a highly engaged audience, please review the sponsorship prospectus.

We look forward to seeing you at KubeCon NA and the OpenFeature Summit!

Features​

Angular Module System Integration​

The Angular SDK exports a module that allows you to configure your OpenFeature provider using Angular constructs. You can set your default provider, and optionally configure additional providers for other domains. Besides configuring your provider, you'll also need to use the OpenFeatureModule in order to utilize the other features of the SDK.

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { OpenFeatureModule } from '@openfeature/angular-sdk';

@NgModule({
  declarations: [
    // Other components
  ],
  imports: [
    CommonModule,
    OpenFeatureModule.forRoot({
      provider: new YourOpenFeatureProvider(),
      // domainBoundProviders are optional, mostly needed if more than one provider is needed
      domainBoundProviders: {
        domain1: new YourOtherOpenFeatureProvider(),
        domain2: new YourOtherOtherOpenFeatureProvider(),
      },
    })
  ],
})
export class AppModule {
}

Easy Templating with Directives​

Perhaps the most useful part of the Angular SDK is the inclusion of the built in evaluation directives. These directives handle all the flag evaluation boilerplate for you, using Angular's directive abstractions which add functionality to elements. In its most basic form, the directive differentially renders templates based on the flag evaluation result:

<!-- evaluate a flag called new-message and show a render a different template based on the result -->
<div
  *booleanFeatureFlag="'new-message'; default: true; else: booleanFeatureElse;">
  <p>Welcome to this OpenFeature-enabled Angular app!</p>
</div>
<ng-template #booleanFeatureElse>
  <p>Welcome to this Angular app.</p>
</ng-template>

String, Numeric, and Object flags are also supported. For these, you can supply templates based by matching against the returned flag value:

<!-- render this template if the value == 10 -->
<div
  *numberFeatureFlag="'discountRate'; value: 10; default: 5; else: numberFeatureElse">
  This is shown when the feature flag matches the specified discount rate.
</div>
<!-- render this template if the value != 10 -->
<ng-template #numberFeatureElse>
  This is shown when the feature flag does not match the specified discount rate.
</ng-template>

Additionally, it's possible to bind the evaluation result and related metadata to the template by omitting the value to match:

<!-- omitting the `value` to match against unconditionally renders this template -->
<div *stringFeatureFlag="'themeColor'; default: 'light'; let value;">
  The theme color is {{ value }}.
</div>

Loading and Automatic Re-Rendering​

You may want to hide some content until your provider is ready. For this reason, the directives support specifying templates to render before your provider is ready, and while it's reconciling its state after context changes. The directive will automatically re-render when the provider's readiness changes, or if the flag values themselves change.

<!-- render different templates based on the readiness of the flag provider -->
<div
  *booleanFeatureFlag="'my-feature'; default: true; else: booleanFeatureElse; initializing: booleanFeatureInitializing; reconciling: booleanFeatureReconciling">
  <p>This is shown when the feature flag is enabled.</p>
</div>
<ng-template #booleanFeatureElse>
  <p>This is shown when the feature flag is disabled.</p>
</ng-template>
<ng-template #booleanFeatureInitializing>
  <p>This is shown when the feature flag is initializing.</p>
</ng-template>
<ng-template #booleanFeatureReconciling>
  <p>This is shown when the feature flag is reconciling.</p>
</ng-template>

Compatibility​

As with other framework-specific SDKs, the Angular SDK is built on top of the existing @openfeature/web-sdk. Any OpenFeature provider built to support the web SDK can also be used with the @openfeature/angular-sdk, no changes required.

Looking Ahead​

We’re eager to expand the Angular SDK’s capabilities with future updates! If you're an Angular developer or interested in exploring how feature flags can enhance your applications, we encourage you to try out the OpenFeature Angular SDK. Happy coding! 🎉

Getting Involved with OpenFeature​

André discovered OpenFeature while researching the state of feature flag vendors. He became intrigued by OpenFeature's potential as a new standardization effort in the feature flag space and decided to contribute after noticing some "needs help" tags on GitHub issues.

Motivation to Contribute​

For André, contributing to OpenFeature is more than just writing code—it's about solving critical software development and release challenges. He believes in the power of community-driven standards to reduce dependencies on third-party vendors, allowing companies to focus more on their products. The opportunity to shape these standards and libraries, and see them adopted by others, is incredibly rewarding for him.

Key Contributions​

André has made several significant contributions to OpenFeature, particularly in the .NET ecosystem. Some of his key achievements include:

• Bringing more telemetry signals to the .NET library
• Adding new features based on the OpenFeature specification to the .NET library
• Updating the codebase to incorporate the latest C# language features
• Helping shape telemetry conventions for feature flags

Most Rewarding Experience​

For André, the most rewarding aspect of contributing to OpenFeature is seeing the library gain traction among developers. As more people start using OpenFeature, the responsibility to deliver high-quality outcomes increases, but so does the satisfaction of knowing his work is making a difference.

Advice for Newcomers​

André’s advice for anyone looking to contribute to OpenFeature is simple: "Don't be afraid." The OpenFeature community is always welcoming new contributors, and André is particularly open to helping those interested in working on the .NET libraries.

Thank You, André!

We're grateful for André's dedication and contributions to the OpenFeature project. His work has made a significant impact, and we look forward to seeing how he continues to shape the future of feature flag standards.

Notable Improvements​

Support for Cancellation Tokens, Idiomatic Method Names​

Methods on some key interfaces (such as provider resolvers) have been updated to indicate that they work asynchronously, by appending the Async suffix in accordance with .NET conventions:

    await Api.Instance.SetProvider(myProviderInstance);
    await Api.Instance.SetProviderAsync(myProviderInstance);

Additionally, optional cancellation tokens can now be passed to applicable asynchronous methods. This allows for the cancellation of async tasks, and is consistent with .NET norms:

    await client.GetBooleanValue("my-flag", false, context, options);
    await client.GetBooleanValueAsync("my-flag", false, context, options, cancellationToken);

ValueTasks for Hooks​

The return types for stages within hooks have been updated to take advantage of the performance benefit provided by ValueTasks. The vast majority of hook stages run synchronously, and they are awaited internally by the SDK; so we can avoid the additional allocations associated with Tasks by using ValueTasks:

public class MyBeforeHook : Hook
{
    public Task<EvaluationContext> Before<T>(HookContext<T> context,
        IReadOnlyDictionary<string, object> hints = null)
    {
      // code to run before flag evaluation
    }
    public ValueTask<EvaluationContext> BeforeAsync<T>(HookContext<T> context,
        IReadOnlyDictionary<string, object> hints = null, CancellationToken cancellationToken = default)
    {
      // code to run before flag evaluation
    }
}

Migration Steps​

Application Authors​

Async suffixes and Cancellation Tokens​

Generally, application authors won't have to make many changes.

As mentioned above, some async methods have been changed to conform to .NET conventions. Evaluation methods now have the "Async" suffix, and accept an optional cancellationToken:

    await client.GetBooleanValue("my-flag", false, context, options);
    await client.GetBooleanValueAsync("my-flag", false, context, options, cancellationToken);

The method for setting a provider has been updated similarly:

    await Api.Instance.SetProvider(myProviderInstance);
    await Api.Instance.SetProviderAsync(myProviderInstance);

"Client Name" has Changed to "Domain"​

Parameters previously named "client name" are now named "domain". "Domains" are a more powerful concept than "named clients", but in instances where named clients were previously used, function identically. No changes to consuming code are necessary these cases.

Provider Authors​

Provider Method Name Changes​

Provider authors must change their implementations in accordance with new methods names on the provider interface. Optionally, you can make use of the new cancellation token:

    public override Task<ResolutionDetails<bool>> ResolveBooleanValue(
                string flagKey,
                bool defaultValue,
                EvaluationContext? context = null)
            {
                // return boolean flag details
            }
    public override Task<ResolutionDetails<bool>> ResolveBooleanValueAsync(
                string flagKey,
                bool defaultValue,
                EvaluationContext? context = null,
                CancellationToken cancellationToken = default)
            {
                // return boolean flag details
            }

No Need for Provider Status​

It's no longer necessary to define, update or expose provider status. If your provider requires initialization, simply define the optional InitializeAsync method:

public class MyProvider : FeatureProvider
{

    private ProviderStatus _status = ProviderStatus.NotReady;        
   
    public override ProviderStatus GetStatus()
    {
        return _status;
    }

    public override Task Initialize(EvaluationContext context)
    public override Task InitializeAsync(EvaluationContext context, CancellationToken cancellationToken = default)
    {
        // some async initialization
    }
}

For more details about this change, see our previous blog post.

Hook Authors​

Hooks Must Return ValueTask​

Hooks must now return ValueTask instead of Task:

public class MyBeforeHook : Hook
{
    public Task<EvaluationContext> Before<T>(HookContext<T> context,
        IReadOnlyDictionary<string, object> hints = null)
    {
      // code to run before flag evaluation
    }
    public ValueTask<EvaluationContext> BeforeAsync<T>(HookContext<T> context,
        IReadOnlyDictionary<string, object> hints = null, CancellationToken cancellationToken = default)
    {
      // code to run before flag evaluation
    }
}

Full Changelog​

See here for the full changelog.

Thanks!​

Thanks to all our users, and a special thanks to everyone who contributed to the .NET SDK:

About the WeAreDevelopers World Congress​

The WeAreDevelopers World Congress is one of the largest developer conferences globally. It brings together tech enthusiasts, developers, engineers, and thought leaders from around the world to discuss the latest trends, innovations, and technologies shaping the future. With over 200 speakers, including industry pioneers and tech visionaries, the event offers a comprehensive agenda filled with keynote speeches, workshops, and networking opportunities. This congress is an excellent opportunity for learning, inspiration, and professional growth, making it a valuable event for anyone passionate about technology.

About the GitHub Open Source Spotlight​

The GitHub Open Source Spotlight is a dedicated space within the WeAreDevelopers World Congress that highlights notable open-source projects and the communities behind them. This spotlight provides a platform for developers to showcase their work, share insights, and collaborate with peers. Being featured in this segment underscores the importance and impact of open-source contributions in the tech ecosystem. We are honored to be part of this lineup, where we can share our journey, innovations, and future plans with the broader tech community.

Where to Find Us​

You can find us at Exhibition Hall 2.2. Our booth will feature:

• Live Demos: Get hands-on experience with OpenFeature and see how it can integrate into your projects.
• Expert Talks: Engage with members of the OpenFeature team who will be available to discuss your queries, provide insights, and share best practices.
• Networking Opportunities: Connect with like-minded professionals, exchange ideas, and build relationships that can help propel your projects and career forward.

Follow OpenFeature on all our social channels to stay updated throughout the event.

• Twitter: @OpenFeature
• LinkedIn: OpenFeature
• GitHub: OpenFeature

How It Works​

const multiProvider = new MultiProvider([
  {
    provider: new ProviderA(),
  },
  {
    provider: new ProviderB(),
  },
]);

await OpenFeature.setProviderAndWait(multiProvider);

openFeatureClient = OpenFeature.getClient();
const value = await openFeatureClient.getStringValue('flag-key', 'default value', someUser);

The Multi-Provider behaves like any other provider, but under the hood it combines results from any number of providers. It takes a list of providers as its only required parameter, then evaluates flags by progressing through the list of providers in order. By default, it will only evaluate the next provider if the current one indicates the flag was not found. Once there is a flag match, the Multi-Provider will return that result and not evaluate with the remaining providers.

Strategies​

In order to support diverse use cases, the Multi-Provider also accepts a Strategy parameter, which can be customized to control which providers are evaluated and how the final result is determined.

const multiProvider = new MultiProvider(
  [
    {
      provider: new ProviderA(),
    },
    {
      provider: new ProviderB(),
    },
  ],
  new SomeStrategy(),
);

First Match Strategy​

The default Strategy is the FirstMatchStrategy. This will evaluate providers in order, moving on to the next provider only if the current provider returns a FLAG_NOT_FOUND result. If an error is thrown by any provider, the Multi-Provider will throw that error. The OpenFeature SDK will then catch the error and return the default value.

This strategy is useful for migrating from one provider to another, when some flags have been ported to the new system while others remain in the old one. By putting the new provider first in the provider's list, the Multi-Provider will prefer results from the new system but keep the old as a fallback.

FirstMatchStrategy can also be used to pull feature flags from multiple sources, and return as soon as the flag is found.

First Successful Strategy​

FirstSuccessfulStrategy is similar to FirstMatchStrategy, except that errors from evaluated providers do not halt execution. Instead, it will return the first successful result from a provider. If no provider successfully responds, it will throw an error result.

One use case for this strategy is if you want the Multi-Provider to fallback to another provider in the case of an error, rather than throwing an error itself. For example, if an external vendor provider goes down, you may want to automatically fall back to a config file.

Comparison Strategy​

The ComparisonStrategy requires that all providers agree on a value. If the providers return the same value, the result of the evaluation will be that value. Otherwise, the evaluation result will contain an error in the errors field to indicate a mismatch, and the result value will be the value returned by the first provider. The ComparisonStrategy also evaluates all providers in parallel, as it is not intended to exit as soon as it finds a match.

One use case for this strategy is validating the success of a provider migration. If the configuration in one provider has been recreated in another, this strategy confirms the flags and user targeting are consistent between those sources.

Custom Strategies​

In order to support complex provider behaviour and diverse use cases, users can write custom strategies that extend the abstract BaseEvaluationStrategy class. Some key methods to control the Multi-Provider’s behaviour include:

• runMode: This property determines whether providers are evaluated sequentially or in parallel.
• shouldEvaluateThisProvider: This function is called before a provider is evaluated. If it returns false, the provider is skipped. This is useful for conditional evaluations based on the flag key or the provider's state.
  • For example, if you know that all flag keys containing the substring provider_a_ should only be evaluated using ProviderA, you can skip evaluating with any other providers when that prefix is used.

export class MyCustomStrategy extends BaseEvaluationStrategy {
  // In this example, we know keys containing 'provider_a_' will only exist in ProviderA
  override shouldEvaluateThisProvider(
    strategyContext: StrategyPerProviderContext,
    evalContext: EvaluationContext,
  ): boolean {
    if (strategyContext.flagKey.includes('provider_a_') && strategyContext.providerName !== 'ProviderA') {
      return false;
    }

    return true;
  }
}

• shouldEvaluateNextProvider: After a provider is evaluated, this function determines whether to proceed with evaluating the next provider. It takes into account the result or any errors encountered. If it returns true, the next provider is evaluated; otherwise, the evaluation stops and the results are passed to determineFinalResult. In parallel execution mode, this function is not called.
  • If your provider indicates that a result should not be used in a non-standard way, you can customize shouldEvaluateNextProvider to continue to the next provider if that condition is met. For example, if your provider result should be skipped when flagMetadata.unusableResult is true, you can check for that property here.

export class MyCustomStrategy extends BaseEvaluationStrategy {
  override shouldEvaluateNextProvider<T extends FlagValue>(
    strategyContext: StrategyPerProviderContext,
    context: EvaluationContext,
    details?: ResolutionDetails<T>,
    thrownError?: unknown,
  ): boolean {
    // if the provider indicates the result should not be used, continue to next provider
    if (details?.flagMetadata.unusableResult === true) {
      return true;
    }
    // otherwise, return this result
    return false;
  }
}

• determineFinalResult: This function is invoked after all evaluations are completed (or when no further evaluations are needed). It consolidates the results and determines the final outcome. The function must return a FinalResult object, which includes the final resolution details and the corresponding provider, or an array of errors if the result was unsuccessful.
  • For example, if you are evaluating several providers in parallel and want to control which result is used in the case of a mismatch, rather than using the built-in ComparisonStrategy, you could override this function.

export class MyCustomStrategy extends BaseEvaluationStrategy {
  override runMode = 'parallel';

  override determineFinalResult<T extends FlagValue>(
    strategyContext: StrategyPerProviderContext,
    context: EvaluationContext,
    resolutions: ProviderResolutionResult<T>[],
  ): FinalResult<T> {
    let value: T | undefined;

    for (const resolution of resolutions) {
      if (typeof value !== 'undefined' && value !== resolution.details.value) {
        logger.warn('Mismatch between provider results: ', value, resolution.details.value);
      } else {
        value = resolution.details.value;
      }
    }

    // we want to always use the first provider's resolution
    const finalResolution = resolutions[0];
    return this.resolutionToFinalResult(finalResolution);
  }
}

Use Cases​

Some key use cases supported by the Multi-Provider include:

Migrating from one provider to another​

Let’s say you were using one provider, OldProvider, but have decided to switch to NewProvider moving forward. You have been creating all new flags in NewProvider, while slowly copying over your existing flags. This means your newest flags only exist in NewProvider , some of your older flags only exist in OldProvider, and an increasing number of flags exist in both. Previously, you would have to instantiate an OpenFeature client for each of your providers, or register the providers under different domains and manage switching between them manually. The Multi-Provider allows you to wrap both providers and prioritize the new one automatically:

const multiProvider = new MultiProvider([
  {
    provider: new NewProvider(),
  },
  {
    provider: new OldProvider(),
  },
]);

The NewProvider now takes precedence and will always be used, unless a flag does not exist in its configuration. In that case, the Multi-Provider will fall back to OldProvider automatically.

Validating the success of a migration​

You can also use the Multi-Provider to confirm that two or more providers always agree on all evaluation results. For example, once you are finished migrating all of your feature flags from OldProvider to NewProvider, you may want to run concurrently for some time and track any instances where the evaluation results differ, to catch errors in the configuration of NewProvider.

By using the ComparisonStrategy, you can configure the Multi-Provider to run all providers and return an error result if the results don’t match.

const newProvider = new NewProvider();
const oldProvider = new OldProvider();

const onMismatch = (_resolutions: ProviderResolutionResult<FlagValue>[]) => {
	logger.warn('Provider mismatch!')
}

const multiProvider = new MultiProvider(
    [
      {
        provider: newProvider,
      },
      {
        provider: oldProvider,
      }
    ],
    new ComparisonStrategy(
      oldProvider, // the fallback provider to trust in the case of a mismatch
      onMismatch, // callback method called when provider resolutions don't match
    )
)

Aggregating flags from multiple sources​

The Multi-Provider can be used to combine feature flags from sources such as environment variables, database entries, and vendor feature flags, without having to instantiate multiple SDK clients. The order of the providers list establishes the precedence order of providers to control which should be trusted if keys exist in both systems. For example, if you want to use environment variables to override flag values from a vendor provider, you could pass the environment variable provider as the first in the providers list.

const multiProvider = new MultiProvider([
  {
    provider: new EnvVarProvider(),
  },
  {
    provider: new VendorProvider(),
  },
]);
await OpenFeature.setProviderAndWait(multiProvider);

openFeatureClient = OpenFeature.getClient();
const value = await openFeatureClient.getStringValue('flag-key', 'default value', someUser);

If the flag with the key ‘flag-key’ exists in both providers, it will only be evaluated with the EnvVarProvider.

Setting a fallback for cloud providers​

You can use the Multi-Provider to automatically fall back to a local configuration if an external vendor provider goes down, rather than using the default values. By using the FirstSuccessfulStrategy, the Multi-Provider will move on to the next provider in the list if an error is thrown.

const multiProvider = new MultiProvider(
  [
    {
      provider: new VendorProvider(),
    },
    {
      provider: new EnvVarProvider(),
    },
  ],
  new FirstSuccessfulStrategy(),
);

In this example, if VendorProvider is unavailable for any reason, EnvVarProvider will be evaluated instead.

Compatibility​

The Multi-Provider offers developers more flexibility and control when managing complex feature flag setups. As a first step, we have implemented it in the @openfeature/server-sdk and @openfeature/web-sdk.

Future Plans​

We’re excited to get feedback about the current strategies and hear about other possible use cases. As we validate the Multi-Provider on the initial supported implementations we will gradually expand to support other languages and further strategies. We welcome contributors to bring this functionality to other languages.