Incentivize maintainership: opentelemetry.io page which celebrates companies that sponsor maintainers, and surfaces maintainership gaps

[jack-berg]

What

Add a new page to opentelemetry.io which celebrates the companies who sponsor maintainers and identifies gaps in maintainership:

• Count the number of maintainers by company, and group companies into tiers (e.g. diamond, platinum, gold, silver, contributing to take inspiration from KubeCon).
• Automatically update the page with a script running on a schedule.
• Have a section which lists the maintainer groups which are understaffed. This gives companies who want to raise their tier a way to identify areas in need of help, and gives individuals looking to become maintainers a place to find opportunities.

I wrote some scripts to produce a demo of such a page here. The companies are anonymized for now to decouple the decisions of "should we do this" / "how should we calculate it" from the emotionally charged bits of which companies end up in which tiers.

https://gist.github.com/jack-berg/813e747e76bd0609242a492e69c4f8bb

Why

This aligns the incentives of companies and the project. Companies that sponsor more maintainers get something material to show for it. The project needs more maintainers, and specific SIGs are understaffed today. Companies already spend meaningfully on conference sponsorship to signal their involvement in the ecosystem. This proposal channels that same incentive toward the work the project actually needs.

Open questions

There are of course of a lot of different ways to do this. Let's first decide if we want to do something like this: yes or no.

After, if we commit to doing it, we can argue about the details.

Listing some details here for sake of completeness, but I don't think we need to agree on them to agree that we should do something:

• Which groups count as maintainers?
• Do you count distinct maintainer persons or total maintainer positions?
• What are the thresholds for the different tiers? Are they integers or percentages? If integer targets, are they continuously re-calculated based on changing shape of project or fixed?
• Is the maintainer target count static across all repos, or should repos be able to contribute their own preference for what healthy looks like?
• What is the update cadence of such a page?
• How do we make this resistant to gaming?
• What is the source of truth for company affiliation? And how do we handle unaffiliated people (IMO they deserve extra celebration).

[svrnm]

As shared on slack, this was one of the loose ideas we had for the vendors' page when we froze the ecosystem section recently:

open-telemetry/opentelemetry.io#11377

@open-telemetry/docs-maintainers PTAL

A few thoughts/comments:

• overall I am a fan of this proposal, especially also listing the areas that are looking for support/help.
• what I am not so happy about is the "tiering" system, a small vendor with 10s of employees having 1 maintainer does "more" than a vendor with 1000s of employes having 10 maintainers. It skews the whole thing towards big companies. Maybe there is a lower bar like "at least 1 maintainer", but beyond that I would prefer having them all side-by-side. We could still list the number of people and the areas each company is contributing to.
• there might be non-vendor companies so what we had so far as "vendors" would go away and be replaced with "companies supporting otel" or a similar name

[jack-berg]

what I am not so happy about is the "tiering" system, a small vendor with 10s of employees having 1 maintainer does "more" than a vendor with 1000s of employes having 10 maintainers. It skews the whole thing towards big companies. Maybe there is a lower bar like "at least 1 maintainer", but beyond that I would prefer having them all side-by-side.

While its true that a smaller company sponsoring a single maintainer is spending proportionally more than a large company sponsoring a single maintainer, otel needs more maintainers in absolute terms. A flat "any-number-of-maintainers" system codifies an incentive to do the minimum. We need a system that encourages companies that can do more, to do more.

Nobody looks at the kubecon diamond sponsor list and expects to see a small company of 10 people. Expectations are tuned to knowledge about company size, and I think what people really notice is outliers. "company is huge and talks a big game but really doesn't help that much with maintenance" or vice versa "wow company is small but is really punching above their weight".

there might be non-vendor companies so what we had so far as "vendors" would go away and be replaced with "companies supporting otel" or a similar name

Yeah no need to emphasize companies selling o11y solutions - i.e. "vendors". Should just be "companies" or similar.

[svrnm]

flat "any-number-of-maintainers" system codifies an incentive to do the minimum. We need a system that encourages companies that can do more, to do more.

fair point. Although we also want an as diverse set of companies contributing, based on LFX Insights in the last year we had 4 organizations do 51% of the commits and a looooong tail of other ones doing a little bit.

So what we actually want is a little bit of both, we want the big orgs to be encouraged to do as much as possible, but we also want to encourage ANY org to do something and to have the feeling that hitting that bar is doable for them and at the same time worth it even if they are not "diamond".

Nobody looks at the kubecon diamond sponsor list and expects to see a small company of 10 people.

Will I agree with that point about users expecting big names up with "diamand" and small names down with "silver" it's also a prime example for the balance we need to strike, as I suspect that nobody scrolls down to that list of "silver" sponsors eventually. But that's maybe a good problem to have...

Saying all that there is a 3rd variable we need to balance: maintanability of this list. The more complex we make the rules, the harder it will be to keep that list up-to-date, fair and especially defensible. So, if we want to do this I think step one would be defining a minumum viable version and then evolve from there:

As a starting point we have the list of all members on the website, which is generated from github data about the different groups. It is currently not pulling any affiliation data, as this data is highly unreliable if you take it from github profiles. But since we only talk about maintainers for now, and since we need some form of "self reporting" anyhow, this might be something we can build upon.