On August 12, Mat Duggan published an analysis of OpenTelemetry's maintainer data that is hard to argue with, because it is mostly a spreadsheet. He counted who actually merges pull requests across the project's repositories over twenty-four months. The distribution is the story.
In opentelemetry-cpp, 544 merged pull requests passed through four distinct mergers, and 86.1% of them through one. Kotlin: 281 merges, two mergers, 79.7% concentrated in one. Ruby: 78.7%. Python: 486 merges, four mergers, 61.4% through a single person. PHP has merged 181 pull requests through exactly two people. Even semantic-conventions, the cross-cutting repository that everything else depends on for naming, runs at 49.7% top-merger concentration across nine mergers. For contrast, Duggan puts Prometheus at 14.4% across 31 distinct mergers on a larger volume of work.
Go and .NET look healthier, at 36.9% and 31.5%. So this is not a claim that OpenTelemetry is failing. It is a claim about where the load actually rests, and the answer is that in several important repositories it rests on one person's evenings.
Here is the part worth sitting with. This is not scope creep. OpenTelemetry did not drift into being large. It set out to support many languages, hundreds of integrations, and unusually strong compatibility guarantees, and it delivered on that. The strain is not the price of a project losing focus, it is the price of a project doing exactly what it promised. Features do not stall because contributors are absent or because technical discussion is dysfunctional. They stall because too few people are both qualified and authorized to make decisions the project has promised to support indefinitely.
So the problem is not that OpenTelemetry's maintainers need to work harder. It is that the project is underwriting an institutional commitment with individual effort, and no amount of goodwill closes that gap. What follows are four changes that would close it. None of them are novel. Every one is already running in another open-source project, which is the main reason to take them seriously.
Pay for maintenance, not just for features
Django is the clearest precedent, and the oldest. Since 2014 the Django Software Foundation has paid Django Fellows to provide consistent maintenance capacity. Fellows triage tickets on Trac, review and merge pull requests, act as release manager, handle release blockers and backports, monitor security reports, and answer contributor questions on the forum. It is a paid, full-time, one-year role, renewable on fundraising. Read that list again and notice how little of it is feature work. It is almost entirely the work that is necessary, invisible, and impossible to sustain on spare evenings.
The Python Software Foundation runs the same idea as Developers in Residence, covering core development, packaging, PyPI, security, infrastructure, documentation, and mentorship. Some of those positions are sponsor-supported, but the work is performed for the project rather than managed as a vendor roadmap. That distinction is the whole ballgame.
Rust is now building the most directly transferable version. Its Maintainers Fund, launched in June 2026, finances Maintainers in Residence to do large-scale refactoring, code review, unblocking new features, issue triage, and mentoring other contributors. As of the funding team's July progress update, published August 4, the fund had received $350,000 in donations and was structuring year-long contracts with an expectation, but explicitly not a guarantee, of renewal. Because the program is new, treat it as a promising experiment rather than a proven result.
What makes Rust's version the most useful model for OpenTelemetry is not the money, it is the published prioritization. The funding team's axioms, in their stated priority order, are: end-user impact first, dire needs first, fund what no one else will, scale to demand, and choose the shovel-ready work when priorities tie. "Fund what no one else will" is the one that would change OpenTelemetry's shape, because it points money at exactly the components a commercial sponsor has no reason to adopt.
OpenTelemetry could stand up an analogous Maintainer Fund under CNCF stewardship. Vendors and large adopters contribute unrestricted money, and an OpenTelemetry funding committee selects recipients against published criteria:
- End-user impact
- Maintainer and employer concentration
- Review and release delays
- Security and compatibility risk
- Absence of an obvious commercial sponsor
- The candidate's ability to mentor additional approvers
Applied honestly, those criteria do not point at the busiest repositories. They point at the struggling language SDKs and at cross-project work like semantic conventions, which is at 49.7% concentration and which every other component inherits. The loudest corporate constituency and the greatest structural risk are rarely the same place.
Pooling matters as much as the amount. Paying a maintainer through a single observability vendor preserves the labor while creating a reasonable question about influence, and that question does not go away just because everyone involved has good intentions. A neutral fund separates financial support from technical control, which protects the maintainer as much as it protects the project.
Build an apprenticeship, not a contribution drive
The standard response to a maintainer shortage is a push for more contributors. It is well meant, and it addresses the wrong bottleneck.
Attracting contributors and producing maintainers are different problems with different solutions. A maintainer needs technical depth, historical context on why the project rejected the obvious approach three years ago, community trust, and judgment about compatibility and scope. Those develop through sustained collaboration, not through a first patch. A burst of "good first issues" reliably increases contribution counts, and it just as reliably increases the review burden on the same one or two people already blocking releases. You can make the funnel wider and make the bottleneck worse in the same quarter.
LFX Mentorship already provides the infrastructure and the stipends for structured, time-bound open-source mentorship, and it has run cohorts since 2019. OpenTelemetry could use it for six- or twelve-month maintainer apprenticeships with an explicitly different objective than a normal mentorship. The goal would not be to ship a feature. It would be to rotate a participant through triage, review, release work, documentation, compatibility analysis, and incident response, with becoming a reviewer or approver as the stated deliverable.
One condition makes or breaks this: the mentor's time has to be funded or contributed by their employer. Mentorship is work, and it is front-loaded work. Asking an already overloaded maintainer to supervise three newcomers without reducing anything else on their plate makes the bottleneck worse before it gets better, and the maintainers most worth learning from are exactly the ones with no slack left. Any apprenticeship program that does not budget for the mentor is a plan to burn out the person you most need.
Make support levels reflect actual capacity
Duggan is right that presenting every language implementation as roughly equivalent creates expectations the project cannot consistently meet. A user picking an SDK from the docs today has no way to tell that one of them has six active approvers and another has one person merging four-fifths of everything.
The project already accepts the underlying principle for code. OpenTelemetry's 2025 proposal on stabilization and release practices calls for machine-readable stability metadata across repositories, distributions that ship only stable components by default with a configurable minimum stability level, and tested "epoch" releases assembled by a new Release SIG. That is the project saying, correctly, that users deserve to know what they are getting.
The same honesty should extend to maintenance capacity, because a component can be perfectly stable and still be one job change away from unmaintained. Each SDK or component could publish a support status against objective criteria:
- Sustained: Multiple active approvers, employer diversity, predictable releases, security coverage, and defined response expectations.
- Community maintained: Active and usable, but with no guaranteed response or release capacity.
- Seeking maintainers: Insufficient active ownership. Feature expansion paused while the project recruits or funds successors.
- Retiring or federated: Moving outside the core project, or following a documented deprecation schedule.
These labels describe project capacity, not software quality, and the difference needs saying out loud every time they come up. A mature Ruby library does not become bad software because it has one overstretched maintainer. The code can be excellent. What the label tells you is whether a compatibility fix will get reviewed this month and whether a security report will get answered, and those are things a user planning a five-year deployment has every right to know before they commit.
Support levels also give the project a rational way to reduce scope, which it currently lacks. Components without adequate ownership should stop accumulating unlimited new commitments. They can be frozen, moved to a separately governed ecosystem repository, or retired with a generous migration window. Scope reduction reads like retreat, but a component that quietly cannot be maintained is already a broken promise. Making that visible is the honest version.
Treat maintainer health like release health
Apache institutionalizes this through its Project Management Committees. A PMC is responsible not only for releases but for reviewing contributions from non-committers, nominating and electing new committers, mentoring contributors, and reporting on community health. And Apache sets a hard floor: a PMC must have at least three active members, because a formal release requires three positive votes. The governance requirement and the capacity requirement are the same requirement, deliberately.
OpenTelemetry could adapt that principle at the SIG or subproject level. Every critical component gets a minimum viable ownership group, and falling below that threshold triggers a defined response rather than a private worry:
- Publish the maintainer vacancy.
- Pause nonessential feature expansion.
- Identify and mentor likely approvers.
- Solicit time commitments from benefiting vendors.
- Allocate project funding if the component is strategically important.
- Federate or retire it if sustainable ownership cannot be found.
The mechanism already has a home. OpenTelemetry's governance charter makes the Governance Committee responsible to "ensure that SIGs maintain a healthy pool of maintainers and contributors and remain focused on their feature roadmap and deliverables." That responsibility exists on paper right now. A quarterly maintainer-health review, published like a release report, would turn it into an operational process with a number attached instead of a value everyone endorses and nobody measures.
What companies should actually contribute
Observability vendors have benefited enormously from OpenTelemetry. An entire product category now assumes it. Supporting the project should therefore mean more than sending an engineer to a SIG meeting, or funding development of the specific component a company needs shipped next quarter. Both of those are contributions. Neither adds redundancy, and one of them can consume review capacity rather than add it.
Companies should be able to make three kinds of visible, comparable commitments:
- Unrestricted money for independent maintainer positions, given without a feature attached.
- Named engineering time for review, release, and mentoring rotations, budgeted like any other assignment.
- Apprentices who are expected and supported to grow into upstream reviewers and approvers.
Publishing those commitments annually, alongside the maintainer-health report, would let the ecosystem see who is investing in shared infrastructure and who is drafting on it. That is a better signal than raw contribution totals, which measure how much a company wanted something built, not whether the project can survive that company losing interest. The standard applies to every organization shipping an OpenTelemetry-based product, and it is worth applying to yourself before you apply it to anyone else.
The goal is redundancy
The success metric here is not more pull requests. More pull requests is what the current system is already good at producing, and it is part of the load.
The metric is redundancy. A healthy OpenTelemetry component should be able to lose a maintainer, or an entire participating company, without reviews and releases stopping. Maintainers should be able to take a vacation, change jobs, or step away without feeling they have abandoned critical infrastructure that half the industry now depends on. Contributors should be able to see a credible, supported path from a first review to real project authority, rather than guessing at one.
Every proposal above serves that one goal. The fund exists so maintenance has a payer. The apprenticeships exist so authority has a pipeline. The support levels exist so promises match capacity. The health reviews exist so the gap gets caught while it is still fixable rather than after someone burns out.
OpenTelemetry has already built the technical standards and the governance structure for a remarkably ambitious project, and it built them faster than most people expected. The next thing to build is the labor institution that ambition requires: paying for invisible maintenance, funding mentorship, measuring succession, publishing honest support levels, and being willing to reduce scope where ownership does not exist.
OpenTelemetry does not need another appeal for heroic volunteers. It needs a system that makes heroism unnecessary.
This post responds to OTel Isn't Going Well (And I Made A Spreadsheet About It) by Mat Duggan, published August 12, 2026. All merge-concentration figures are his.
Is OpenTelemetry failing?+
No, and that is worth stating plainly. The project shipped the technical standards and governance for something genuinely ambitious, and several repositories, notably Go at 36.9% top-merger concentration and .NET at 31.5%, have a distributed bench of approvers. The concern is narrower and more specific: in a handful of important components, including C++, Kotlin, Ruby, Python, PHP, and the cross-cutting semantic conventions repository, review and merge authority rests on one or two people. That is a structural risk in components that the rest of the ecosystem depends on, and it will not resolve itself.
What is merger concentration and why does it matter more than contributor count?+
Merger concentration is the share of a repository's merged pull requests that were merged by its single busiest person. It matters more than contributor count because merging is the scarce permission. Anyone can open a pull request. Only an approver can decide it is correct, compatible, and safe to support indefinitely, and only a maintainer carries the release and security responsibility that follows. When concentration is high, adding contributors adds work to the bottleneck rather than relieving it.
Why not just have observability vendors pay maintainers directly?+
Some do, and it is better than nothing. The problem is that paying a maintainer through a single vendor preserves the labor while creating a legitimate question about influence over a project that is supposed to be vendor-neutral, and that question lands on the maintainer as much as on the vendor. Pooling unrestricted money through a neutral CNCF-stewarded fund, allocated by a committee against published criteria, separates financial support from technical control. Rust's Maintainers Fund is the closest working model.
Wouldn't publishing support levels scare users away from smaller SDKs?+
It would redirect some of them, which is the point. Users are already making that decision, just without information, and the ones who discover the gap during an incident have the worst possible experience of it. A published support level also does something a contribution drive cannot: it names the components that need help, which is the first step toward funding or staffing them. The labels must describe maintenance capacity rather than software quality, because a well-written library with one overstretched maintainer is still a well-written library.
How is a maintainer apprenticeship different from a normal mentorship or an internship?+
The deliverable. A normal mentorship produces a feature or a fix, and it is measured by whether the code shipped. An apprenticeship is measured by whether the participant became an approver. That changes the curriculum: instead of implementing one thing, the apprentice rotates through triage, review, release work, documentation, compatibility analysis, and incident response over six to twelve months. It also changes the budget, because the mentor's time has to be paid for or explicitly contributed by their employer, or the program simply moves load onto the person it was meant to relieve.
What can my company actually do about this?+
Three things, in rough order of how much redundancy they add. Give unrestricted money for independent maintainer positions, with no feature attached. Commit named engineering time for review, release, and mentoring rotations, budgeted like any other assignment rather than squeezed into the gaps. Sponsor apprentices with the explicit expectation that they become upstream reviewers and approvers. Publishing what you committed, annually, is what makes the difference between contributing to shared infrastructure and drafting on it.
