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.