Cncf

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. ...

Last time I wrote about why I keep saying yes to open-source mentorship. This post is the how: specifically, how to be a mentee in 2026. I’ve spent the last few years on the mentor side of CNCF LFX LFX Mentorship — the Linux Foundation’s structured mentorship program. Cohorts run quarterly, projects are scoped to ~12 weeks, and mentees receive a stipend. , Google Summer of Code ( GSoC A Google-funded program where students contribute to open-source projects over the summer, paired with mentors from those projects. ), and GoBridge, through Thanos, Prometheus, and now OpenTelemetry projects. Every cohort I’ve run, the same questions keep coming up from people who want to apply but don’t know how to start. ...

There’s a moment that keeps happening to me. Someone I mentored two or three years ago shows up in a SIG call, on a maintainers’ list, on a stage at KubeCon. They’ve shipped something I couldn’t have shipped alone. They’re answering questions I once answered for them. And the part that gets me: they’re already mentoring someone else. That moment is the thing. why why It’s also the only honest answer to “why do you keep doing this when it’s not your job?” The loop closes, and you get to watch. ↩ Everything else I write here is a footnote to that moment. ...