Open source and portable are not the same thing
Elastic's APM page says “APM should be open. Period.” and backs it with OpenTelemetry semantic conventions, W3C trace context and EDOT, their own supported OTel distribution. On licensing and direction they are right. The remaining portability risk is the instrumentation an application starts with. In the 30-day PyPI snapshot behind this page, elastic-apm accounted for about 95% of downloads across elastic-apm and elastic-opentelemetry. Package downloads are not customer share, but they show that the Elastic-specific agent remains heavily downloaded and carries no deprecation notice. It is BSD-licensed and readable, but it speaks Elastic's intake protocol rather than OTLP. Elastic's migration guides show what leaving costs: for Java it is a JVM flag swap with no code changes, while custom Agent API spans must be ported to OpenTelemetry. Start on OpenTelemetry and there is no instrumentation migration to schedule.