6 Things I Learned About OpenTelemetry Contribution (That the Docs Won't Tell You)
If you’ve been waiting for a sign to start or restart contributing to OTel, this is it! 💖 ✨
💌 Hey there, it’s Elizabeth from SigNoz!
This newsletter is an honest attempt to talk about all things - observability, OpenTelemetry, open-source and the engineering in between! We at SigNoz are a bunch of observability fanatics obsessed with OpenTelemetry and open-source, and we reckon it’s important to share what we know. If this passes your vibe-check, we’d be pleased if you’d subscribe. We’ll make it worth your while.
This blog took 6 days and 7 hours to be curated, so make sure to show some love!
Contributing to open-source can be overwhelming at first, and it’s okay to feel a little lost when trying to navigate your way through it. OpenTelemetry is one such open-source project under the CNCF [the second-largest, to be precise].
With over 200 contributors, it’s doing really well and is growing fast. I’ve been part of the community [and advocating its adoption!] for a while and see many people who wish to contribute to the project asking for tips, guidance, and direction in the Slack channels. There isn’t a lack of resources in this aspect, but it could be a bit scattered across a dozen different repos and docs. This blog is an attempt to bring all the resources you need to get started in one place, in a capsule.
I’ve been following Diana Todea’s journey very closely for a while, and recently she won the OpenTelemetry Community Awards at KubeCon, NA 2025. So my obvious next step was to hop on a call with her and gather as many insights as I could! Between our conversation and her own recent writings, I’ve distilled the best insights on how you can move from a lurker to a contributor.
I am also addressing a problem here: While many folks want to contribute, there is a shortage of folks who actually make it to their first PR, and even fewer who consistently continue to contribute and stay active. I’m writing this to address both hurdles, helping you get started and find a reason to stay.
So, if you’ve been waiting for a sign to start or restart, this is it. 💖 ✨
#1. What’s the first step I should take?
Kudos to you for taking the first leap. You can start by joining the CNCF Slack channel [of which OTel is a part] and come say hi in the #hallway channel. Here are some examples.
You can also follow suit and introduce yourself. Next, since contribution is the primary goal, here’s the official documentation outlining key aspects you should know. The next step you could take is try finding a good first issue from this list.
You can also check out CLOtributor, which helps you find good first issues across a number of Cloud Native projects. Here are some channels you can join initially. [as per Diana’s blog]
#otel-sig-end-user, #otel-devex, #opentelemetry-new-contributors, #otel-contributor-experience, #otel-docs-localization
But now you could run into your first dilemma. Let’s see how to get over it.
#2. I can’t find a good first issue, wtd1 ?
Finding a good first issue is indeed a task in its own. Most of them could already have been picked up by someone, and there could be active discussions around them. Because these issues are beginner-friendly, they are highly competitive and often claimed within hours of posting.
If this is the case, you can shift your strategy. While these issues are great for a quick win, they rarely help you build the rapport/ relationships or architectural understanding necessary for long-term contribution. This is why the Special Interest Group [SIG] model of OpenTelemetry Community is so important.
You can always start small, by being an active part of the community, including SIG calls and discussions in the corresponding channels, and by trying to make yourself useful with ad hoc tasks.
#3. I made a PR, not getting any reviews, wtd?
Give it some time.
Most maintainers have a day job in addition to maintaining the project, so small delays can occur. You can always post a message in the corresponding Slack channel with enough context so that anyone can pick up the review task. Here’s an example.
#4. I want to contribute, but non-technically, wtd?
The good news is you are in high demand!
There’s a lot of work that is not coding that could use a lot more hands on deck. Some means of contribution include documentation and blogs. You can find ways to improvise existing documentation or add new ones. You can also join the End User Working Group [EUWG]. They are constantly looking for people to share implementation stories, conduct user interviews, or improve feedback loops between vendors and users. The Merge Forward is another initiative that focuses on diversity and inclusion, and needs allies to help run mentorship programs and community events.
If you’re the kind of person who likes helping others, you can contribute by simply being active in forums or Slack to answer questions from newer users. Helping troubleshoot issues or explaining concepts in the Slack channels or GitHub discussions is a valuable form of contribution, too. So, by being a friendly helper in the community, you’re contributing to the project’s success, and you might build a reputation for yourself along the way.
If you’re interested in the process side of things, OpenTelemetry, being a pretty huge project, has many SIG meetings, public notes, and release planning. You could volunteer to help with note-taking in a SIG meeting, or assist in organising community events like the OpenTelemetry Community Day at KubeCon. The Contributor Experience SIG focuses on improving the project for contributors; they might have initiatives you can join, even if you’re not contributing code.
Another piece of good news is that you can always switch tracks or do both code and non-code contributions. In our call, Diana emphasised that a contributor’s journey can be very fluid; you might start with documentation because that’s what you’re comfortable with, and later move into code as you learn more, or vice versa. The path you choose initially doesn’t lock you in; all contributions count, and in a project as broad as OpenTelemetry, there is a need for a diverse set of skills, which can be the best launchpad for you [if you utilise them well!].
#5. How to contribute actively and remain consistent?
Here’s something harder than getting your first PR merged. Staying consistent and active in the community. Many, many people drop off after a couple of contributions. Here’s when consistency and discipline come into the picture, much like hitting the gym 😅.
Consistency in open source comes from aligning your contributions with what genuinely excites you. You have options to choose from, ranging from whether it’s a SIG you’re passionate about or a specific skill you want to grow. Set a realistic routine, such as contributing weekly or monthly, and stay connected by attending SIG meetings, tracking GitHub updates, or staying active in Slack.
You can stay in the loop by attending the bi-weekly SIG meetings for your area, even if just as a listener at first, or by joining community calls.
As Diana puts it, when something triggers you and helps you learn, it becomes easier to show up consistently and enjoy the journey. And, like everything else in life, motivation is intrinsic and should come from within. 🧘♀️
#6. Ok, but what do I get out of this?
Trick question.
Contributing to OpenTelemetry or any open source project, for that matter, is indeed an investment of your time and effort. The good news is the ROI2 can be huge, both personally and professionally.
Today, OpenTelemetry sits at the forefront of observability. By contributing, you’ll gain a much deeper understanding of how instrumentation, tracing, metrics, and related technologies work under the hood. As you debug issues or implement features, you’ll inevitably learn a ton about distributed systems, telemetry data, and best practices in cloud-native architectures from the industry’s best people! You’ll also be interacting with engineers from many companies [since OpenTelemetry has contributors from Lightstep, Google, SigNoz, and dozens of organisations]. These connections can lead to job opportunities or collaborations in the future. Many contributors find that being active in open source eventually opens multiple doors.
Many people also contribute out of a passion for the technology and the ethos of open source; if you’ve benefited from free software, there’s a gratifying element of paying it forward. That motivation can be very fulfilling in itself.
Some areas that could use more help
OpenTelemetry is a broad project with many moving parts, and naturally, some parts of it have more active contributors than others. If you’re looking to make a real impact and perhaps have an easier time finding issues to tackle, it helps to know which areas are currently under-resourced. Based on community insights and what maintainers have pointed out, here are a few areas in need of more contributors:
Documentation Localisation: As Diana mentioned, translating docs is a major need. Some language communities, like Japanese and Chinese, have been very active in translating OpenTelemetry docs, but others have barely started. If you are fluent in any language besides English, you can make a big difference by contributing to localisation efforts.
Language SDKs with smaller teams: OpenTelemetry maintains SDKs for many languages. Some of these, especially the most popular languages, have large contributor teams, but others could use help. For example, newer or less common language implementations might have only a couple of maintainers. If you happen to know a language like PHP, Ruby, Erlang, or Rust, those SDKs might appreciate extra contributors to help fix bugs and implement new features to catch up with the latest spec.
eBPF Instrumentation [OBI]: One of the newer frontiers in OpenTelemetry is the eBPF auto-instrumentation a.k.a. OBI. This allows automatic telemetry data capture at the kernel level without modifying application code. If you’re interested in low-level programming or Linux kernel tech, the OBI project would love some help!
Being part of the community and taking on responsibilities is as simple as sending an intro message to any SIG or channel you’re particularly interested in and asking if you can help out with anything. It can be as easy as the screenshot below! Thanks to the amazing community made even more welcoming by the great people in it!
So go, and make a change!
Feel free to check out our blogs and docs here. Our GitHub is over here, and while you are at it, we’d appreciate it if you sent a star ⭐ our way. You’re also welcome to join the conversation in our growing Slack community for the latest news!
wtd: just an acronym for ‘what to do?’ much like this emoji 🤷♀️
ROI: Return On Investment
A really helpful and thoughtful piece... welcomed!