Sms Bundle Laravel Package

Product Decisions This Supports

• SMS capability strategy (OTP, transactional, alerts): Informs whether we ship SMS as a first-party abstraction or lean on a provider SDK. This bundle is a thin Symfony-style transport wrapper — useful mainly as a reference pattern, not a dependency.
• Build vs. buy for the messaging layer: The existence of micro-bundles like this is evidence that an SMS abstraction layer is small enough to build in-house. The decision this package supports is usually "buy the provider SDK, build a 1-file adapter," not "adopt a third-party bundle."
• Provider abstraction / vendor portability: Its transport abstraction supports the roadmap decision to keep SMS provider-swappable (Twilio ↔ Vonage ↔ MessageBird) rather than hard-coding one vendor.
• Framework fit on the roadmap: Clarifies a platform decision — this is a Symfony bundle, not a Laravel package. It informs whether our roadmap assumes Laravel-native packages (service providers, facades) or allows Symfony interop.
• Dependency-risk policy: With 2 stars, 0 dependents, and a 0.04 score, it's a case study for our "no single-maintainer, no-social-proof dependencies in production" rule.

When to Consider This Package

Consider only if:

• You are on Symfony (ideally the legacy Xi stack it was built for) and need a pre-wired SMS transport abstraction.
• You want a reference implementation to copy the abstraction pattern from — read the source, don't require it.
• You are prototyping and can tolerate zero community support and unknown maintenance status.

Look elsewhere if:

• You are on Laravel — this is not a Laravel package. Use the provider's official SDK behind a small SmsSender interface + service provider. Lower risk, less glue.
• You need active maintenance, PHP 8+ compatibility, security patches, or a support SLA.
• You need delivery receipts, webhooks, templating, or compliance features (10DLC, sender registration) — provider SDKs own this; a 2-star bundle will not.
• You are in a regulated or customer-facing critical path where an unmaintained dependency is disqualifying.

Practical guidance: treat it as a spike/reference only. Do not add it to production composer.json.

How to Pitch It (Stakeholders)

For executives (one line): A tiny, effectively abandoned Symfony bundle for SMS. It validates that an SMS adapter is cheap to build, but it is not a dependency we should adopt — we'll use the SMS provider's own SDK and wrap it ourselves, in roughly a day of engineering.

For engineering:

• Signal: 2 stars, 0 dependents, score 0.04 → no ecosystem validation, no downstream users to surface bugs, unclear maintainer commitment.
• Mismatch: Symfony bundle, not Laravel — integration cost is real, benefit is near zero.
• Recommendation: Build a thin SmsSender contract (send, status, provider id) with one adapter per provider. This gives portability without taking on abandoned code.
• Effort: ~1–2 days for the interface + first adapter; add adapters as needed.
• Risk of adoption: high (unmaintained), risk of building: low (small surface, well-understood domain).

Decision: Do not adopt. Reuse the idea (transport abstraction), not the code. Revisit only if we standardize on Symfony and this bundle shows maintenance activity.