[Donation Proposal]: Dart SDK and API for OpenTelemetry

[michaelbushe]

Description

The donation consists of two closely-related Dart packages now published on pub.dev:
• dartastic_opentelemetry – a full OpenTelemetry SDK for Dart that implements all MUST, SHOULD and most MAY requirements of the specification (traces ✓, metrics ✓, logs coming).
• dartastic_opentelemetry_api – the stand-alone OpenTelemetry API for Dart, providing the specification-mandated no-op behaviour when an SDK is absent.

Together they deliver cross-platform OpenTelemetry support for servers, desktop, mobile, and (soon) web/wasm.
Both packages are released under the Apache 2.0 license, come with extensive unit-tests, protobuf stubs generated from the canonical OTLP definitions, and exporters for OTLP/gRPC and OTLP/HTTP.

We separated the API and SDK in two repositories for strictness. If the GC wishes to merge them into one, we are willing to do so.

Benefits to the OpenTelemetry community

This contribution fills in the only remaining language gap – Dart is the last top-15 language without an officially maintained OTel SDK; this donation brings parity with other ecosystems.

Moreover, Flutter, written in Dart, is the most popular cross-platform application development platform. This contribution covers only Dart. We will separately contribute a Flutter OTel SDK, which applies the Dart OTel SDK to Flutter applications, as we work on it's maturity and alignment with other OTel libraries for mobile development (Android, iOS). This contribution will aid Dart servers and pave the way to accelerates mobile & frontend coverage.

The contribution ensures spec compliance & governance – moving to the CNCF/OpenTelemetry org guarantees that future spec changes (e.g., Logs, Profiling) land quickly and consistently.

This contribution enables community growth – Dart and Flutter engineers can contribute under the same processes and CLA they already use for other OTel repos instead of an external project.

Reasons for donation

We are donating this Dart SDK:

• To avoid fragmentation: keeping a core language implementation outside the org risks divergent APIs and hindered spec evolution. There are multiple abandoned or failed OTel libraries currently in pub.dev
• To ensure long-term sustainability: CNCF governance, security processes, CI, and release automation provide guarantees a single-vendor repo cannot.
• To enable wider contribution & review from the OTel language-SIGs and spec authors, ensuring interoperability, compatibility test inclusion, and registry listing.

We contributed after review and discussion with César Munoz who leads the development of Android OTel SDK.

Repository

https://github.com/MindfulSoftwareLLC/dartastic_opentelemetry

Existing usage

Dartastic is being evaluated by a handful of large enterprises mostly Elastic customers.

Maintenance

The author & current sole maintainer is Michael Bushe (GitHub @michaelbushe)
Michael's company, Mindful Software, will dedicate Michael's time.

Mindful Software has created Dartastic.io to help fund maintenance through subscriptions to early access packages, support, consulting, training and a SaaS offering of o11y backends customized for Flutter.

Dartastic OTel development is also supported by SEMplicity, Inc., the largest Elastic consultancy.

We commit to follow OpenTelemetry CONTRIBUTING.md, triage SLAs, and attend SIG-language meetings.

Licenses

Apache 2.0

Trademarks

• “Dartastic” is an unregistered brand name of Mindful Software LLC; it is not a registered trademark. No transfer of trademark rights is required.
• We are willing to rename the packages to opentelemetry/opentelemetry_dart or opentelemetry/opentelemetry_api on pub.dev if the stale or abandoned placeholder package can be reassigned. We ask for GC guidance on this issue.
• We make no claim over the “OpenTelemetry” mark and will follow CNCF trademark policy.

Other notes

Though quite useful, this package is not 1.0 yet and there are holes we need to fill, like Zipkin. Logs are not implemented yet.

[austinlparker]

Thanks for opening this issue! Question - are you familiar with https://github.com/Workiva/opentelemetry-dart, and could you describe the differences between these implementations?

[alolita]

@michaelbushe Thanks for your interest in OTel. Can you share more details what your community looks like for this library?

[michaelbushe]

Thanks for opening this issue! Question - are you familiar with https://github.com/Workiva/opentelemetry-dart, and could you describe the differences between these implementations?

