I love OpenTelemetry, but for Java, I wish adoption would slow down until the implementation catches up.

For example, if you visit the OpenCensus site, it tells you on every page that OpenTelemetry is the way to go now. Yet OpenTelemetry's Java metrics implementation is still listed as alpha, and functionality as basic as tags didn't work when I last tried it.

Or, I've been working with Datadog lately, and I want to add dynamic span metadata. My options appear to be either to wire up the (deprecated) OpenTracing client, or set up a full collector/agent suite of OpenTelemetry processes (whose default tutorial configurations appear to be invalid in places).

worth I guess, but bumpier than I'd like.

Yeah, OpenTelemetry was OpenCensus, and before that it was OpenTracing. The go client faces some of the same churn; metrics are in alpha and the API isn't documented, though spans and traces are on more solid ground than the Java client it seems.

It's been a lot of change and I can't wait for things to settle down and for companies to stop trying to get their piece. I feel like everyone (Datadog, NewRelic, Google, etc.) saw Lightstep as a competitor and wanted to get involved with a competing spec, which is how we ended up in this consensus mess.

Still, it's good progress and it's so much better than raw logs. Would recommend.

Lightstep was one of the originators of the combined spec -- but yes, the churn has been really painful, and we're sorry for the pre-1.0 pain. Now that the spec is 1.0 and most of the language SIGs have put out 1.0 API/SDK releases for tracing, hopefully that pain will reced.

Do you have an insight on the timeline for stabilizing the metrics and logging specs?

Logging is still experimental in the spec. Metrics API is feature freeze and the protocol is stable, so it's more on language SDKs to stabilize their implementations. This is a focus for several of them right now.