To Upstream or Not?

Why Becoming the Maintainer of Your Dependencies Matters

Speaker: Christos Markou, Elastic
Date: March 26, 2026 — London

The Context

  • OpenTelemetry — vendor-neutral telemetry standard
  • OTel Collector is the core component
  • Vendors provide their own distributions (e.g., EDOT from Elastic)
  • Components are maintained by the community

The Deprecation Crisis

  1. k8sevents receiver marked for deprecation
  2. Argument: k8sobjects receiver would replace it (events are just objects)
  3. After deprecation — investment in replacement stalled
  4. k8sobjects receiver made too much noise, required complex transformers
  5. Situation was untenable for production users

The Response

  • Elastic got green light to invest in upstream
  • Created a dedicated issue for Kubernetes events
  • Drove discussion and pushed for consensus
  • Key argument: don't deprecate until replacement is ready
  • Same component later helped solve customer issues quickly

Roles in Open Source

Role Responsibility
Companies Fund development, shape roadmaps
Maintainers Maintain standards, review, approve/reject, long-term ownership
Community Users Surface bugs, edge cases, limitations

Maintainers are not gatekeepers — they govern the project.

The ingress-nginx Warning

  • ingress-nginx deprecation could have been avoided or delayed
  • The project was literally begging for maintainers
  • Companies that rely on OSS without contributing back risk losing critical components
  • Being present pays off

Key Takeaways

  1. Invest in your dependencies — it's not altruism, it's self-interest
  2. Don't deprecate until the replacement is actually ready
  3. Being an active maintainer lets you solve customer issues faster
  4. Open source sustainability requires corporate investment
  5. Contributing upstream is cheaper than forking or migrating

Questions?

KubeCon EU 2026 — London