current state / feature parity with https://github.com/signalfx/splunk-otel-android

[cforce]

To the best of my knowledge, there has been an effort to integrate significant parts of the feature set from signalfx/splunk-otel-android into this CNCF-hosted OpenTelemetry project. However, I notice that there is still considerable activity on the signalfx/splunk-otel-android repository. I’m trying to understand the extent of feature parity between the two projects and how they are intended to coexist — whether they serve the same purpose or have distinct goals.

Since I couldn’t find any clear information on the signalfx/splunk-otel-android repository about its relationship with this project, I decided to open this issue. I’d greatly appreciate it if you could clarify the current state and future plans for these projects.

[aditi-s3]

Thanks @cforce for your question and interest

Long term goal:
OpenTelemetry-Android aims to provide a modular and customizable instrumentation framework, allowing developers to tailor the instrumentation to their specific needs and use cases. This flexibility is essential for adapting to various application requirements and integrating seamlessly with different backend systems.
Splunk-otel-android will depend on opentelemetry-android, but serve as the sdk specifically for Splunk’s Observability (O11y) platform. Its primary goal is to simplify the integration process for users who wish to leverage Splunk’s monitoring and observability tools, while utilizing OpenTelemetry’s capabilities.

Current State:
They are divergent until desired modularization, semantics, Kotlin based APIs (specific to Android platform) are added upstream (openetelemetry-android) . We intend to contribute and shape upstream and leverage the upstream capabilities in splunk-otel-android. Short-term they may diverge but intention is to converge long-term.

[breedx-splk]

Thanks @cforce for the inquiry and @aditi-s3 for the response.

The only thing I'd like to add is that I personally think that there's room for opentelemetry-android (and the other RUM/client libs for that matter) to be somewhat more opinionated in order to continue driving vendor-agnostic standards forward. There will always be resistance on some things (one size doesn't fit all), but I still think there's a lot of room to build and implement standards that work for most (simple thing made simple, complex thing made possible).