The first post in this thread was about why I keep saying yes to mentorship. The second was the playbook for mentees. This one is for the people on the other side of the table: the maintainers, the SIG leads, the engineers in companies that depend on a project and are starting to wonder whether dependency is enough.

The frame I’m borrowing comes from a piece my colleagues at Bloomberg published with the CNCF in March: Sustaining OpenTelemetry: Moving from Dependency Management to Stewardship (also on Bloomberg’s company stories). The phrase has stuck with me. It names something I’ve been trying to articulate for years, and gives me a concrete vocabulary for talking about what mentorship is for inside a project the size of OpenTelemetry.

From dependency management to stewardship

Most companies use open source the same way they use electricity. 1

You depend on it, you patch when it breaks, you grumble when an upgrade is painful, you upstream a fix when you absolutely have to. That’s dependency management: a relationship in which the project is something you consume.

Stewardship is the opposite stance. You don’t just consume the project; you take responsibility for the version of it that exists ten years from now. You pay for that version not just with code but with time spent growing the people who will maintain it. 2

The Bloomberg piece is making this case at the level of an organization. I want to make it at the level of a single SIG meeting.

A glimpse from the SIG room

In my field notes from OTel Unplugged EU 2026, the maintainer crisis came up in at least three rooms:

“Not enough maintainers, too many PRs, codeowners disappearing. The JavaScript SIG Special Interest Group — OpenTelemetry’s organizational unit, roughly one per language or component (e.g. SIG Go, SIG JavaScript, SIG Collector). has an automated script to move inactive maintainers to emeritus after three months. […] Some SIGs have tried a buddy/mentor system for onboarding new contributors — it helps, but it doesn’t scale across all SIGs when the existing maintainers barely have time to review PRs.”

And the line that stuck with me from those rooms:

“Maintainership is privilege AND responsibility.”

That tension (privilege, responsibility, not enough hours) is the texture of stewardship in practice. Mentorship is the mechanism by which a project produces more maintainers, not just more PRs. 3

Where mentorship plugs in

OpenTelemetry’s contribution surface is enormous: protocol specs, language SDKs, the Collector, instrumentation libraries, semantic conventions, and an exhaustive list of SIGs. New contributors look at that surface and freeze. Maintainers look at it and triage by exhaustion.

Structured mentorship (LFX, GSoC, Outreachy) works because it converts that two-way frozenness into a contract. The mentee gets a scoped problem, a stipend, and a guaranteed reviewer. The SIG gets a contributor whose entire job for 12 weeks is to make their problem smaller. Both sides agree to spend time on each other.

What I’ve seen work, and what I’ve seen fail:

What works

  • Tying mentorship slots to SIG roadmap items. The strongest LFX projects I’ve mentored were ones a SIG genuinely wanted done. The mentee’s work landed in a release. The mentee got reviewers who were already invested.
  • Pairing every mentee with two mentors. One technical, one navigational. The technical mentor reviews code; the navigational mentor explains why a particular working group meets on Tuesdays and how to ask a question without it sounding like a bug report.
  • Promoting good mentees into reviewers, not just contributors. The fastest way to grow your maintainer pool is to give the people you’ve already mentored a reviewer bit before they think they’re ready. 4

What doesn’t

  • Treating LFX as a free-labor faucet. A mentee is not a contractor. If the SIG isn’t prepared to spend a few hours a week on review, the mentorship will fail and the project will get a worse reputation in the next cohort.
  • Vague project descriptions. “Improve the X SDK” is not a project. “Add the W3C Baggage propagator to the Foo SDK with conformance tests against the upstream test suite” is.
  • Disappearing reviewers. I’ve watched cohorts stall because the listed mentor was on a release crunch and the buddy system never kicked in. Buddies need buddies.

Why this is the hard part

Many ways exist to “support open source” that look great on a slide and produce little. Sponsorship dollars. Logos at conferences. PRs filed by an engineer who already had everything they needed to file the PR.

Mentorship is the one that produces compounding returns and almost no easy metrics. It’s slow. It’s lossy: most cohorts produce one strong maintainer-track contributor, not five. It does not show up in the release notes. It does not have a nice ROI graph. It will not survive the first round of cuts in a product-led quarter unless someone with budget authority decides it’s a strategic choice.

And yet it’s the mechanism. The reason the projects you depend on still exist in five years is that someone, somewhere, in 2024, mentored the person who will be on call the night your service crashes in 2030.

Call to action — for maintainers and the companies they work for

If you maintain a CNCF project, or you work for a company that depends heavily on one, here is what I’d ask:

  1. List your project on the next LFX cohort. The intake portal is in cncf/mentoring. It takes a few hours to write up three good project ideas.
  2. Write project descriptions that name a real artifact. Not “improve X.” Name the file, the test suite, the missing feature, the open issue number.
  3. Commit reviewer time before the cohort starts. Block the calendar. Tell the buddy. The mentee will know within two weeks whether the project is real or a slot to be ignored.
  4. Promote your strong mentees into reviewer roles. The most consequential move a maintainer can make is making the next maintainer.
  5. If you’re an engineering leader at a company that depends on the project, fund the time. Stewardship that lives only on engineers’ weekends is fragile. Make it part of someone’s quarter, with a roadmap row and a name. 5

If you read this far and you’re already doing this: drop me a line. I’d love to compare notes on what’s working in your project and what isn’t. The most useful thing the CNCF mentorship community has produced isn’t the formal program structure; it’s the back-channel of mentors comparing notes after a bad cohort. That’s how the program gets better.

P.S. Doing my part

Since the call to action above was directed at everyone except me, a postscript on what I’m putting into this on my own end.

The current chapter: I work at Datadog APM on compile-time instrumentation, runtime profiling, and performance tooling for Go services. Most of that work happens in the open in Datadog/Orchestrion, which is basically melting into the upstream opentelemetry-go-compile-instrumentation project. As I write this, Dario Castañé and I are co-mentoring an LFX 2026 Jun–Aug cohort on exactly that surface; the framing lives in issue #446, and Part 1 and Part 2 already covered the project itself, so I’ll stop pitching it.

What matters more is the lineage. Before Datadog, I co-mentored on Thanos for a few years through the early LFX Mentorship cohorts (back when the platform was still branded CommunityBridge): the 2020 Q2 query-limits project and 2020 Q3–Q4 UI components with Bartek Płotka and Prem Saraswat; 2021 Spring multi-tenancy with @yashrsharma44; the 2021 Fall protobuf migration with Lucas Servén Marín and Giedrius Statkevičius; plus a GSoC 2021 Thanos TLS project. More recently on Prometheus: client_golang instrumentation work in LFX 2024 Mar–May with Arthur Sens, and prometheus/test-infra in LFX 2024 Sep–Nov with Bryan Boreham. Each was a different SIG, a different co-mentor, a different mentee picking up something that became a real piece of the project. They are all on cncf/mentoring if you want to read the project framings up close. 6

What sticks with me from those years isn’t any single PR. Some of those mentees are now maintainers themselves. That’s the loop closing: the thing Part 1 was really about.

This closes the series. Part 1 was the why. Part 2 was the mentee playbook. If any of the three landed for you, share it with the person you’ve been meaning to nudge into open source. That’s the mechanism.