Feature request: OpenFeature provider for Flutter

[dixonl90]

Feature description

Use case

We're standardising on OpenFeature across our frontend apps and would like to use Datadog Feature Flags as the evaluation backend, the same way Datadog's web/server stacks already can via the official OpenFeature providers.

How the SDK currently delivers (or doesn't)

Datadog ships official OpenFeature providers for JavaScript/browser, React, Angular, Node.js, Python, and Java — all listed under Datadog Feature Flags docs. There is currently no equivalent for Flutter / Dart. datadog_flutter_plugin exposes RUM (including addFeatureFlagEvaluation for tracking) but not the Remote Configuration channel that the JS provider uses to receive flag definitions, so a Dart-native provider can't be implemented out-of-tree without reverse-engineering RC payloads and re-implementing Datadog's evaluation logic in Dart.

The closest thing app developers can do today is wire an OpenFeature Hook that forwards afterEvaluation to DatadogSdk.instance.rum?.addFeatureFlagEvaluation(...), which gives RUM observability but leaves the actual flag values to be sourced from a different vendor — defeating the point of standardising on Datadog Feature Flags.

What we'd like to see

A first-party package:datadog_openfeature (or equivalent) shipped from this repo / the Datadog org, with parity to the JS provider:

• DatadogProvider configured with applicationId / clientToken / site / env, suitable to register via OpenFeatureAPI().setProviderAndWait(...).
• Local, instantaneous flag evaluation backed by Datadog Remote Configuration (matching the JS docs' guarantees).
• iOS / Android / web parity via the existing datadog_flutter_plugin platform channels.
• Built-in RUM evaluation reporting so consumers don't have to wire the hook themselves.
• Bucketing / targeting consistent with the server and other Datadog SDKs so users land in the same variant across platforms.

Proposed solution

Two plausible routes, ordered by ambition:

1. Full provider, in-tree. Add a new package alongside datadog_flutter_plugin that:

   • Exposes Remote Configuration over the existing platform channels (the native dd-sdk-ios / dd-sdk-android SDKs already implement RC; web can defer to @datadog/browser-rum's RC).
   • Ports the flag evaluation engine from DataDog/openfeature-js-client to Dart, sharing test fixtures with the JS implementation to guarantee bucketing parity.

2. RC plumbing only. Smaller surface: expose raw RC payloads (for the FF product code) to Dart through datadog_flutter_plugin, and let the community build the OpenFeature provider on top. Lower maintenance cost for Datadog, but bucketing parity becomes the community's problem.

Option 1 is what we'd actually want as users; option 2 would unblock us to build something defensible ourselves.

Other relevant information

Happy to contribute / pilot — we're actively integrating OpenFeature in our app today and would be early adopters of either approach. If there's an internal roadmap item already tracking this we'd love a pointer; otherwise a rough signal on whether this is on the radar at all would help us decide between waiting and building a stopgap.

[fuzzybinary]

Hi @dixonl90,

We're looking into offering this. Please make sure you've also raised it as a feature request with your CSM if you have one. That will help us track it internally.