Depuis des années, les équipes qui migrent des SDK fournisseurs vers OpenTelemetry se plaignent d'un sentiment de stagnation. Les outils des fournisseurs sont robustes ; OTel arrive avec des tampons expérimentaux et environ six façons de réaliser des tâches. Tout en maintenant un système indépendant du fournisseur, le support linguistique reste inégal. Golang et .NET dominent, tandis que d'autres prennent du retard. L'instrumentation automatique fonctionne jusqu'à rencontrer un obstacle abrupt nécessitant un travail manuel.

La perception de la communauté suggère une progression lente, mais les données révèlent un triple frein. Une barrière de stabilité binaire combinée à une petite équipe de mainteneurs crée une hésitation à marquer les fonctionnalités comme stables. Une fois déployées, les modifications deviennent impossibles, ce qui incite à des débats sans fin sur les problèmes potentiels dans des dizaines de langages.

Pour gérer la portée, le travail est divisé en Core et Contrib. Le Core gère des spécifications neutres et rigoureusement revues. Le Contrib couvre les intégrations à évolution rapide. Cette structure reflète le modèle otel-collector mais met en lumière la tension continue entre stabilité et expansion rapide dans l'écosystème d'observabilité. Les petites équipes manquent souvent de temps ou de budget pour cela.