How to name 3rd party, non-contrib, packages

[aabmass]

Context

I have a few Google Cloud related packages (all):

• Currently using but planning on splitting into more packages
  • opentelemetry-tools-google-cloud
  • opentelemetry-exporter-google-cloud
• Not currently used, going to delete or re-use the package names though
  • opentelemetry-exporter-cloud-trace
  • opentelemetry-exporter-cloud-monitoring

In preparation for 1.0, I want to tidy this up. I am planning to split the trace, metrics, propagator, and resource detector into separate packages. Few questions:

Questions

1. Should I keep them named as opentelemetry-* or is that confusing since they don't live in contrib?
2. What should I call a package with a resource detector? opentelemetry-resourcedetector-foo?
3. How about the namespace package used in the code? Right now I am using opentelemetry.* namespace packages (e.g. opentelemetry.exporter.cloud_trace). Is that ok?

[lzchen]

For Azure, we are using azure-monitor-opentelemetry-exporter. This makes sense to a user, since "exporter" is the subject and the other words are descriptors. I think the it will be important to be consistent within your organization, for example, if you decide to do opentelelemetry-component-type-component-name then you should do so across all your packages. But, Google is free to use whatever convention they want, I don't believe there are any guidelines on naming from Opentelemetry side.

[owais]

What @lzchen said. It's gonna be hard to enforce a convention here in the broader community. FWIW, Lightstep also has a bunch of otel-launcher-<lang> packages, Splunk has splunk-otel-<lang> packages and I think AWS has "ADOT " packages.

[aabmass]

Is anyone using the opentelemetry namespace packages like opentelemetry.exporter.*? Maybe we want to be more opinionated on that since collisions could break the ecosystem

[owais]

I remember Nathaniel mentioned AWS was using or planning to use opentelemetry.sdk.* namespace but I cannot tell for sure if they did end up using it or not. Perhaps we can reserve opentelemetry.ext.* for external/3rd-party packages to avoid conflicts with official packages at least. People can use opentelemetry.ext.exporter.* instead of opentelemetry.exporter.* then.