The person you're replying to seems to have an idealogical bent against OTel. I'll say that "moribund" is about as unrealistic a term as it gets for OTel, given

The person you're replying to seems to have an idealogical bent against OTel. I'll say that "moribund" is about as unrealistic a term as it gets for OTel, given that it's now the #2 CNCF project by activity and still growing. That said, OTel is far from being easy to adopt still, and despite a lot of us trying hard to change that, it's got a long way to go. If you're using one of the "major" languages (Java, .NET, JS, Python) then it's pretty easy to set up automatic instrumentation and a Collector that you can tee off to your preferred backend analysis tool. But if you need more context from your apps, manual instrumentation outside of tracing is pretty hit-or-miss, and you need to build up a vocabulary around concepts (Resources, attributes, baggage, context, spans, etc.) that isn't easy unless you've got the time to sink into it. It's extremely powerful and has the building blocks to let you capture just about any data you need, pluggable processors and exporters, etc. -- but these building blocks are very unevenly composed into easy-to-use, turnkey-ish components that a lot of people ultimately want.