Registry: first-party field should be derived from the author info

[chalin]

@svrnm @cartermp @open-telemetry/docs-approvers - first-party in the context of the OTel org means owned and maintained by OTel, but that's not what I'm seeing in the registry entries. We shouldn't have a isFirstParty field, this property should be derived from the author information.

Related:

• This was prompted by my review of [registry] Add otelgoyek instrumenation library #6421, which @pellared has marked first-party
• Highlight first party ownership in the ecosystem registry #4795

[chalin]

Once we figure things out we should update the definitions in

opentelemetry.io/data/registry-schema.json

Lines 222 to 229 in 61efc46

	"isNative": {
	"type": "boolean",
	"description": "A flag to indicate if the entry is native"
	},
	"isFirstParty": {
	"type": "boolean",
	"description": "A flag to indicate if the entry is first party"
	},

[svrnm]

First party means that it is provided by the same organization (project or company) as the targeted "software", eg

• an instrumentation library for "foolib" is first party if it is by the "foolib" authors
• an collector exporter is for ACME's commercial backend is first party if it is provided by ACME

I don't think this can be captured purely from the email address of the author or from the GitHub handle.

[svrnm]

From my point of view things by us (otel community) are rarely/never first party

[pellared]

Also see

opentelemetry.io/templates/registry-entry.yml

Line 18 in 61efc46

isFirstParty: false # set this to true if "isNative" is set to false, but the plugin / instrumentation library is from the same vendor/project as the instrumented software

[svrnm]

maybe we should turn this into some kind of ENUM? not sure how to name it then

[cartermp]

I have always seen first party as being similar to "inherent", meaning that it's not a library you have to install so that you can instrument another library.

[svrnm]

I have always seen first party as being similar to "inherent", meaning that it's not a library you have to install so that you can instrument another library.

that's "isNative: true"

Just to fill in some of my thought process, since I introduced that field and replaced "thirdParty": we had a similar issue with "thirdParty" that it was not obvious who the first and third party is, a problem still not solved. What I wanted to have expressed in the registry are 2 properties (and then highlighted via badges):

• "native"/"out of the box"/"otel inside" (currently isNative) for anything that requires no additional dependencies to be installed, e.g. a library that takes direct dependency on the OTel API, or an application that comes with the OTel SDK built in, see https://opentelemetry.io/ecosystem/registry/?flag=native
• "first party"/"by the same org/company" (currently isFirstParty) for anything that requires an additional dependency but that dependency is provided by the same entity that provides "the target", e.g. the nginx module by F5 (see https://opentelemetry.io/ecosystem/registry/?flag=all&s=nginx), or the road runner PHP plugin(!) or instrumentation libraries by the author of the library (e.g. https://github.com/connectrpc/otelconnect-go)

The purpose of that is that "native" is the goal, but "first party" is an intermediate step (think an author wants to do otel but not yet the full way, so they create a plugin and later figure out that by taking direct dependency on the otel API they make things even better), so we want to promote both as a good thing (vs our community maintaining yet another component).

Both names are far from perfect, so if we have any good ideas how to name them properly, please suggest:)

[pellared]

For me the description and naming was clear 😅