I am familiar. I was asked by a client - SEMPlicity, Inc, the largest Elastic consultancy - to write an agent for one of Elastic's large clients. I started to use the Workiva implementation. I noticed right away it didn't support gRPC and then noticed someone had contributed the implementation 7 months prior and it was left hanging. In fact the lead said there was no planned support for gRPC. That's pretty glaring, IMO, gPRC is not only the default but far more performant and that costs customers money and end users bandwidth. For other reasons as well , it seemed to me that the project couldn't be relied on, in fact there other forks of it, abandoned, in pub.dev. Also, real customers gave feedback that they were wary about using Workiva due to quality concerns.

Given that experience, I pitched to SEMplicity to make the Dartastic OTel SDK. My work is cleanroom and didn't rely on Workiva's though I might go back and review what they have to see if it has techniques that can improve Dartastic (like accurate web timestamps but I think Dartastic is ok).

I can't give you a rundown of all the differences but if you would like to see that, I can investigate that and report. At a minimum Dartastic implements gRPC and Workiva does not. I also noticed they didn't have proper separation between API and SDK and had some classes in the wrong layers, though I think some of that has been corrected.

There's also some niceties in Dartastic that I'm sure they didn't implement :

• factories at each level (API, SDK, Flutter) that allow implementation overrides to create a pluggable and extendable SDK.
• Semantic constants to reduce reliance on strings.
• Dart idioms that would not be found in other OTel libs - copyWith's, Attributes.of({'foo': 'bar', 'baz': 42})'s.
• intelligent defaults for service name, versions

[michaelbushe]

@michaelbushe Thanks for your interest in OTel. Can you share more details what your community looks like for this library?

This is a joint venture with SEMplicity, Inc. which will grow the community through the Elastic network (sales). SEMplicity already has 4 very large enterprises - in telcom and healthcare - that are evaluating it or have said they would. SEMplicity is working with Elastic and is in the process of making a EDOT - an Elastic Distribution of a wrapper OTel library, which is how they distribute and support all the other OTel libs.

I also expect to grow the community through Dartastic.io which will offer:

• early access to-be-open-source libraries, mainly Flutterrific OTel that applies the Dart SDK to Flutter and a nifty demo where I instrumented the popular Flutter Wondrous app. early access to integrations with popular Flutter libraries before they are open sources) and later, private libraries for native integrations (planned down the road).
• A Saas OTel backend with the choice of Grafana on a multitenant system at the Pro subscriber level and Elastic through SEMplicity, at the Enterprise level and, down the road, other backends. These backends will have dashboards that show the Flutter-specific metrics and conveniences to turn production errors into stack traces with code via uploaded symbol files (iOS, Android) & source_maps (Web), reducing MTTR and integrating with Dart CI/CDs.

I'm expecting to make instructional videos and present at conferences and Flutter Meetups, etc.

I'm a big believer in Flutter + OTel and expect to make this popular in a community that knows very little about it and has only proprietary services today (Sentry.io, mostly, also DataDog, others).

I greatly look forward to working with the developer community, working with issues inclusively, handling issues and PRs with high quality code and communication. I didn't build in the open at first because there's already a spec and getting my own mind around and flushing out my own idea was productive and I believe had a good outcome. As a lifelong meditator and Yogi, I don't hold onto ideas tightly and I am expecting significant changes as more developers get their hands on the SDK and provide feedback.

I'm expecting to build a big community and am hoping this is my last job, I have ten years or so until retirement.  😂🙏🏼

[trask]

hi @michaelbushe, thanks for opening this issue!

not necessarily relevant to this proposal, but I did want to make a correction since I've seen this come up elsewhere

gPRC is not only the default but far more performant

The default transport protocol (at least in the specification) is http/protobuf (not grpc), and the grpc protocol is not more performant compared to the http/protobuf protocol.

[austinlparker]

Thanks for opening this issue! Question - are you familiar with https://github.com/Workiva/opentelemetry-dart, and could you describe the differences between these implementations?

I am familiar. I was asked by a client - SEMPlicity, Inc, the largest Elastic consultancy - to write an agent for one of Elastic's large clients. I started to use the Workiva implementation. I noticed right away it didn't support gRPC and then noticed someone had contributed the implementation 7 months prior and it was left hanging. In fact the lead said there was no planned support for gRPC. That's pretty glaring, IMO, gPRC is not only the default but far more performant and that costs customers money and end users bandwidth. For other reasons as well , it seemed to me that the project couldn't be relied on, in fact there other forks of it, abandoned, in pub.dev. Also, real customers gave feedback that they were wary about using Workiva due to quality concerns.

