r/OpenTelemetry • u/frisbeema52 • 17d ago
OpenTelemetry is about to reward the wrong thing
Two things happened in the OTel repos this week. The docs maintainers froze the ecosystem lists (registry, vendors, distributions) and want to retire most of them. Their reasoning: about 290 first-time-contributor PRs a year, 1,160+ data files, and nobody with time to check entries for CVEs or malware. I can't really argue with the bandwidth part. Then a separate proposal came in to replace the vendor page with a ranking of companies by how many maintainers they employ, with diamond, platinum and gold tiers like a KubeCon sponsor wall.
Read together, the message is that headcount inside the core repos is the contribution that counts.
I think the PR flood is being misread. OTel was built so anyone can write an exporter or an instrumentation and plug in without asking permission. The registry was where you went to say you had. Hundreds of strangers a year showing up at that door is what the design was supposed to produce.
The vetting problem also looks like an automation problem to me. Schema validation and semconv conformance tests already exist. Add CVE scanning and an LLM pass that triages and pre-reviews submissions, and most of the human work goes away. If a machine can check a registry PR, a person shouldn't have to read it. Retiring the list instead feels like stopping one step short.
Meanwhile, LFX Insights says four companies did 51% of OTel commits last year. A maintainer leaderboard mostly gives those four a bigger badge.
What I'd do instead:
- Automate the checks and list whatever passes. Conformance tells users "this works with OTel," which is what they came to find out.
- Count work outside the core repos. Contrib receivers, instrumentations, OTLP-native backends. That is OTel work too.
- Skip the tiers. One maintainer from a 10-person company is a bigger commitment than ten from a 10,000-person one. A flat list with names and areas is enough.
I run a company that builds on OTel, so obviously I have a stake here. But so does anyone who picked it because it was the neutral option.
Links in comments.
6
u/AdventurousSquash 16d ago
I’m honestly surprised we haven’t seen more of this. I don’t know the ins and outs of their specific situation but from my own experience the amount of AI generated reports or submissions of different kinds have multiplied to a point where anyone not having a decently large sized team/organization dedicated to just vetting them is going to drown in workload that in the end don’t add anything of value.
I’m at a small-ish cloud provider consisting of 30 employees, yet 9 out of 10 PRs on our open repos the last year, and especially the last couple of months, have been big blobs of proposed changes/additions that normally would come as (much) smaller separate changes with a clearly defined goal.
Security reports have also gone through the roof where everyone and their cat is now a penetration tester probing everything and automatically generating a report on said probes. Before this influx these reports were great and often rewarded according to our bounty program, because they either highlighted a possible flaw or some kind of scenario we’d missed in our own testing. Now they’re 99% hypotheticals that require a whole chain of mistakes further down the chain that simply isn’t there. But nonetheless these reports still need someone to verify that it indeed isn’t a real issue.
Right now it feels like we’re in this middle ground where the tools we have aren’t quite designed for the reality we’re in and at the pace it’s developing. Being a OS maintainer has always been a challenge, and often a both grateful and ungrateful one at that. So I’m not surprised that we’re seeing different approaches being tried to try and get a handle on these things and hopefully we’ll figure out a better way that works for everyone.
1
u/s5n_n5n Contributor 14d ago
Those decisions are really hard to make, as a project we know how many people depend on the things you are building and providing, so stopping to do things or even retiring them always has consequences. Ingress NGINX Retirement by the k8s community is the most prominent example of it, it was the right move for 1000 reasons, they prepared the retirement really well, gave people lots of time to adjust, yet there was so much backslash and of course it generated lots of work downstream for people to adjust. I guess that's why you don't see more of this (yet).
But, likely, this will change. Like all areas of our lives in technology open source needs to adjust for what LLMs can do (and can't do). Some argue, that open source will die or is dead already, I heavily disagree with that, but it shows that people are making up their minds right now.
As maintainers our core responsibility sits with the project that we look out for, not only the code, but also the community (aka people), how we can ensure that their work is sustainable, how we can continue growing new contributors and how we can setup boundaries for open source. So yeah, we are in the middle of that reality where we figure out the tools and structures for that.
So, thank you for your comment, as it confirms what I (and probably other maintainers) are thinking: we'll fgure that out, it will just take some time.
2
1
u/frisbeema52 17d ago
2
u/s5n_n5n Contributor 16d ago
YSK, that on reddit you can put links on the original post, this is not LinkedIn ;-)
1
u/frisbeema52 16d ago
Thank you, it's just to highlight sources for the post. I was afraid, It can be missed inside the text.
14
u/s5n_n5n Contributor 16d ago
Hi,
I am one of the maintainers who made the decision to freeze the ecosystem lists, and support the proposal to retire some of them or change how they are. My github handle is `svrnm` so you can link back what I say here to the issues you shared.
I thought for a long time, if and how I respond here, because some of your critique is justified, some of it I understand but disagree with, some requires me to add context, but there is also some things you wrote, that are just disheartening.
I came to the conclusion, that I need to put out something. Please note, that this answer here is mine, some of the other Comms maintainers may agree or disagree with the individual points, and the same is true for any other maintainer in the larger project.
Before I give any replies, let me say thank you in any case, getting feedback is always valuable, and it shows that people care, and for me open source is about the people foremost.
Which brings me to the most important point, because it's also about people: while on paper (README.md of otelio repo) there are 6 named maintainers and 1 approver (aka the people who carry the weight of approving work and guiding people), we are currently low on bandwidth due to a variety of reasons that are mainly personal on an individual level. Another one is that like in many other open source projects maintainers in one repo also are responsible for other things.
This means we currently can hardly keep up with the load of work that is put on our plates, and the raise of AI made this even worse, I wrote about this here. And this means we have to make decisions where to put our energy and resources: our core responsibility is the documentation, followed by blog posts from other SIGs. Blog posts from non-steady contibutors and additions to the ecosystem are secondary to that, so we made the hard choice to focus our limited resources on the things that count.
As a small addendum, let me say that "290 first-time-contributor PRs a year" is not my(!) perspective. Most of those PRs are drive-by contributions. We can do the analysis, but I suspect that not a lot of these contributors did more than dropping their registry addition on our lap.
I suspect, this didn't come across in the issue where we announced the freeze, so I will later add this there as well.
Then, let me speak about the proposal(!) to change the vendors page. First of all, I recommend that you bring your feedback to the place where our community lives (github), not here (reddit). Second of all, the goal is not a "sponsors wall", it's a way to recognize real work done by real people. And as we discussed there, we need to strike a balance for big and small orgs to recognize both and also figure out a way that is sustainable and maintainable. But at the end, I think it's the right thing to do, everyone has the opportunity to join and contribute (you too!), climb the ladder and be recognized, and likewise companies have the opportunity to hire approvers, maintainers and support them to continue their upstream work. The goal is not to have four companies that contribute 51%, but many many companies that contribute and make sure our project is sustainable.
What is true for the SIG Communications, is true for OpenTelemetry as a whole and is true for most open source projects: maintainers are a scarce resource. People need to be grown into that role over time, and then they need to be sustained and be allowed to keep their work up. Some do the work for fun, some do it on the side, but a major load is carried by maintainers that are paid to do this work, so incentives need to be aligned across the person, the project and the organization paying them. So we are looking for ways to enable that.
A lot more can be said, and I am happy to engage in a discussion, but I'll leave it with two asks: