OpenTelemetry (OTel) es el estándar abierto de observabilidad más ambicioso del ecosistema CNCF, pero su ritmo de avance genera frustración en los equipos que migran desde SDKs de proveedores. Este análisis examina por qué el proyecto parece no estar terminado a pesar de los años transcurridos y reúne datos sobre su estado real.
OTel nació con un objetivo claro: ser totalmente agnóstico al proveedor, un logro notable en un ecosistema tan lucrativo y disputado como el de la observabilidad. Sin embargo, esa neutralidad convive con un problema estructural. El proyecto soporta decenas de lenguajes y cientos de bibliotecas, repartidas entre un núcleo estable, revisado con rigor, y un repositorio "contrib" más amplio y rápido, donde aterrizan las integraciones experimentales. A esto se suma el otel-collector y el protocolo OTLP, cada uno con su propio ciclo de estabilidad.
El autor sostiene que el cuello de botella se explica por una combinación de tres factores: una puerta de estabilidad binaria que, una vez cruzada, convierte cada decisión en casi permanente; un banco de maintainers demasiado pequeño en varios SDKs; y un alcance desmesurado de lenguajes y frameworks. El resultado es un incentivo perverso: discutir indefinidamente los problemas teóricos de cada funcionalidad antes de marcarla como estable.
Para sustentar la hipótesis, compara 24 meses de actividad de OTel con proyectos como Envoy y Prometheus. Los datos muestran una concentración excesiva de commits, merges y cierre de issues en una o dos personas en SDKs como PHP y Ruby, mientras que Golang y Dotnet presentan una distribución más sana. En el extremo, depender de dos maintainers para cubrir un alcance de esa magnitud no es un proyecto saludable.
La conclusión es clara: OpenTelemetry no carece solo de más manos o más presupuesto, sino que su propio diseño —estabilidad rígida, alcance masivo y proceso de propuestas (OTEP) opaco en duración— multiplica la fricción. Mientras esa estructura no cambie, la percepción de lentitud probablemente persistirá.