Re-do vendors page & consider new adopters page

[svrnm]

A while back a discussion was going on over at the community repo about redoing the vendors page:

open-telemetry/community#984 (comment)

I just wanted to continue this discussion and also include the point that there's a need for a proper "adopters" page, right now the community page has this:

https://github.com/open-telemetry/community/blob/main/ADOPTERS.md

It's a mix of vendors and real end-users right now, but missing a lot of evidence especially for the vendors (is this another list of "we have SDK, Collector" or is it a "we dogfood" like honeycomb has it there with a blog post.

There's also this list in the ruby docs:

https://opentelemetry.io/docs/instrumentation/ruby/#whos-using-opentelemetry-ruby

Finally I miss a bunch of "adopters" like cri-o, sleuth, docker buildkit/buildx that started to build otel into their software (not sure if they are an adopter or if we need another term for that)

Not sure how to go about this, but I don't like how things look like right now and I think there's a great opportunity to promote otel outside of the list of vendors.

Tasks

• Major rework of ecosystem pages #3060
• Vendor page copyedits #3092
• Move Ruby adopters to data-driven list #3090
• ...

[svrnm]

Ok, there's of course also the page "integrations" on opentelemetry.io

[chalin]

If we redo the vendors page or table, IMHO it should be data driven.

[cartermp]

I would definitely say that we should split Adopters from Vendors.

or is it a "we dogfood" like honeycomb has it there with a blog post.

To be an Adopter you need to be using OTel within your own systems for observability purposes. And so anyone who's offering support for OTel but not necessarily using it internally would not be allowed. I think we should start with purging that list of all vendors just to be safe and then let them add themselves back in provided they offer a description of how they're using OTel in their own systems. I guess that's still just a trust-based system, but I'm going to assume nobody has malicious intent here.

[svrnm]

I would definitely say that we should split Adopters from Vendors.

or is it a "we dogfood" like honeycomb has it there with a blog post.

To be an Adopter you need to be using OTel within your own systems for observability purposes. And so anyone who's offering support for OTel but not necessarily using it internally would not be allowed.

💯
That's what bugs me about the Adopters list over at the community forum... it's misleading. I got people internally asking why we are not on that list and I pointed them to the vendor list (we do some dogfooding but there's no blog post on that)

I think we should start with purging that list of all vendors just to be safe and then let them add themselves back in provided they offer a description of how they're using OTel in their own systems. I guess that's still just a trust-based system, but I'm going to assume nobody has malicious intent here.

ACK, we can also ping the people who created the line on the page and ask them to validate (and give us what we want: link to the docs, etc.), give them some time to respond and then purge them.

[cartermp]

ACK, we can also ping the people who created the line on the page and ask them to validate (and give us what we want: link to the docs, etc.), give them some time to respond and then purge them.

Good idea overall. Although I think we still want to account for closed-source usage of otel. Not everyone gets to brag publicly about how they used OTel for regular product work :)

[chalin]

We're hitting silly table formatting issues for the Vendor table since it's being updating often enough. E.g., #2473 (review). And that complicates rebases.

This issue mentions more work than just making the vendor table be data driven, but might it be worth making the switch to a data-driven table now / soonish even before decisions are made about adoptors? If so, I can schedule some time soonish before another vendor wants to update the table :) ... WDYT @svrnm @cartermp?

[cartermp]

Yes, let's get this done ASAP. The vendors won't stop coming :)

[svrnm]

@chalin that's a great idea, let's do that

[svrnm]

this is completed