16 posts tagged with "openfeature"

Separating deployment from release is basic hygiene for a modern engineering organisation. For a Banking-as-a-Service provider, it stops being hygiene and becomes a requirement: when a new feature does not behave the way it was supposed to, we need to switch it off immediately, not schedule a rollback.

Our in-house feature flag solution served us well for a long time. It was straightforward, it did what it was built to do, and for basic on/off features it was entirely adequate. What it was not was something that could grow with us. This is the story of how we chose its replacement.

A quick primer, for anyone who needs it​

If you already live in flag tooling, skip ahead.

Before feature flags, a bad bug meant rolling back the entire deployment. On a large monolith, that is not a button you press — it is a process, and it can take hours while the problem stays live in production.

A feature flag turns that into a switch. You toggle functionality in production, instantly, with no redeployment. That is the whole idea, and everything else is refinement on top of it.

A few years ago, a fairly ordinary question would derail a fairly ordinary meeting at DataGalaxy: "is this feature actually live for this customer?"
Nobody in the room could answer it with confidence. The backend engineer would check a database table. The frontend engineer would check a build-time environment variable that may or may not have shipped in the last release. Someone from infra would mention an ingress rule nobody had touched in months. Three answers, three systems, and no way to know which one was telling the truth.

That meeting, repeated in different forms often enough to become a running joke, is really where this story starts. This is the story of how we went from that mess to a single, open, standardized way of answering that question, using OpenFeature as the contract and GO Feature Flag as the engine underneath it. It's also the first in a series of articles we plan to write about what feature flags have changed for us, and about the parts of this journey we haven't figured out yet.

A quick word on what a feature flag actually is​

If you're already deep in flag tooling, feel free to skip ahead. But it's worth grounding this story in the idea itself, because the term gets used loosely.

A feature flag (also called a feature toggle) is a mechanism that lets you change your software's behavior without changing and redeploying its code. Martin Fowler's Feature Toggles article remains the best reference on the topic: it separates flags into categories (release toggles, experiment toggles, ops toggles, permission toggles) and makes an argument we'd underlined long before we could articulate it ourselves: a flag isn't just an if statement, it's a piece of infrastructure with its own lifecycle, and treating it otherwise is how you end up with the mess described above.

That framing matters, because for a long time, we weren't running "feature flags" in that sense. We were running scattered conditionals with delusions of grandeur.

The real risk in 2026 isn't picking the wrong feature-flag tool — it's locking your codebase to one. Here's how the leading open-source options compare, judged through the OpenFeature standard for capability and true openness, not marketing.

The 2026 lens: lock-in, not features​

Open-source feature flagging has matured. Targeting rules, percentage rollouts, and self-hosting are now table stakes — most tools on this list do them well. So the interesting question is no longer "which one has the most features?" It's "which decision will I still be happy with in three years?"

The thing that outlives your tool choice is the flag-evaluation code scattered across your services. If those calls are written against a vendor's proprietary SDK, switching backends later means touching every call site. That is the lock-in that actually costs teams.

OpenFeature — the CNCF vendor-neutral specification and SDK set — is the answer the category is standardizing on. It decouples the flag API in your application code from the backend that serves the flags. You write against the OpenFeature SDK once, then plug in a provider for whatever backend you run. Swap the backend later and your application code doesn't change. That makes OpenFeature support a first-class selection criterion in 2026, not a nice-to-have — and it's the axis most listicles skip.

AI coding assistants have become a regular part of the developer workflow — writing boilerplate, suggesting configurations, explaining APIs. But when it comes to feature flags, generic AI often gets the details wrong: incorrect flag schema, outdated OpenFeature SDK patterns, or relay proxy configuration that doesn't quite match what GO Feature Flag expects.

Community members have built tools that fix this — injecting domain knowledge directly into your AI assistant so it generates accurate, idiomatic code from the start.

Thomas Poignant, creator of GO Feature Flag, has been elected to the OpenFeature Governance Committee for the 2026-2028 term. This is a milestone to be genuinely proud of — and one that feels like a natural continuation of the work done at the intersection of GO Feature Flag and the OpenFeature ecosystem.

KubeCon + CloudNativeCon Europe 2026 in Amsterdam is behind us, and what a week it was. For GO Feature Flag, it was both an opportunity to represent the project on a big stage and to connect directly with the community in person.

