Contact Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a "contact us" capability. This is the decision the package actually informs — and it informs it by being a negative example. A contact form is a form, a mailer call, and a spam guard. That is a one-sprint build in Laravel with FormRequest, Mail, and a honeypot or reCAPTCHA rule. The package does not meaningfully reduce that work.
• Framework-fit due diligence on the dependency list. The package is a Symfony bundle, not a Laravel package — no service provider, no config/contact.php, no Blade views, no composer.json extra.laravel block. If it appeared in a candidate list for a Laravel roadmap item, the correct product decision is to close the ticket and fix the sourcing criteria that surfaced it.
• Roadmap de-prioritization of "reuse existing OSS for contact/intake flows." With 7 stars, 0 dependents, no release since January 2016, and an archived repository, there is no ecosystem to inherit: no security patches, no PHP 8 compatibility, no community answers. Any roadmap line item premised on "we'll just wire up an existing bundle" should be re-scoped to build.
• Maintenance-liability budgeting. Adopting an archived dependency shifts a permanent maintenance cost onto our team — we become the fork maintainer. That is a staffing decision, not a code decision, and it should be priced explicitly.
• Vendor-risk scoring as a standing gate. This package is a useful calibration case for whatever adoption scorecard we run: unmaintained + zero dependents + framework mismatch should auto-fail before any engineering spike is scheduled.

When to Consider This Package

Essentially never for a Laravel product. Concrete criteria:

• Only if we are maintaining a legacy Symfony 2.x/3.x application, the contact form is already wired to this bundle, and the task is "keep the lights on" rather than "add capability." In that case it is a rip-and-replace candidate, not an adoption candidate.
• Only if we accept that we are forking. The last release predates PHP 7.1 and modern Symfony; expect work on type hints, deprecated APIs, and mailer interfaces before anything runs. Price that as a build, because it is one.
• Look elsewhere / build in-house if any of the following is true (all are true for us):
  • The stack is Laravel. Non-negotiable — framework mismatch alone ends the evaluation.
  • We need spam protection, rate limiting, GDPR-compliant storage or retention of submissions, or multi-recipient routing. None of that is in scope for a 2016 "yet another contact bundle."
  • We need a maintained dependency with a security-response path. Archived repos have none.
  • We need localization, file attachments, or CRM/webhook delivery — all standard asks on modern contact flows.
• Preferred alternatives: Laravel's own Mail + RateLimiter + validation (build), or a maintained Laravel-native package with recent releases and real dependents. Evaluate those on release cadence and dependent count, not on star count.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Build the contact flow in-house — one sprint, roughly 30–50 lines of application code.

For executives: The candidate package is unmaintained — archived, last released in January 2016, seven stars, zero downstream users. It also targets a different PHP framework (Symfony) than our Laravel stack, so it would not integrate without custom glue. Adopting it would make us the sole maintainer of a dead dependency in exchange for saving less than a sprint of routine work. The cost/benefit is clearly negative, and the security exposure of an unpatched mail-handling dependency is real.

For engineering: No ServiceProvider, no Laravel config or view layer — this is a Symfony bundle with a DI extension, which means building an adapter before we get any value. It predates modern PHP and Symfony mailer interfaces, so compatibility work is a rewrite with extra steps. We already have validated form requests, the mailer, rate limiting, and CSRF in the framework. The build is small, fully testable, and ours to maintain deliberately.

Ask: Approve the in-house build and add a dependency gate to our intake checklist — reject candidates that are archived, unreleased in 24+ months, or framework-mismatched, before an engineering spike is scheduled. Flag the Symfony-vs-Laravel mismatch in our sourcing criteria so this class of package stops reaching the shortlist.