Given that experience, I pitched to SEMplicity to make the Dartastic OTel SDK. My work is cleanroom and didn't rely on Workiva's though I might go back and review what they have to see if it has techniques that can improve Dartastic (like accurate web timestamps but I think Dartastic is ok).

I can't give you a rundown of all the differences but if you would like to see that, I can investigate that and report. At a minimum Dartastic implements gRPC and Workiva does not. I also noticed they didn't have proper separation between API and SDK and had some classes in the wrong layers, though I think some of that has been corrected.

There's also some niceties in Dartastic that I'm sure they didn't implement :

• factories at each level (API, SDK, Flutter) that allow implementation overrides to create a pluggable and extendable SDK.
• Semantic constants to reduce reliance on strings.
• Dart idioms that would not be found in other OTel libs - copyWith's, Attributes.of({'foo': 'bar', 'baz': 42})'s.
• intelligent defaults for service name, versions

Thanks for your response. I do concur that there appear to be several other opentelemetry libraries on pub.dev that aren't maintained, but the Workiva one does appear to be maintained and has an active user base. When investigating their GitHub, I didn't see any comments or issues from users about donating the library or other sort of governance-related things, although since it appears to be solely maintained by workiva, perhaps they don't have public meetings.

We've certainly fielded requests for an upstream Dart API/SDK implementation over the years, but given that there's an existing community implementation, it'd be nice if we could align these efforts somehow.

[michaelbushe]

hi @michaelbushe, thanks for opening this issue!

not necessarily relevant to this proposal, but I did want to make a correction since I've seen this come up elsewhere

gPRC is not only the default but far more performant

The default transport protocol (at least in the specification) is http/protobuf (not grpc), and the grpc protocol is not more performant compared to the http/protobuf protocol.

It appears I have some defaults to change, thank you. Makes sense due to the universal availability.

Perhaps from the collector's view HTTP is faster but from the client view latency and bandwidth are better with gRPC?

[tigrannajaryan]

Perhaps from the collector's view HTTP is faster but from the client view latency and bandwidth are better with gRPC?

IIRC, the OTLP benchmarks we did have shown that gRPC Unary has more overhead than plain HTTP due to extra operations to establish gRPC streams over which unary requests are sent. The difference is more visible for tiny payloads, anything largish is likely going to see negligible differences.

This was a few years ago, the latest implementations may exhibit a different performance characteristic.

[michaelbushe]

I created an issue in the Workiva project that asks about their plans for donation:
Plans to donate to OpenTelemetry?

[StephenWithPH]

To the extent that this new implementation has more features and more responsive maintenance, it will be quite compelling to me as an OTEL user (in other languages) and an OTEL needer in Dart.

---

I created an issue in the Workiva project that asks about their plans for donation:

If possible, it would be a very nice outcome to end in a place where the OpenTelemetry-endorsed Dart OTEL implementation lives on pub.dev at opentelemetry:

Today, Workiva's package is the closest thing to a de-facto incumbent.

Having said that, I sympathize with the fact that Workiva has a business to run, but there are telemetry features that would be very nice to see land! For example: Workiva/opentelemetry-dart#146 .

With regards some of the stale PRs (gRPC, proto), Workiva was handicapped by the Google-maintained Dart protobuf library; their 4.0 release roughly six weeks ago finally dropped support for Dart < 3; Workiva took that update fairly soon after.

I've been watching (and hoping) it would unblock Workiva in their library; Google's handling of Dart protobuf is a source of frustration in the Dart community.

[svrnm]

To link them here are previous discussions on dart:

• Dart support ? #552
• REQUEST: Consult on opentelemetry-dart #974

[svrnm]

I'm expecting to build a big community and am hoping this is my last job, I have ten years or so until retirement. 😂🙏🏼

It's great to read that you are invested into this project and are willing to spend significant time into it. Besides the technical questions, the community question is the one that carries the most risk: right now this donation comes with 1 maintainer from 1 organization (=you). Based on prior experience with SIGs/donations that didn't work out because of a low amount of contributors, or being mainly driven by one company, we need to up those numbers, that's another reason why we ask about other implementations!

It would be great to see more people & organizations to rally around this effort before we go into the donation process.

[michaelbushe]

Thank you. I appreciate the concern with single-maintainer donations.

This donation is backed by a partnership between three organizations:
1. Elastic
2. SEMplicitly, Inc., the largest Elastic consultancy, actively involved in supporting Dartastic for enterprise clients.
3. Mindful Software, my independent consultancy, which developed and supports Dartastic and is supported by Elastic and SEMplicity.

