Highlight first party ownership in the ecosystem registry

[codefromthecrypt]

Desired feature or idea:

Similar to how there is highlighting of code maintained by us, I'd like to see highlighting of first party ownership of instrumentation, exporters, etc in the ecosystem registry.

For example, this project is maintained by us

These two are maintained by the upstream project (first party), something you can tell by name comparison, but it isn't annotated otherwise

I'd love to see a stylesheet or otherwise change based on a flag in the registry data of "isUpstream" negate of "isThirdParty" or similar, so that end users can know something in the registry is authoritatively owned.

Additional context:

While it is easy to tell which instrumentation are done by us, it is not easy to tell which are done by the upstream owners. We make a call that is in my opinion correct, that the very first priority is that the instrumentation is upstream. By highlighting we encourage the same behaviors in our registry as our policy, and make it easier for end users to know if something is neither maintained by us, nor by the project owner. For example, they can prefer something that isn't a vendor-specific codebase which is neither subject to review of the target owners, nor ours.

[svrnm]

We have functionality it's just not enabled for all those upstream instrumentations, we can distinguish in the registry between "first party integrations" and "native":

first party example: https://opentelemetry.io/ecosystem/registry/?s=kafkaflow native example: https://opentelemetry.io/ecosystem/registry/?s=next.js

We also have the integrations page to feature those:

https://opentelemetry.io/ecosystem/integrations/

A piece missing is that this list of integrations shares the data from the registry, right now those are 2 independent data sets. We also leverage that second list to promote native (and only native) integrations on their language pages around libraries, e.g. https://opentelemetry.io/docs/languages/js/libraries/#use-natively-instrumented-libraries

All of this also has a dependency with this terminology discussion (and everytime I tried to improve the situation I struggeld with finding the right words): https://github.com/open-telemetry/opentelemetry-specification/issues/4089

So what can you do to help with that:

• Tag registry entries which are missing the native/first party flag
• Help to merge the data sources for integrations & the same data set in the registry
• Help to find better terminology by participating in the discussion mentioned above

[haidong]

Tag registry entries which are missing the native/first party flag

I'm working on this.

As of this writing, there are 761 files that miss the flag:

 data/registry   main ±  find . -type f | xargs grep -L -e "isNative" -e "isFirstParty" | wc -l                                                                                     
     761

Changing 761 files in one PR will be too much. I'll breakdown the 761 files into separate batches using alphabetical order, one PR per batch.

[codefromthecrypt]

@haidong thanks so much for pitching in on this!

[svrnm]

Hey @haidong

commented on your PR but adding the same here: what I was hoping for is a review of instrumentations (native and library) and apps and to verify if their instrumentation is first party means that it was created by the same org that provides the app or lib. Collector components are not part of that. Also components provided by the Otel community are not first party.

Apologies once again and thank you for your eagerness to help.