I'm always willing to dogpile on DataDog (no pun intended), given bad experiences with their sales, but all I'm reading out of this is that the DD person didn't want to review it out of a potential conflict of interest. It was reviewed however by someone else. Am I missing something here?
DataDog asked OpenTelemetry contributor to kill pull request
51–60 of 107 posts
Re: DataDog asked OpenTelemetry contributor to kill pull request
#52I'm always willing to dogpile on DataDog (no pun intended), given bad experiences with their sales, but all I'm reading out of this is that the DD person didn't want to review it out of a potential conflict of interest. It was reviewed however by someone else. Am I missing something here?
You're missing that this was a year-old PR ready to merge but it was stopped from merging by DataDog because it makes it easier for users to migrate from DataDog to another logging service
Re: DataDog asked OpenTelemetry contributor to kill pull request
#53Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...
Is Mr boostchicken a DD employee? If so then this makes sense. Otherwise, it doesn't.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#54I love this bit:
> Hello, I'm using this receiver in production for about one year, and left some comments that may be helpful.
>> Are you serious? That is intense. Did it scale? Any memory issues? If I remember correctly I tuned all that away.
Always astonishing to see broken stuff doing well in prod lol.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#55Nice tool. A couple years ago I wrote a similar tool that translates Datadog's agent's metrics/checks into AWS Cloudwatch equivalents.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#56Tentative 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.
As far as I can tell literally no vendor allows data to flow out? What am i missing?
Re: DataDog asked OpenTelemetry contributor to kill pull request
#57From @mx-psi
> Speaking as a Collector contrib maintainer, I just wanted to say that I am not going to continue reviewing this PR or start reviewing other future PRs related to the Datadog APM receiver to avoid any semblance of conflict of interest given my role both as a maintainer on this repository and as a member of Datadog's OpenTelemetry team.
And from their GitHub profile:
> Open Source Software Engineer at Datadog , focusing on OpenTelemetry
What's the conflict of interest exactly? You work at Datadog, supposedly to work on OSS, with a focus on OpenTelemetry and you don't want to review Datadog related code for OpenTelemetry? Sounds weird, that kind of profile is exactly the type of person who should be reviewing the code, they have knowledge of both sides of it.
Rather, it sounds like Datadog is walking back and don't want to support OpenTelemetry if it means it'll support their own tooling, instead of just others.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#58Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...
Is Mr boostchicken a DD employee ? If so then this makes sense. Otherwise, it doesn't.
Seems they are not (Meta is mentioned on their profile), but it doesn't make sense either way. Datadog should not be pressuring either their own employees or others to add Datadog relevant collectors to OpenTelemetry, especially when their public position they put out is that they "love" and support efforts like OpenTelemtry.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#59Earlier quoted context omitted.
Not sure I entirely follow what's going on here. Is there some context behind this that's useful to know?
This comment highlights my problem with singular project tracking issues. Once they get so massive like this, people suddenly "can't follow along". Though not specific to GitHub but in this case the ui hampers readability and the comments are very much in-the-moment. This then leaves me to ask the questions, (a) should we stop writing such mammoth comments in issues or (b) should we leverage generative AI to summariz…
but if you're actively working on a problem you're in it, and the comments probably make sense. coming in from outside via web search or shared link, yeah, it's probably hard to jump in without full context of the lead up to it. once the problem is fixed, do you really care that much after the fact and have moved on?
Re: DataDog asked OpenTelemetry contributor to kill pull request
#60Earlier quoted context omitted.
OpenTelemetry basically allows for vendor neutral instrumentation for your metrics, logs, and traces. It makes it easy to switch to a cheaper or better service with minimal lock-in, which is obviously bad for DataDog and other companies business model
> It makes it easy to switch to a cheaper or better service with minimal lock-in Got any examples? I tried running my own "stack" for a project I wanted alerting on. I landed on Jaeger all-in-one (wasted time on Zipkin, the UI just was nowhere near as good as it ought to be) Docker container in docker-compose with COLLECTOR_OTLP_ENABLED.
I used the collector to proxy otel traces to jaeger zipkin for uniform istio tracing.