Dev Tools Laravel Package

Product Decisions This Supports

• Instrumentation standard decision (build vs. buy): Informs whether to standardize on OpenTelemetry versus a proprietary agent (Datadog, New Relic, Sentry, Elastic). This package is a dev-only dependency that lets engineers prove telemetry actually emits from a Laravel app before signing an observability contract.
• Migration risk gating: A cheap, reversible way to de-risk an observability roadmap milestone. Because it never ships to production and adds no runtime dependency, the cost of trying it is bounded to engineering hours.
• "Build" option viability for custom instrumentation: If you intend to write domain-specific instrumentation (queue jobs, multi-tenant request lifecycles, checkout funnels), upstream dev tooling shortens the build-measure loop and makes the in-house option genuinely comparable to buying.
• Framework-upgrade risk: The 0.2 release adds Symfony 8 support, which matters indirectly for a Laravel estate — Laravel tracks Symfony components, and dev tooling that lags a framework upgrade becomes a blocker to CI telemetry checks. This is evidence the upstream keeps pace with the ecosystem we actually run.
• Demo-able proof over architecture decks: Enables a live round-trip — Laravel app → collector → backend — so stakeholders see real traces from a staging service rather than a diagram.
• Vendor negotiation leverage: A working, vendor-neutral pipeline materially weakens "you're locked in anyway" arguments during APM pricing and renewal conversations.
• SLI/SLO readiness: Supports defining service-level indicators from real telemetry pre-launch instead of reverse-engineering them after the first incident.
• Explicitly not supported: end-user debugging, local app inspection, or APM replacement. Telescope/Nightwatch and vendor agents own that job. Note also that 0.2's new capabilities (repository-prefix filtering, listing released versions) are maintainer-workflow conveniences, not product features — they improve the tool's usability for teams managing multiple instrumentation packages, and should not be sold internally as new observability capability.

When to Consider This Package

Consider it when:

• You have decided, or are seriously evaluating, OpenTelemetry as the instrumentation standard across a PHP/Laravel estate and need an upstream-sanctioned way to verify spans, metrics, and logs are correct.
• Engineers are building or maintaining a custom exporter, instrumentation library, or Laravel auto-instrumentation and need conformance/test scaffolding rather than hand-rolled harnesses. The 0.2 repository-prefix filtering helps if you maintain several instrumentation packages side by side.
• You want telemetry assertions running in CI — "this endpoint emits a span with these attributes" — without provisioning paid SaaS in every pipeline.
• You are planning a Laravel/Symfony upgrade cycle and want dev-side telemetry checks to survive it; 0.2's Symfony 8 support is a positive signal here.
• You are contributing back to, or extending, the OpenTelemetry PHP ecosystem.

Look elsewhere when:

• You want turnkey APM or app-level debugging in Laravel. This is not an observability product and will not give you dashboards, alerts, or traces out of the box.
• You have no OpenTelemetry adoption plan. It is dev tooling for a stack you aren't running; value is zero otherwise.
• You require a commercially supported, SLA-backed dependency. With 0 stars, 0 dependents, and a dev-tools scope, there is no vendor support path — treat it as community/upstream infrastructure.
• No one on the team owns observability. Tooling without an accountable owner becomes shelfware regardless of quality.

Maturity caveat: the popularity signals are effectively null, so evaluate on organizational backing (official OpenTelemetry PHP org), release cadence, license (Apache-2.0), and code review — not adoption metrics. The 0.1 → 0.2 progression (new features, Symfony 8 compatibility, a first-time contributor) is a modest but real maintenance signal; it does not change the risk profile, and there is still no dependent ecosystem to lean on. The saving grace remains that the blast radius is structurally small: dev-only, require-dev, never in the production artifact, and 0.2 introduces no breaking changes that would complicate a pinned upgrade.

How to Pitch It (Stakeholders)

For executives: OpenTelemetry is the vendor-neutral standard for traces, metrics, and logs. open-telemetry/dev-tools is the upstream development toolkit for the PHP implementation — it is not shipped to production, carries no runtime or customer-facing risk, and its job is to let our engineers verify in CI and locally that Laravel services emit correct telemetry before we commit to a vendor or a multi-quarter migration. The recent 0.2 release is a small, non-breaking maintenance update — new filtering and version-listing conveniences for maintainers, plus Symfony 8 support that keeps the tooling aligned with our framework upgrade path. The strategic value is optionality: it lets us prove out vendor-neutral instrumentation cheaply, preserve pricing leverage with APM vendors, and reduce the chance an observability migration slips late. The tradeoff is maturity — it is early-stage with no dependents — so we should adopt it only as a dev-only dependency alongside a named engineering owner. Ask: approve a time-boxed 2–4 week spike with one engineer on a single non-critical Laravel service, with a go/no-go on standardizing on OpenTelemetry.

For engineering: Official OTel PHP org package, Apache-2.0, actively released — 0.2 adds repository-prefix filtering, released-version listing, and Symfony 8 support, with no breaking changes called out. Use it for local collector round-trips and instrumentation conformance tests; pin the version, keep it under require-dev, and do not let it gate production builds. Symfony 8 support is worth validating against your target Laravel version during the spike rather than assumed. It complements — it does not replace — the SDK, API, and exporter packages, and it should be paired with an explicit decision on which backend and exporter you standardize on. Success criteria for the spike: a repeatable CI check asserting span presence and key attributes on one real endpoint, and a documented local dev setup that a second engineer can run unaided.