the customers spending billions on the big cloud providers are entitled to much more rigorous and detailed reporting (incl historical data) for end-user-visible performance... I would much rather see the graphs in the article than a green check box (especially when things aren't actually very "green").
(disclaimer: I am one of the people who started opentracing)
Someone sent me this HN thread – nice to see the questions here!
OpenTracing has had a big end-of-2017 with support landing for various service mesh(es), bindings announced from some major vendors (newrelic and datadog), many community contributions in the "core" OpenTracing repos as well as integrations with numerous external projects, lots of uptake from companies large and small, etc.
"OpenTracing-compatible" is strict API compatibility in any supported language. The cross-language spec is "terminology-based" since it's, well, cross-language.
As an OpenTracing contributor, the core value prop still seems quite strong in that instrumentation of OSS dependencies is a massive pain point and should not be tracing-system-specific since it doesn't need to be. There is also value in common protocols and formats, and in that spirit there is interest in broadening scope to include those... though from seeing many companies adopt tracing tech, I haven't observed protocol compatibility as the main pain point or blocker.