Link 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.
Oh wow... I worked with Boostchicken at Sony. He's not at DataDog afaik.
DataDog asked OpenTelemetry contributor to kill pull request
61–70 of 107 posts
Re: DataDog asked OpenTelemetry contributor to kill pull request
#62I'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
Where did DD stop the merge. I just saw them simply state that the reviewer didn't want to review it as they work at Datadog. It could simply be that they are biased TO merge it even if it contains flaws. Having an independent reviewer ensures the code quality meets the bar.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#63Tentative 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.
None of the APM providers like New Relic, Data Dog, or Azure App Insights want a truly open ecosystem. The only reason they support "Open" Telemetry is because they're worried about lock-in at the data sources. For example, App Insights supports rich/structured telemetry via its proprietary SDK and various APIs. No open-source developer in their right mind would ever hard code such a proprietary dependency into somet…
100% disagree. I've talked with many of those providers and their CSuites are actually behind the open ecosystem. You forget many of them have huge marketshare to gain by having an open ecosystem
Re: DataDog asked OpenTelemetry contributor to kill pull request
#64I'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?
Re: DataDog asked OpenTelemetry contributor to kill pull request
#65Earlier quoted context omitted.
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
Where did DD stop the merge. I just saw them simply state that the reviewer didn't want to review it as they work at Datadog. It could simply be that they are biased TO merge it even if it contains flaws. Having an independent reviewer ensures the code quality meets the bar.
The OP didn't link directly to the comment and it's buried in the thread: https://github.com/open-telemetry/opentelemetry-collector-co...
Re: DataDog asked OpenTelemetry contributor to kill pull request
#66From @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 Da…
The potential conflict is that people might think/perceive DD to still be out to harm this project given their previous request for the author to stop development. Anything that might be regular code review or discussion for "why did you choose this approach" could be seen as sabotage on this super public issue.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#67How can DataDog threaten open source developers? Can they sue them? what is it?
Re: DataDog asked OpenTelemetry contributor to kill pull request
#68More vendor lock-in shenanigans. Data dog has always been a proprietary POS. I don’t know why people use it, APM traces? How long before Grafana has these capabilities in OSS? So annoying seeing a company like DD who cannot innovate at all, trying to lock in the average company.
> How long before Grafana has these capabilities in OSS?
They've already started down that path with Grafana Tempo[0]. It's functional, but their UX and discoverability need a lot of work.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#69Earlier quoted context omitted.
you may want to check out https://github.com/SigNoz/signoz I am one of the maintainers. We are building a DataDog alternative with native support for opentelemetry.
I have seen it around, but didn't know it was open source. If you guys are working on correlation, then I will definitely be watching this. Consistent link urls that can be shared is also useful. Hopefully someone else will contribute the notebooks feature. Those are very useful. Something that DD is not careful about, is being able to consistently use UTC for all time labels in all graphs (and maybe a quick way to c…
We use Datadog at the medium sized unicorn I work at. People often don’t understand how important correlating timestamps is. I wish Datadog was just opinionated as hell and said everything you see is UTC by default. Or even less dramatic than that, literally just slap the time zone on whatever it is that you’re viewing. It’s so insanely critical when you’re viewing logs on a prod outage that people immediately see and understand that the logs they are looking at are PST, CST, UTC or whatever. It’s insane that software designed to help people unfuck production systems doesn’t display that by default.
As-is we go through a song and dance whenever we look at logs and metrics “oh, this happened at X time which is Y time for most people.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#70[deleted]