Creating an Open Standard for Feature Flags

Harness is excited to announce our participation in OpenFeature, a new open source project that establishes a standard for feature flag management. OpenFeature was created to support a robust feature flag ecosystem using cloud native technologies, and it was recently accepted by the Cloud Native Computing Foundation (CNCF) as a sandbox project. 

We see the creation of OpenFeature as further evidence that the engineering industry recognizes the many benefits that feature flags can provide, including A/B testing, testing in production, or simply controlling the release of new features to production. Because of the growing popularity of feature flags, many businesses today are deciding whether to build their own feature flag solution or to purchase one. Businesses may also have concerns about vendor lock-in, as customized, bespoke architectures are common when teams (especially enterprises) look to adopt feature flag tooling. OpenFeature was designed to address these challenges with an open standard for feature flagging. 

As a new and upcoming standard, it’s important that OpenFeature has support from existing vendors. At Harness, we’re excited to be one of the vendors contributing to this open standard.

What is OpenFeature?

OpenFeature provides a specification for a vendor neutral implementation of feature flags. As stated on its website, “OpenFeature will provide a unified API and SDK, and a developer-first, cloud-native implementation, with extensibility for open source and commercial offerings.”

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

This means that organizations adopting OpenFeature can be confident that they won’t be locked into a specific vendor. Additionally, those just starting out with feature flags, can adopt a very basic implementation based on environment variables (also called configuration management) and later migrate to a vendor that provides more control and features as their requirements mature.

How OpenFeature is Implemented

OpenFeature SDKs are currently being implemented in a number of the most common languages. At a technical level, the SDK provides an evaluation API that consumers can use to obtain the value of the feature flag. At the heart of this API are the calls to evaluate different flag types, such as:

• getBooleanValue
• getStringValue
• getNumberValue
• getObjectValue

Vendors can then implement a Provider API that wraps their own SDKs. The OpenFeature SDKs can then load and use these providers, invoking them via the evaluation API.

The image below gives an example of this, where the application code calls getBooleanValue() on the OpenFeature SDK. The OpenFeature SDK then invokes the provider API.  Depending on which provider has been loaded, the vendor-specific SDK code will be invoked.

Why Harness is Participating in OpenFeature

Harness is committed to building an open ecosystem to support and improve the entire software delivery lifecycle. In 2021, we started making our own products available open source, including our Feature Flag SDKs. By contributing to OpenFeature, we are continuing to support open source projects that benefit our customers and move the industry forward by improving the way developers work.

When we talk to software engineering and DevOps leaders, we often find they have built their own homegrown solutions, but they have grown to the point where maintenance and support is too time-consuming. As a result, adding new features at scale is next to impossible. As they look to adopt better commercial tooling, they are worried about becoming locked in to a single vendor, as well as a lack of easy migration or portability.

With OpenFeature, if a team or company wants to start their feature flag journey by building something themselves, they can start by building a simple solution that fits their needs and conforms to an open standard. When their needs become more advanced, they can easily adopt a vendor solution that supports OpenFeature, like Harness Feature Flags.

At Harness, we believe in letting our customers pick and choose the modules that make the most sense for them. The OpenFeature standard is right in line with that ethos because it ensures that when a customer's feature flagging needs grow beyond the basics, we can offer the extra functionality needed without having to change how their applications integrate with Harness Feature Flags. The more the underlying implementation of feature flagging is standardized across the industry, the more we can focus on adding innovation and new value to the concept of feature flags. It becomes less about creating multiple standards across vendors, and more about focusing on simplifying adoption of feature flags and innovating on how they can add value on top of the basics.

What Are We Doing To Help?

Harness is committed to supporting OpenFeature. Initially, we have contributed toward the Golang SDK, and we plan to build OpenFeature providers for each of our Feature Flag SDKs. We are also promoting feature flags best practices to help users get the most out of their feature flag processes. 

We are excited to help push this initiative forward and to collaborate with the Feature Flag community at large to contribute to OpenFeature as the best path forward for our industry. 

If you want to check out how Harness Feature Flags can help software engineering and DevOps teams achieve control in your software delivery, you can sign up for free and start using Harness Feature Flags today.