Gen Otlp Protobuf Laravel Package

Product Decisions This Supports

• Observability platform standardisation. This package is the wire-format layer for OTLP — the vendor-neutral protocol used by OpenTelemetry collectors. Committing to it effectively commits the product to OTel as the telemetry backbone, which is the real decision. The package itself is a downstream artifact of that choice, not an independent bet.
• Build vs. buy on serialization. The protobuf schemas are generated upstream from the OTel specification and published under Apache-2.0. There is no defensible reason to hand-maintain OTLP payload classes. Treat this as "buy" (adopt) and spend engineering time on instrumentation coverage instead.
• Vendor portability / exit cost. Because telemetry leaves PHP services in a standard binary format, the backend (Jaeger, Tempo, Prometheus, Grafana, a managed APM) becomes a swappable configuration detail rather than an application-level dependency. This directly lowers re-platforming cost if a vendor renegotiation goes badly.
• Cost and overhead modelling. Protobuf payloads are materially smaller than JSON equivalents, and the optional pecl protobuf C extension makes export significantly faster. That is a concrete input to the capacity/cost line for high-throughput PHP services, not a theoretical one.
• Roadmap sequencing. This package should never appear as a roadmap item on its own. It surfaces only when you schedule "ship OTLP export from the PHP SDK" work. If you are prioritising tracing for Laravel APIs, queues and jobs, this is a dependency in the critical path; if you are not, it is noise.
• Buy-in for a phased rollout. Its narrow scope makes it a low-risk piece of a proof-of-concept: instrument one route, point at a local collector, and you have a demo without touching the broader observability stack.

When to Consider This Package

Consider it when:

• You are adopting open-telemetry/opentelemetry-php and enabling the OTLP exporters (gRPC or HTTP). In that case this arrives transitively — you do not add it deliberately, you just need to know it is there and pin it consistently with the SDK.
• You need to emit OTLP without pulling the full SDK, or you need to construct custom OTLP payloads (proprietary span attributes, bespoke resource descriptors) that the SDK's higher-level API does not expose.
• Your PHP services already talk to an OTel collector, or you have committed to deploying one (self-hosted, Kubernetes, or a cloud distribution such as AWS Distro for OpenTelemetry).
• You are running in production and can install the pecl protobuf extension — the README explicitly calls this the recommended production configuration. If you cannot install PHP extensions in your runtime, budget for the performance penalty of the native library.

Look elsewhere when:

• OTel is not your telemetry standard. If the stack is Datadog APM, New Relic, or hand-rolled logging, this package adds a parallel pipeline and no value.
• You have no PHP backend services, or telemetry needs are trivial. The protobuf runtime, collector infrastructure, and schema-version discipline are disproportionate to a small surface area.
• A vendor agent already handles transport for you. Vendor agents ship their own serialization; bolting OTLP alongside duplicates egress and cost.
• The team would otherwise be reaching for raw protobuf classes to do work the SDK already abstracts. Misusing Resource/Span/Metric shapes produces malformed telemetry that collectors silently reject — a failure mode that is expensive to debug and looks like "observability is broken."

Due-diligence flags to raise before adoption:

• Maturity signal is weak. Last standalone release is September 2023, the README is a stub, and the package is a read-only subtree split of a monorepo. Treat the monorepo (open-telemetry/opentelemetry-php, 917 stars) as the source of truth for health, not this package's page.
• Zero listed Packagist dependents does not mean unused — the SDK depends on it through the monorepo — but it does mean you should verify version alignment yourself rather than assuming Composer will resolve a compatible pair.
• Schema evolution is someone else's release cadence. Protobuf definitions track the OTel specification. You inherit the obligation to upgrade, regression-test, and validate payloads when the spec moves. Assign an owner for that.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version. "This is a small open-source component that lets our PHP services send telemetry to any OpenTelemetry-compatible backend. It does not add a feature; it removes a lock-in. Adopting it means we instrument once, in a standard format, and can then change observability vendors on commercial terms rather than on migration cost. It is low-risk and near-zero-cost to adopt, and it should be scoped as plumbing inside an existing observability initiative — not funded as a standalone project. The one commitment it creates is an ongoing obligation to keep the telemetry schema current, which is a maintenance line item, not a build."

For engineering — the practical framing. "gen-otlp-protobuf is the generated PHP protobuf layer for OTLP; it is the transport format, not the instrumentation. You will almost never require it directly — pull in open-telemetry/opentelemetry-php, enable the OTLP exporter, and this comes along. Install pecl protobuf in production images; without it, export throughput is noticeably worse. Pair it with a collector (otel-collector locally, Docker or Kubernetes in staging) and wire tracing into Laravel middleware, queue/job.processing events, and the HTTP client, then extend to metrics. Use HTTP for simplicity where gRPC infrastructure is inconvenient — gRPC needs grpc/grpc and proxy-friendliness is a real constraint. Two things to own deliberately: pin the package version in lockstep with the SDK, and add a CI check that validates payload shape so a spec bump doesn't silently drop telemetry at the collector."