Description

embrace.io wishes to donate a Kotlin implementation of the OTel specification. This has been developed as a Kotlin Multiplatform Library and currently runs on Android, JVM, iOS, and JavaScript targets.

Modes

The project can run in two modes:

1. Compatibility mode: where the Kotlin API binds opentelemetry-java by calling an appropriate bridge implementation under the hood.
2. Implementation mode: where the Kotlin API runs the Kotlin implementation

Compatibility mode is primarily intended for folks who are already using opentelemetry-java on Android, but who prefer to use a Kotlin API, or as a bridge for users who want to migrate between the two APIs. Implementation mode is intended for everybody else, and particularly for anybody who uses Kotlin Multiplatform in Android/iOS mobile apps.

What is implemented?

The project has working implementations of the Tracing and Logging APIs. Some smaller features such as specific exporters or sampling are currently not implemented, but continue to progress every day.

Platform support

embrace.io has primarily been interested in targeting this library on Android as that’s our immediate business need. However, Kotlin Multiplatform does allow targeting Kotlin code at a variety of platforms & we have confirmed the project can run on a JavaScript & iOS targets although neither have been put into our production systems.

Given that Kotlin Multiplatform is becoming much more common in Android/iOS apps, we’re hopeful that this could be a useful solution for anybody who wants to write telemetry in one place and have consistent conventions & behavior between different platforms.

Benefits to the OpenTelemetry community

Kotlin is the de facto standard language used in modern Android apps & the OpenTelemetry project does not currently have a dedicated Kotlin SDK or API. Whilst Android developers could use opentelemetry-java via Kotlin’s interoperability, a lot of API design choices such as builders and thread-local context storage feel non-idiomatic when called from Kotlin.

Our hope is that developing a more mobile-friendly API will increase the adoption of OpenTelemetry on Android, and attract more engineers to the community who will have a client-side perspective on telemetry.

We also believe this would be a very useful addition for anybody sharing code using Kotlin Multiplatform, as it would allow them to capture telemetry consistently between different platforms.

Reasons for donation

We would like more folks to contribute to the project, and feel that donating to OpenTelemetry is the best way of achieving that. I also feel that diversity of opinion and interests will be helpful. For example, folks outside of embrace.io might have much stronger interests in developing support for different Kotlin Multiplatform targets, such as iOS/JavaScript.

Repository

https://github.com/embrace-io/opentelemetry-kotlin

Existing usage

embrace.io ships an Android SDK that allows developers to capture telemetry in their apps; opentelemetry-kotlin is used internally within this SDK. The library has been tested across millions of user sessions for several customers in this way.

opentelemetry-kotlin can run in two modes: by binding the opentelemetry-java API, or by using a Kotlin implementation of the OTel specification. The first mode has run in production & the second mode will do so in the near future.

Additionally, the API for opentelemetry-kotlin is exposed to consumers of embrace’s SDK, or anybody else who wants to consume the artifact from Maven Central. We don’t have insight into whether any folks have consumed the library in this way.

Maintenance

Currently three engineers from embrace.io (@bidetofevil, @fractalwrench, @priettt) are willing to act as maintainers.

We would be very happy to welcome maintainers and contributors from additional organisations. Our hope is that by opening this issue, individuals or organisations who are interested in maintaining this project will come forward.

Licenses

Apache 2.0

Trademarks

None, although the package namespace is currently io.embrace.opentelemetry.kotlin. We didn’t want to use the io.opentelemetry namespace until this project was officially donated.

Other notes

Longer-term we feel like the opentelemetry-android project should build on top of opentelemetry-kotlin rather than opentelemetry-java, mainly due to the mobile-friendliness issues previously discussed. This is something that we can talk through in more depth with the Android SIG. We recognise that there will probably be many things to discuss & change before that is a feasible option.

Hanson also gave a talk at OTel Community Day that gives some context on the ‘why’ behind this donation: https://www.youtube.com/watch?v=di5nhYvUh6w