Open Source Donation Plan

This article explains the donation process of dartastic_opentelemetry and dartastic_opentelemetry_api to the Cloud Native Computing Foundation's (CNCF's) OpenTelemetry project.

The OpenTelemetry Dart and Flutter SIG is looking to grow our community of Dart and Flutter developers interesting in contributing first-class observability for Dart and Flutter.

Interested in contributing?

Join the #otel-dart Slack
Watch or contribute to open-telemetry/opentelemetry-dart, dartastic_opentelemetry or dartastic_opentelemetry_api.

Michael Bushe created two OpenTelemetry SDKs that he's been working on since July 2024:

The dartastic_opentelemetry SDK, written in pure Dart, licensed under Apache 2.0.
Dartastic Native OTel, native binaries with a Dart facade, licensed under The Dartastic Commercial License.

The donation only applies to the public Apache 2.0 GitHub repos dartastic_opentelemetry and dartastic_opentelemetry_api.

Dartastic Native OTel will remain commercial.

The final entrypoint for Dart and Flutter developers be opentelemetry, and eventually, opentelemetry_flutter. The name is consistent with the OpenTelemetry standard. The opentelemetry package in pub.dev has been occupied with Workiva's implementation, which is no longer maintained. Workiva was kind enough to let the mature implementation be published to opentelemetry.

Currently, dartastic_opentelemetry beta releases are cross-published to opentelemetry, beginning with 1.0.0-beta.17, giving users an upgrade path. Workiva's current opentelemetry 0.18.0 will not break and be given and upgrade path with a migration tool publish to 0.18.0+2.

Goal and Commitment

The bottom line is the opentelemetry package is the entrypoint. Throughout the donation process and forevermore, users of dartastic_opentelemetry and dartastic_opentelemetry_api will always be compatible with and sometimes ahead of the standard opentelemetry SDK and API.

At the end of the donation, dartastic_opentelemetry will be downstream of opentelemetry and may have additional fixes that are contributed upstream. Dartastic support customers can rely on dartastic_opentelemetry, the open source SDK supported by Dartastic.io.

The larger goal is to have the highest quality and most compliant OpenTelemetry API and SDK of any language. We want to be better than the other 16. We may already be close to that goal. Gauntlet thrown!

Dartastic follows Quality-Driven Development. There's no timeline. There's no rush. The iron triangle collapses to one line - scope. The scope is clear - the OpenTelemetry specification. It changes but is not difficult to keep up with. There's no cost constraint - this is free work, we can't break a budget.
There is no time constraint, no deadline. When it's ready, it's ready. Quality is the only driver. In the meantime, the dartastic_opentelemetry package is available and continues to increase in quality.

Background

Workiva's `opentelemetry`

For many years, opentelemetry held Workiva's implementation. It was used by early Dart OpenTelemetry adopters but fell out of maintenance.

In July 2024, Michael Bushe attempted to integrate into a Flutter app. After seeing that it was falling out of maintenance, he embarked on implementing the OpenTelemetry specification, line by line.

2025: Donation Proposal

On May 6, 2025, Michael created a Donation Proposal Issue in the open-telemetry GitHub project.

Michael couldn't just dump a repo onto the project. A community needed to be built up around the project, with an OTel Special Interest Group (SIG) as stewards of it. Michael set out to build a Dart and Flutter OTel community.

Yusuf Rosman, who worked on Workiva's implementation, contributed early in a big way by providing the Logs Signal.

Creating a larger community took longer than expected since:

Flutter developers weren't very aware of OpenTelemetry. Flutter shops that used observability used proprietary solutions. It was difficult to find Dart and Flutter developers willing to work on the project.
A half-dozen billion-dollar companies contacted Michael inquiring when the Open Source work would be finished but none were willing to fund the work. A common refrain for open source development. So Michael stopped publishing new open source work and focused on building the commercial side: Dartastic Native OTel, Dartastic Observatory, Dartastic Pub, Dartastic Symbolizer, and Dartastic RUM. Michael finally published more of the Open Source work, when his consulting clients needed it.

2026: SIG Formation

On April 14, 2026, Google's Abdallah Shaban unlocked the project by his comment on the donation proposal:

Hi @michaelbushe - my name is Abdallah and I work with the Flutter and Dart teams. It would be great to chat about this effort - we are hearing pretty clearly from our community that this is a critical missing piece of the ecosystem. What is the best way to connect with you?

