Feature flagging, (similar to bugs, but thats a different story entirely) has existed almost since the dawn of computing. It originally started as a “configuration file” that held variables, or that helped evaluate a “boolean” (true or false) statement—to do a thing statically within a given configuration. When you wanted to update it, you would change the property value, push that updated configuration out to your systems, and restart the process.
This process expanded outward across operational systems and application environments, creating ways to change a system or application without the need to redeploy it entirely.
Many companies and many teams inside of these companies came up with their own solutions for making the process a bit better (more scalable, more diverse, etc…). Some teams started storing these “feature values” in a database table. Others created microservices that other services could call to get flag values.
What progressed was a series of hand-crafted systems, that while still solving problems, created layers of complexity amongst teams and, ultimately, across companies. Eventually, these layers of complexity created brittle platforms that required significant amounts of manual intervention to manage.
Feature management platforms like LaunchDarkly aim to solve the complexity by providing a centralized platform where teams can drive feature flags dynamically, target users and groups with changes, and extend that goal of changing an application without redeployment. This has opened up many doors to simplifying the way we test applications, roll out changes, and introduce new features to teams.
As organizations look to standardize the way they ship features and leverage feature flagging at scale, the value of a standardized set of APIs and SDK interaction points has become increasingly clear. These standards should be built in the open, across multiple organizations that have an interest in ensuring the success of feature management as a development methodology and space.
That brings us to the creation of the OpenFeature project.
What is OpenFeature?
OpenFeature is a Cloud Native Computing Foundation (CNCF) sandbox project originally created by Dynatrace—but has since expanded to many stakeholder companies, community members, and technology partners. The goal of the project is to offer a unified API and SDK, and a developer-first, cloud-native implementation, that allows for extensibility between (and with) open source and commercial offerings.
Establishing a standard around feature flags as a whole creates a better experience for teams who are looking to integrate feature management across multiple adjacent systems, or who are moving feature flags across multiple platforms. When some teams opt to continue down the path of building their own solution, a standardized structure for creating and managing the data and interaction of these feature flags not only gives them a way to maintain consistency with the rest of the industry. It also gives them a simplified path for moving out of their own solution to either other community-supported feature management tools, or a commercial offering like LaunchDarkly.
As a company building a feature flag service, it also means organizations like LaunchDarkly spend less time focused on how to structure and build our own feature flags. Instead, the priority can be on improving our overall implementation of the standard for teams looking to consume the service.
Where is LaunchDarkly in OpenFeature?
At LaunchDarkly, we are firm believers that the more companies that use feature management (in whatever capacity), the better it is for the whole industry.
Feature flagging fundamentally improves the overall experience of product, developers, and operations teams. It gives a path to testing and releasing features in your applications without having to deploy from scratch each time. It allows teams to control which users are receiving the features you are releasing, and at times where you want them released. When problems arise in your applications or platforms, feature flagging gives an effortless mechanism for rolling those changes back.
Standardizing the data structure and APIs around these feature flags allows us to create better integrations, and better experiences around the ways these features are consumed. It also opens up new doors for teams to flag everywhere.
While cloud native is called out in the mission for the project, the value of a standardized API and SDK goes well beyond just the cloud. Companies that follow a hybrid on-premises and cloud approach or are still in the early days of migrating to the cloud can still leverage and benefit from this specification. Ultimately, the impact of these standards will be experienced even in legacy mainframe platforms.
This standard will help grow feature flagging usage to a number of new use cases. And we at LaunchDarkly are excited by emerging operational use cases of feature flags, which will be even more strengthened by participating in creating standardization around them. Beyond the traditional development team use cases, we’re excited and interested to see where DevOps and SRE teams take this standardization.
LaunchDarkly is invested and heavily involved (alongside many other companies within the application development space) in the work going into the OpenFeature project. We’ll be providing updates and insights along the way. Stay tuned!