Dartastic.io will also support the ecosystem through paid subscriptions for early access, support, consulting, and training.

While I am currently the primary maintainer, these partners are invested in supporting its adoption and growth. Additionally, several large enterprises in healthcare and telecom are evaluating the SDK already.

As noted in the issue you referenced earlier #552, the real need is a Flutter SDK - given that over 95% of Dart usage is in Flutter. To that end, I’ve also built a Flutter-specific SDK (Flutterrific OTel), which I intend to donate after further maturing it.

Workiva's SDK does not integrate with Flutter per se, that's left to implementers.

Flutter creates apps for, and integrates with, iOS, Android, Web, and Desktop clients for Linux, Windows and Mac. A Flutter SDK in the OpenTelemetry family can drive consistency across OpenTelemetry client libraries in semantics and behavior across Android, iOS, browsers and desktop apps.

We will cultivating our community through:
- Providing a compelling Flutter SDK that nearly auto-instruments Flutter apps.
- Providing Flutter-specific OTel backends integrations - dashboards, error symbolization - that we expect to drive adoption.
- Building OTel integrations for Flutter packages (networking like Dio, routers like GoRouter & auto_router, etc.).
- Active outreach at Flutter meetups and conferences.
- Collaboration with Elastic and SEMplicity's enterprise users who can contribute feedback, issues, and possibly code.
- Public issue management
- Onboarding and mentoring new contributors.

[svrnm]

This donation is backed by a partnership between three organizations:

Can you elaborate on that? How many contributors will each of those organizations involve into the project? Ideally, can you ask them to come here and let us know about their commitment themselves and how it will look like?

Dartastic.io will also support the ecosystem through paid subscriptions for early access, support, consulting, and training.

Can you elaborate on the early access part? Assuming this donation is going to be accepted, would this mean that there will be an off-community version that will be ahead of the development that is going to happen in the public?

[michaelbushe]

Thank you for your time and questions.

George Boitano, SEMplicity's owner, told me yesterday he will comment on this thread.

I'm still the only contributor but we are just getting started. Of course I hope to attract many developers who can contribute to the project.

I'm aware of the monkey business that some companies have made with their OpenSource. I have a strong commitment to free and open source software and I will never waiver from it.

As I understand it, the way Elastic works is that they fork and wrap all OTel libraries to support their customers. The distros are called EDOTs (Elastic Distributions of OTel).

When Elastic comes to Mindful Software (=me and a team I build) for support, I'll work on the publicly available donated OTel project, out in the open and will review issues with the OTel community. Elastic will need to maintain their own fork from the public project(s).

Early access works like so:
I worked hard to make a solid Dart API & SDK and have it well tested (87% coverage). I didn't release it until it was good quality and had some outside validation. My view is that if I released it earlier, it would have been messy for others and a drag on delivery.

Now that the Dart API & SDK are in public, they stay there. There's no early access for the Dart SDK. All work will be done in the github project.

The Flutter SDK, which is a separate project that depends on the Dart SDK, is not yet publicly available simply because the quality isn't up to par. I expect it to be available in 1 or 2 months. I want to keep it under wraps because there's going to be churn, it's not well-tested, and there are big deviances to other OTel libraries - especially since I use short-lived spans for UIs (spans are supposed to be short-lived, says the docs) but other UI libraries use long-lived spans. These are problematic since, unlike servers, a user can flick away a mobile app leaving spans unended, which I understand is not good for backends, and which I had poor results with when I initially tried that route. It's Apache 2.0 so I can provide it if anyone wants it.

Once the Flutter SDK is stable, I will also donate it here. Likewise, that's when early access ends for the Flutter SDK. I also have a nifty demo, Wondrous OTel, where I forked and instrumented Wondrous. That will be open sourced at the same time (I don't think a donation is warranted for the demo.)

Other libraries will take the same route. Dart encourages lots of small packages and we will have many packages to integrate with popular Flutter libraries. Perhaps I will just build them out in the open, especially if the community grows quickly. My current plan is to start them privately in the same manner and then release. It's a personal flavor - I think the best work is done spending a long time in a quiet room. I also like to grok a problem by myself. I think the best aspects of the Dartastic SDKs might not have happened in committee.

Early access is a very minor part of this project and I'm willing to take feedback and adjust accordingly.