Google's Dart and Flutter Lead, Kevin Moore, reviewed the repos, made some critical contributions, and Michael re-engaged with the Open Source since it was clear, with Google's support, that the work was going to help the Flutter community.

Having sponsored maintainers and contributors is a requirement for forming an OpenTelemetry SIG. Michael found the minimal set of Flutter developers whose companies would sponsor their work, most notably, Robert Magnusson of Grafana and Benjamin Bennett of Embrace (now Palo Alto Networks).

With the critical mass, on June 11, 2026, Michael made the Dart and Flutter OTel SIG Bootstrap PR. On June 29, to enlarge the fledgling team, Michael made the PR that published the Call for Contributors. This added new developers to the effort, particularly Harshit Kushwaha who did yeoman's work.

For the next 3 months the community of contributors worked very hard to make dartastic_opentelemetry and dartastic_opentelemetry_api compliant with the OTel spec, closing almost 100 issues. As of this writing, we've made 11 beta releases as a team. The Dart and Flutter OTel SIG meets bi-weekly. Work is ongoing.

A New Home, a New Structure, a New Plan

Witnessing the progress, in October 2026, OpenTelemetry created a new repository for Dart and Flutter: open-telemetry/opentelemetry-dart

Each OpenTelemetry SIG has a liaison to the Governance Committee and the Technical Committee. The process for OpenTelemetry donation is to have it qualified by the Technical Committee. Compatibility is critical for OpenTelemetry. Quality is important for all software in wide use.

Instead of technically qualifying everything at once, liaisons and maintainers decided to break it up into bite-sized PRs.

A bare monorepo with scaffolding exists as of this writing. Though only two repos are going in, they will be broken up into multiple packages.

Packaging and Publishing Plan

The plan in brief is to ensure the highest quality donation, package-by-package while not breaking existing consumers. The Technical Committee can qualify each donated package as the others are being worked on.

The package layout and plan is defined in docs/design/packages.md follows. The table lists the packages in pub.dev that the donation will be delivered to, roughly in dependency order.

Package	Kind	Depends on	Notes
`opentelemetry_semantics`	Semantic conventions	—	Weaver-generated.
`opentelemetry_api`	API	—	Pure Dart, no `dart:io`. No-op by default.
`opentelemetry_sdk`	SDK	api	Exporter interfaces, processors, samplers, console + in-memory exporters, generic resource detectors. Platform-agnostic.
`opentelemetry_otlp`	Core exporter	sdk, protobuf, http	Protos, transformers, OTLP/HTTP (protobuf + JSON), config, gzip, user agent, cert utils, HTTP client factory. Web-safe.
`opentelemetry_otlp_grpc`	Core exporter	otlp, grpc	Split out so HTTP-only and web builds never see `dart:io`/grpc.
`opentelemetry_prometheus`	Exporter	sdk
`opentelemetry`	Dart entry point	api, sdk, opentelemetry_otlp	Re-exports api, sdk and protocols. `OTel.initialize()`.
`opentelemetry_flutter`	Flutter entry point	api, sdk, opentelemetry_otlp, Flutter	Re-exports api + sdk and protocols. `FlutterOTel.initialize()`, Flutter resource detection, lifecycle.

Quality State and Process

Semantics - Easy-Peasy

Semantics is generated from the OpenTelemetry Specification by Weaver. It's a well-worn path and with no dependencies. Delivering semantics first exercises the donation and publication process.

However, semantics just got harder - the OpenTelemetry community is moving towards federated semantics. GenAI semantics are already split out into their own specification. The Client SIG, with a close relationship to Flutter, is creating a multi-platform set of Client Semantics. The Dart semantics will be a consumer of federated semantics - it exposes all OpenTelemetry semantics to Dart and Flutter, and a producer - it will contribute semantics specific to Dart and Flutter, similar to how Android, iOS and Linux have defined platform-specific semantics.

The plan is to:

Deliver the common semantics like the dartastic_opentelemetry_api does today to the opentelemetry-dart repo.
Publish the semantics after review to opentelemetry_semantics.
Have dartastic_opentelemetry_api depend on the opentelemetry_semantics while removing the semantics it delivers today.

Semantics publication can then be automated and published separately as the common and federated semantics evolve.

API and SDK - Needs More Time in the Oven

Currently, Traces, Metrics and Logs are all late beta quality. There is 100% line code coverage for the API, 94.6% for the SDK. The packages have many integration tests against running otel collectors, and a Dart OTel Reference Demo that works.