We are excited to introduce in-process evaluation for the GO Feature Flag OpenFeature server providers: Go, Java, .NET, Python, JavaScript, and TypeScript.

This capability is designed to improve evaluation performance and drastically reduce network traffic between your applications and the relay-proxy.

What changes with in-process evaluation?​

Previously, when you used the OpenFeature providers we ship, evaluation used remote evaluation: each flag evaluation triggered a network call to the relay-proxy.

That model fits many setups, but it is not always the most performant or resilient way to evaluate feature flags on hot paths.

That is why we are launching in-process evaluation mode for our most widely used providers.

We're excited to share that Thomas Poignant, creator of GO Feature Flag, presented an insightful talk at PlatformCon 2025 about decoupling deployments from feature releases using OpenFeature.

Talk: "Decouple Deployments and Releases with OpenFeature"​

In this presentation, Thomas explores how traditional deployment strategies often directly couple feature releases with code deployments, increasing risks and slowing time-to-market. He demonstrates how OpenFeature, a vendor-agnostic API for feature flagging, enables developers to separate feature releases from code deployments, providing precise control over feature visibility and experimentation.

This blog post dives into a new functionality introduced in the GO Feature Flag provider for OpenFeature: exporter metadata. We'll explore how it works and how you can leverage it to enrich your evaluation events with valuable static information.

What is Exporter Metadata?​

Exporter metadata is an object you can configure when initializing your GO Feature Flag provider for OpenFeature.

It allows you to specify a set of static information that you want to consistently include with all your evaluation events. A good example of information you might include in exporter metadata is the environment in which your application is running, the version of the application or anything that helps you when you analyze your evaluation data.

This data is then forwarded to the exporter and incorporated into your feature events as a new field called metadata.

Until Today the java provider, used the guava cache to store the flags and the segments. Using the guava cache is now discouraged by the guava team.

In order to follow the guidance of the guava team, we have decided to migrate the internal cache of the Java provider from guava to caffeine.

This may create a breaking change for you if you were using a custom cache configuration with the guava cache in your provider.
Because of this, the cache configuration on GoFeatureFlagProviderOptions that used Guava's CacheBuilder is now handled by Caffeine.

We're excited to announce significant improvements to the integration between GO Feature Flag and OpenFeature.

To better serve our users' diverse needs, we've decided to split the previous Go provider into two distinct providers:

• go-feature-flag: For use with the GO Feature Flag relay proxy.
• go-feature-flag-in-process: For direct integration of GO Feature Flag into your application.

Thomas recently delivered a presentation on Feature Flagging in the Software Development Lifecycle (SDLC) for OpenFeature. Given the presentation's public availability, we are pleased to share the slides with you.

Effective management of the feature flag lifecycle is crucial for maximizing the value of feature flags within an organization.

This presentation is covering the following key areas:

• Feature flag lifecycle: Understanding the complete journey of a feature flag.
• Roles and responsibilities: Identifying who owns each phase of the lifecycle.
• Feature flag naming conventions: Best practices for clear and consistent flag identification.
• Preventing flag debt: Strategies for avoiding the accumulation of unused or obsolete flags.
• Involving project managers: The importance of project management collaboration in feature flag initiatives.

By understanding these concepts, you can optimize your feature flagging strategy and drive business success.

We're thrilled to announce a major milestone for GO Feature Flag: full compatibility with mobile applications. That's right, you can now leverage the power of feature flags to optimize your iOS, Android, and React Native apps with unparalleled ease and flexibility.

We're excited to announce that GO Feature Flag is now one of the first flag management systems to support the Open Feature Remote Evaluation Protocol (OFREP) (currently in an experimental stage).

This is a significant step towards the adoption of Open Feature, a community-driven initiative aiming to standardize feature flag management across different platforms.

Welcome to this tutorial on using feature flags in Node js with GO Feature Flag and Open Feature SDKs.

In this video, we'll walk you through the process of implementing feature flags in your Node js applications, allowing you to roll out new features gradually and control their visibility in real-time.

Earlier this week the super cool podcast Dev’Obs asked me to talk about feature flags, go-feature-flag and also the super nice initiative OpenFeature.

The podcast is in French 🇫🇷 (yes I know sorry…) but you can learn a lot of cool things, when to use them, what is OpenFeature about and all the cool things that the feature flags can bring to your developer experience.

Listen it here: https://www.listennotes.com/podcasts/devobs/devobs-24-feature-flags-rknRoFGL7N5/