Define initial scope

[beeme1mr]

The purpose of this issue is to document the current status of the project and propose a high-level roadmap for achieving general availability.

Spec

The spec is an important aspect of OpenFeature. We need to reach a level of stability as quickly as possible so that SDKs, provider implementations, and hooks can be created.

Research

Server-side research

Research is nearly complete for the server-side. The outcome from that research can be seen below:

• API Comparison
• Vendor Landscape Overview

Areas that may still require additional research:

• Request based context propagation using something like continuous local storage or thread local storage. A proof of concept was added to the playground.

Client-side research

Client-side feature flagging will be a requirement for a GA release. Conceptually, they're similar to server-side feature flags but they introduce additional complexities that need to be considered. However, the majority of our effort so far has been on server-side feature flagging.

Web

Research for feature flagging client-side on the web is currently in progress.

Mobile

Research for feature flagging client-side on mobile has not been started.

Sections of the spec

Flag Evaluation

The flag evaluation section is available in an experimental state here.

Hooks

The hook section is available in an experimental state here.

There are still some ongoing discussions including:

• Should after hooks be allowed to mutate the value?
• Hook ordering & state
• Finally hook errors?

Provider

The provider is available in an experimental state here. It's important that vendors keep a close eye on this part of the spec in order to ensure OpenFeature compatibility with their product.

Evaluation Context

The evaluation context is currently in progress. This part of the spec simply provides semantic meaning to some properties on the context object. This will provide consistency between different providers. For example, one vendor may have a userId property and another may have userKey. OpenFeature needs to provide enough structure to providers in order to map context properly.

There's an open PR to add evaluation context to the spec. That PR can be found here.

Event Subscription

Event subscription is at the proposal stage. Many vendors provide an event-based API that allows developers to subscribe to events like onReady or flagUpdate.

Bulk evaluations

Bulk evaluation is at the proposal stage. This may be useful on the client, or when a developer wants to include the results of multiple flag evaluations on a request.

Tracking Events

Tracking events are at the proposal stage. Events can be associated with flag evaluations, which is particularly useful for A/B testing. This concept does not exist in all providers. However, we could potentially introduce the concept of a tracking provider. The provider could either be a provider that supports this concept or another event tracking tool, e.g. Segment.

---

SDKs

Server-side

Java

The Java SDK is under active development. You can see the repo here.

Node JS

The NodeJs SDK is under active development. You can see the repo here.

Golang

The Golang SDK is under active development. You can see the repo here.

Python

The Python SDK is under active development. You can see the repo here.

.NET

Development hasn't started on the .NET SDK, but it is expected to begin soon.

Client-side

Web

The client-side web SDK depends on the spec research listed above. It's unclear at this time how similar this SDK will be to the NodeJS SDK. Code reuse may be an option.

Mobile

Android

The client-side Android SDKs depends on the spec research listed above. Its priority still needs to be determined.

iOS

The client-side iOS SDKs depends on the spec research listed above. Its priority still needs to be determined.

React Native

The client-side React Native SDKs depends on the spec research listed above. Its priority still needs to be determined.

---

Providers and Plugins

Providers and plugins will need to be developed for each of the supported languages. A contrib repo for each language should be created. It can act as a central location for community managed providers and plugins.

Maintainers and workflows will need to be defined to ensure that only high quality providers and plugins are included.

---

Documentation

Documentation will need to be created and available online. Docusaurus seems to be the popular choice.

---

Cloud Native

The cloud native operator and provider should be moved into a separate section. Perhaps a dedicated Special Interest Group (SIG) should be defined for this initiative. The goal is to provide a spec compliant provider that utilizes Kubernetes constructs. Progress can be monitored here.