That covers internal quality but external quality matters too. The packages have over 140,000 weekly downloads and there has been only one bug from the field - a significant performance issue with span id generation, which consumed 90% of the time to create a span.

That's good news and bad news. The good news is that the API and SDK are good quality, internally. The bad news is that even with 40,000 weekly downloads, a serious performance concern was not uncovered quickly.

The downloads have increased exponentially, so most usage is new. Also, most usage is on mobile apps where a millisecond span creation time is not great, but even creating 50 spans at once would not reach the level of human perception. On a server, it's much more significant.

In acceptance of a donation, OpenTelemetry looks for wide production use. The packages need more time to bake, be used more widely, and receive feedback on performance, functionality and developer experience.

While adoption grows, the team is focused on raising the internal quality bar, mostly by leveraging AI.

Both the SDK and the API have tracker Issues with a combined 130 AI-generated compliance gaps. These were created mostly with Fable 5 in July but using a combination of frontier models. The methodology is documented in the AI Shootout at the OTel Compliance Corral blog post.

Every detected gap that was turned into an issue has been reviewed by multiple humans and every one has been verified to be a valid compliance gap.

All the API tracker issues except one have been closed and delivered in API rc.4. They were integrated into the SDK and released as SDK beta.17.

The only API issue not closed is the AnyValue type, a significant update for a specification change.
The team is also tracking future specification updates and will update the published specification version the API and SDK adhere to.

The team is currently focused on the SDK tracker issues.

We will create more trackers by conducting multiple rounds of AI compliance reviews while getting more feedback from production users. We expect the number of issues to decrease as we approach specification compliance and to increase as frontier models improve. This is the second round of AI compliance issues for the API. The first round found only 4 issues which were quickly fixed and closed in June, compared to 26 issues for the API on the first round that used Fable.

Moving without Breaking Things

This pattern will be repeated for each package:

Qualify and publish the CNCF package.
Have opentelemetry and dartastic_opentelemetry depend on the CNCF package, re-export its symbols and remove the dartastic OSS code.

Supporting dartastic_opentelemetry Consumers

Eventually dartastic_opentelemetry will be a shell with only the OTel.* entrypoint. The final step for dartastic_opentelemetry is to make it downstream fork of opentelemetry. It will then be able to have additional fixes and be supportable by Dartastic.io.

Supporting Workiva's opentelemetry Consumers

Current opentelemetry consumers are at Workiva's release 0.18.0. To support those consumers and inform them of the upgrade path:

Dartastic.io will cross-publish releases to opentelemetry, equivalent to the dartastic_opentelemetry, with documentation informing consumers of the new SDK and the links to the opentelemetry-dart repo, and a link to this blog post that explains the plan.
Workiva will publish an update 0.18.1+2 documentation release, with links to the new repo and a migration guide.

Conclusion

Dart and Flutter are getting an official OpenTelemetry SDK, and it's being built on the work in dartastic_opentelemetry and dartastic_opentelemetry_api.

The plan is simple: deliver, publish, depend on and remove, one package at a time, starting with semantics. Each package is qualified on its own, so nobody waits for the whole thing to land at once. Nobody gets broken along the way either. dartastic_opentelemetry users stay compatible, and Workiva's opentelemetry users get a clear upgrade path.

There's no deadline. Quality decides when each package is ready. The API is nearly there. The SDK needs more time in production and a few more rounds of compliance work.

There's no need to wait for the donation to finish. dartastic_opentelemetry is ready to use today, and using it is the most helpful thing you can do. Run it in your apps and tell us what breaks, what's slow and what's awkward. Wide production use is what OpenTelemetry looks for, and field feedback is how we found the span id bug.

If you want to do more:

Watch or contribute to open-telemetry/opentelemetry-dart.
Pick up an issue from the SDK tracker.
Join the Dart and Flutter OTel SIG meeting, every other Friday (even ISO weeks) at 08:00–08:30 GMT. Subscribe to the SIG calendar for the invite and catch up in the meeting notes.

The goal hasn't changed: the highest quality, most compliant OpenTelemetry SDK of any language. Come help us get there.

About Dartastic.io : AI Code Healing and Real User Monitoring for Flutter

See what your users experience. Find problems with Flutter apps in production. Fix them with AI.

Dartastic.io brings AI code healing, real user monitoring, and OpenTelemetry observability together in one platform built for Dart and Flutter. (Patents pending)