NuGet package names / namespace inconsistencies for OpenFeature providers

[julealgon]

I was browsing the existing provider packages produced by this repo and noticed there is an obvious inconsistency in the way they are named:

https://github.com/orgs/open-feature/packages?ecosystem=nuget

Here are the formats in use today:

• OpenFeature.Contrib.Provider.{VendorInfo}
• OpenFeature.Contrib.Providers.{VendorInfo}
• OpenFeature.Contrib.{VendorInfo}

Besides those inconsistencies, there is also the topic of "should the package name have .Contrib on it?". OpenTelemetry packages don't, even those that are from the contrib repo. I personally think that's the best naming strategy as it makes it very easy to find any packages and they are all clearly related by the names regardless of the source.

Will these inconsistencies be fixed? What about the .Contrib part, have you considered also dropping that from the packages?

[toddbaert]

I was browsing the existing provider packages produced by this repo and noticed there is an obvious inconsistency in the way they are named:

Hey @julealgon I agree the consistency could be improved. Maybe we could do this with some kind of linting/checking in the repo. Unfortunately renaming a package is certainly puts a burden on consumers since it requires a manual migration for continued features/fixes, so it would be up to the maintainers of each contrib package if they want to do it.

Besides those inconsistencies, there is also the topic of "should the package name have .Contrib on it?". OpenTelemetry packages don't, even those that are from the contrib repo. I personally think that's the best naming strategy as it makes it very easy to find any packages and they are all clearly related by the names regardless of the source.

