DataDog asked OpenTelemetry contributor to kill pull request
1–10 of 107 posts
Re: DataDog asked OpenTelemetry contributor to kill pull request
#2Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...
Re: DataDog asked OpenTelemetry contributor to kill pull request
#3Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...
Not sure I entirely follow what's going on here. Is there some context behind this that's useful to know?
Re: DataDog asked OpenTelemetry contributor to kill pull request
#4Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...
Not sure I entirely follow what's going on here. Is there some context behind this that's useful to know?
If I understand correctly, this is a receiver — which means you can take your existing DD instrumentation in their format and have it translated to OTel using this code.
It lowers the switching cost to get off of DD.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#5Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...
Not sure I entirely follow what's going on here. Is there some context behind this that's useful to know?
Wondered the same. Assume this is a threat to their business? An open source competitor can do something cool so they want to kill the functionality?
Re: DataDog asked OpenTelemetry contributor to kill pull request
#6Earlier quoted context omitted.
Not sure I entirely follow what's going on here. Is there some context behind this that's useful to know?
If I understand correctly, this is a receiver — which means you can take your existing DD instrumentation in their format and have it translated to OTel using this code. It lowers the switching cost to get off of DD.
And Datadog competitor Grafana sponsored it: https://twitter.com/boostchicken/status/1618692475845238784
Re: DataDog asked OpenTelemetry contributor to kill pull request
#7Tentative TLDR: It seems like DD pressured a contributor into not shipping a feature that would have made DD just another telemetry vendor.
It seems like right now, data can flow IN datadog libraries/agents but not out. This PR would sort of allow data to flow OUT of datadog's libs/agents?
And DD doesn't want that because it removes their lock-in power?
Is this correct? This would be extremely crappy of Datadog.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#8Tentative TLDR: It seems like DD pressured a contributor into not shipping a feature that would have made DD just another telemetry vendor. It seems like right now, data can flow IN datadog libraries/agents but not out. This PR would sort of allow data to flow OUT of datadog's libs/agents? And DD doesn't want that because it removes their lock-in power? Is this correct? This would be extremely crappy of Datadog.
[deleted]
Re: DataDog asked OpenTelemetry contributor to kill pull request
#9Earlier quoted context omitted.
If I understand correctly, this is a receiver — which means you can take your existing DD instrumentation in their format and have it translated to OTel using this code. It lowers the switching cost to get off of DD.
And Datadog competitor Grafana sponsored it: https://twitter.com/boostchicken/status/1618692475845238784
[deleted]
Re: DataDog asked OpenTelemetry contributor to kill pull request
#10Earlier quoted context omitted.
Not sure I entirely follow what's going on here. Is there some context behind this that's useful to know?
If I understand correctly, this is a receiver — which means you can take your existing DD instrumentation in their format and have it translated to OTel using this code. It lowers the switching cost to get off of DD.
Protect the moat at all costs!