Beyond the good first issue - How to make your contributions sustainable
Contributing to OpenTelemetry isn't hard because the code is complex. It's hard because the project spans 11 SIGs, hundreds of repositories, and a specification that's still evolving while production systems already depend on it. You can knock out a good first issue in an afternoon, but sustainable contribution requires understanding how the pieces fit together and where your work actually matters.
The specification versus implementation gap trips up most newcomers. You might fix a bug in the Java SDK only to discover the behavior you "fixed" is actually spec-compliant, and it's the spec that needs changing. Or you'll propose a feature in the Python instrumentation that conflicts with semantic conventions still under discussion in the spec SIG. The fix is tedious but necessary: before touching code, trace the feature back to its spec definition. Check if there's an open OTEP (OpenTelemetry Enhancement Proposal). Grep the spec repository for related issues. This reconnaissance work feels like procrastination but saves you from having PRs rejected after days of work.
Repository topology matters more than you'd expect. The collector has a contrib repository with 90-plus receivers, processors, and exporters. Making a change that touches the core collector means coordinating with the collector SIG, but adding a new receiver in contrib has different review requirements and release cycles. Similarly, language SDKs have varying maturity levels. The Java and .NET implementations are stable and feature-complete, so contributions face higher scrutiny. Python and Ruby are still filling gaps in auto-instrumentation, making them more receptive to new work but also more likely to have architectural discussions that block your PR.
Community dynamics operate on multiple timescales simultaneously. Specification changes move slowly by design, often taking months of discussion across SIG meetings and GitHub issues. SDK implementations move faster but still coordinate quarterly releases. The collector cuts releases every two weeks. If you're trying to land a feature that spans these layers, you need to sequence your work accordingly. I've seen contributors burn out trying to push a collector feature that depended on spec changes still months away from approval.
The real leverage point is understanding what's actually broken in production. Instrumentation libraries have hundreds of open issues, but only a fraction cause real operational pain. Spending time in the Slack channels and reading postmortems reveals patterns: the Kafka receiver's memory leak under high partition counts, the OTLP exporter's retry behavior causing thundering herds, semantic convention inconsistencies breaking dashboard queries. These aren't tagged as good first issues, but fixing them builds credibility fast and gets your PRs prioritized.
Sustainable contribution means picking a specific problem domain rather than bouncing between random issues. Own the PostgreSQL instrumentation across languages. Become the person who understands OTLP protocol edge cases. Specialize in a receiver family. This focus lets you build context that makes future contributions faster and helps maintainers trust your judgment on design decisions.
The project needs people who can navigate the bureaucracy as much as it needs code. Understanding when to file an OTEP versus opening a PR, knowing which SIG owns a particular decision, recognizing when consensus is forming versus when discussion is stalled—these skills determine whether your contributions land or languish.