I don't feel too strongly either way, but I think there's some value in having Contrib in the name. The SDK itself (OpenFeature) has no dependencies and is owned by the OpenFeature maintainers (it's likely additional "core" packages like this will be published). Artifacts in the contrib repos are stewarded by the OpenFeature maintainers as well, but especially for components that involve integrations with 3rd party tools or vendors, we rely heavily on those who contribute the components to keep them up to date from a feature perspective. They also frequently have a transitive dependency on a particular vendor SDK, etc.

To put it another way, we take responsibility for the packaging, security, and hosting of these contributions, but not the continuing development of their feature sets; I think Contrib might be a good indicator of this difference.

Maybe it could be argued the name of the package implies some of this though, I guess that's how the OTel maintainers think about this.

[julealgon]

Unfortunately renaming a package is certainly puts a burden on consumers since it requires a manual migration for continued features/fixes, so it would be up to the maintainers of each contrib package if they want to do it.

Fair enough. Hopefully they realize the sooner such unification change is made, the less impact to consumers there will be. The more you wait, the more people there will be who would've taken a dependency on it thus making it much more painful of a switch.

I don't feel too strongly either way, but I think there's some value in having Contrib in the name. The SDK itself (OpenFeature) has no dependencies and is owned by the OpenFeature maintainers (it's likely additional "core" packages like this will be published). Artifacts in the contrib repos are stewarded by the OpenFeature maintainers as well, but especially for components that involve integrations with 3rd party tools or vendors, we rely heavily on those who contribute the components to keep them up to date from a feature perspective. They also frequently have a transitive dependency on a particular vendor SDK, etc.

To put it another way, we take responsibility for the packaging, security, and hosting of these contributions, but not the continuing development of their feature sets; I think Contrib might be a good indicator of this difference.

Maybe it could be argued the name of the package implies some of this though, I guess that's how the OTel maintainers think about this.

My argument is pretty simple on this: removing the "Contrib" part from package names just makes everything much simpler for consumers. I don't particularly think it is important for consumers to know whether a package is from the main or the contrib repo by looking at the package identifier: at the end of the day this is much more of an implementation detail than anything else. Besides, the repository information is already part of the package metadata, and users can follow the links from there to the repo.

Additionally, one thing the OTEL community did quite a bit was move code around between the main and contrib repos, while keeping everything else the same. This would be impossible if the "Contrib" marker was hardcoded in the package name: a decision to move it around between main and contrib repos would result in a need to rename the package, which we all know causes a lot of churn for users.

It sounds from your description, that the structure OpenFeature uses is very similar to the one for OpenTelemetry (in terms of ownership, maintainability, vendor dependence, etc), so it would be nice to have some consistent naming approach as well across these repositories/packages for the benefit of the entire ecosystem.

[toddbaert]

Additionally, one thing the OTEL community did quite a bit was move code around between the main and contrib repos, while keeping everything else the same. This would be impossible if the "Contrib" marker was hardcoded in the package name: a decision to move it around between main and contrib repos would result in a need to rename the package, which we all know causes a lot of churn for users.

This is a good point, and something that's already come up for us. cc @austindrenski

It sounds from your description, that the structure OpenFeature uses is very similar to the one for OpenTelemetry (in terms of ownership, maintainability, vendor dependence, etc), so it would be nice to have some consistent naming approach as well across these repositories/packages for the benefit of the entire ecosystem.

This is certainly true.

[askpt]

@toddbaert What are your thoughts on this issue? Could you tell me what I should do? From the list, we can see that we have

• OpenFeature.Contrib.Hooks.Otel <- Will hopefully be moved to the main SDK repo
• OpenFeature.Contrib.Providers.Flagd
• OpenFeature.Contrib.GOFeatureFlag
• OpenFeature.Contrib.Providers.ConfigCat
• OpenFeature.Contrib.Providers.Flagsmith
• OpenFeature.Contrib.Providers.Statsig
• OpenFeature.Contrib.Providers.Flipt
• OpenFeature.Contrib.Provider.FeatureManagement
• OpenFeature.Contrib.Provider.Statsig <- this should be unlisted
• OpenFeature.Contrib.Providers.EnvVar

Let's mark as complete on this list, as we are okay with the naming. Until we finish this issue, #195 is blocked.

[guidobrei]

Is the *.Contrib.* in the package names conveying any useful information?

[julealgon]

Is the *.Contrib.* in the package names conveying any useful information?

This is definitely a good point. I personally think it should be dropped. It actively hurts discoverability. The fact that they are in separate repositories or forks should be enough to differentiate them from "non-contrib" but this does not at all need to be reflected on package names or namespaces.

If you want a good example of this, take how Serilog handles all of its ecosystem. It's not a perfect library by any means, but the way it manages package names consistently is above average.

A sizeable portion of Serilog packages are "contrib", but they still follow the standard naming convention as any other extension.

Another set of libraries that does this well is OpenTelemetry, where only the main namespaces matter and the fact that a package is community-driven or vendor-driven is irrelevant to its naming scheme.

[toddbaert]

I'd be OK with just Provider or Providers.

[guidobrei]

Now that I read through the whole conversation again, I see this was the original point you've brought up @julealgon.

First, I was more paying attention at the naming inconsistencies brought up today in the community meeting by @askpt . We have Providers with package names *OpenFeature.Contrib.Provider, OpenFeature.Contrib.Providers, OpenFeature.Contrib. This should be consolidated as well. I was wondering if we now want to change names, should we also rethink the Contrib slug.

[guidobrei]

I'd be OK with just Provider or Providers.

Now the question is singular or plural?

I'm a little torn. Personally, I'd go with the singular Provider term, as a package represents ONE Provider.
Not sure how this affects Hooks packages because there could be multiple hooks in one package.

[guidobrei]

Other question:

Do we care about alignment between different languages?

In Java e.g., we use dev.openfeature.contrib.providers consistently.

[julealgon]

I'm a little torn. Personally, I'd go with the singular Provider term, as a package represents ONE Provider.
Not sure how this affects Hooks packages because there could be multiple hooks in one package.

I would actually recommend plural for both regardless of how many of each each package has. The idea is that you are adding to a general, well-known namespace that expects there to be multiple of them by design.

Namespaces should usually be driven by the main abstraction and not by the individual packages themselves.

[askpt]

At this point, we should decide and document what approach we want for the future. Both methods are valid, and we should choose one and go ahead.

1. OpenFeature.Providers.* | OpenFeature.Hooks.*
2. OpenFeature.Contrib.Providers.* | OpenFeature.Contrib.Hooks.*

I prefer the 1. As pointed out, it makes it easier to move between repositories if needed, plus other advantages have already been pointed out.

When we make a decision, we should do it library by library and wait for the assigned contributor to approve. When we push it to NuGet, we should deprecate it similarly to this library: https://www.nuget.org/packages/OpenTelemetry.Contrib.Extensions.AWSXRay.

If no one has objections, I will create the sub-issues to tackle this next week.