Requirements

Context
OpenFeature.DependencyInjection was deprecated in favor of OpenFeature.Hosting, which now includes DI-related functionality. This simplifies app integration, but provider packages (e.g., LaunchDarkly) often need only a very small surface to integrate—without pulling in broader hosting concepts (hosted lifecycles, health checks, config binding, etc.).
This idea came to me after integrating launchdarkly/openfeature-dotnet-server DI, specifically after this question (launchdarkly/openfeature-dotnet-server#49 (comment)). In that integration I used only an OpenFeatureBuilder and AddProvider methods with their overloads.

Problem
Provider libraries that just need to plug a provider into OpenFeature end up depending on OpenFeature.Hosting, which can feel heavy and increase the transitive dependency surface for scenarios that don’t use hosting features.

Proposal
Introduce a thin DI-friendly package, OpenFeature.DependencyInjection.Abstractions, that exposes a small builder abstraction (e.g., OpenFeatureBuilder) for provider composition—methods like AddProvider(...), AddHook(...), and minimal configuration hooks.
Crucially, all DI registrations remain in OpenFeature.Hosting, which creates/owns the builder and applies configuration, lifecycle, health checks, and other hosting features. Providers would reference the abstractions package only, extending the builder without taking a hard dependency on hosting.

Benefits

• Separation of concerns: App authors get the full Hosting experience; provider authors get a tiny, stable surface to integrate.
• Smaller dependency footprint: Provider packages avoid bringing in hosting infrastructure they don’t use.
• Broader compatibility: Clean support for libraries, tests, console tools, and worker services where hosting may be unnecessary.
• Future-proofing: Hosting features (Aspire/telemetry/lifecycle) can evolve independently, while the builder surface remains small and stable.

Trade-offs / Considerations

• Another package to version and document.
• Clear guidance needed to avoid confusion about when to use Hosting vs. the abstractions.
• Keep the abstractions narrowly scoped to avoid duplicating Hosting responsibilities.

Back-compat / Migration

• Keep OpenFeature.DependencyInjection deprecated; optionally publish a final patch that forwards types where feasible and points to the new package.

• Provide a short migration guide:

  • App developers: use OpenFeature.Hosting.
  • Provider authors: target OpenFeature.DependencyInjection.Abstractions and extend the builder.

• Observability, lifecycle, and config binding remain in Hosting.

Questions for the community

1. Is there agreement that a DI-only builder abstraction (with Hosting retaining DI registrations) would help provider authors?
2. Any concerns about maintenance or user confusion that outweigh the benefits?
3. Naming preference: OpenFeature.DependencyInjection.Abstractions (my preferred option), or an alternative?
4. Which minimal builder methods are essential, and which should remain strictly in Hosting?
5. If there’s consensus, I can help draft an RFC and a small PoC to validate the split.

Related context
This proposal arose while updating a provider PR where the Hosting dependency felt heavier than necessary for provider-level integration. The builder-only approach allowed the provider to integrate cleanly without consuming Hosting features.