Maintenance Bundle Laravel Package

Product Decisions This Supports

• Maintenance/downtime UX: Informs whether to invest in a first-class "maintenance mode" capability — a scheduled or on-demand state that serves a branded holding page, sets proper HTTP status codes, and gates access for internal users — versus relying on ad-hoc server redirects or nginx rules.
• Build vs. buy vs. adopt: Frames the classic trade-off for a small, commodity feature. This package represents the "adopt an existing library" option; the assessment leans toward build (thin, in-house) because the feature is simple and the dependency risk is high.
• Platform/stack alignment: Surfaces a critical mismatch — despite being catalogued as a Laravel/PHP package, this is a Symfony bundle (CorleyMaintenanceBundle). This directly affects framework-specific roadmap decisions (Laravel has php artisan down built in; Symfony teams need a different answer).
• Vendor/dependency risk policy: Serves as a concrete test case for your OSS intake criteria — 0 stars, 0 dependents, no visible maintenance signal — useful when calibrating "minimum health bar" rules for third-party dependencies.
• Release/ops readiness: Informs runbook and incident-response design (how do we flip maintenance on/off, who can bypass it, how do we communicate planned vs. unplanned downtime).

When to Consider This Package

Consider only in a narrow legacy context:

• You maintain an existing Symfony 2.x/3.x application that already depends on it, and removal cost outweighs the (limited) risk.
• You need a reference implementation of maintenance-mode behavior (IP allowlisting, custom templates, status codes) to inform an in-house build — not as a production dependency.

Look elsewhere (the default recommendation) in almost all other cases:

• Framework mismatch: This is a Symfony bundle; Laravel, Slim, or plain-PHP projects should not adopt it.
• Health signals are effectively zero: 0 stars, 0 dependents, no active maintenance trajectory — fails any reasonable OSS intake bar. No community support means no safety net for security patches or framework upgrades.
• Laravel teams: Use the built-in php artisan down / up commands (with secret-token bypass and custom render), which is maintained by the core team.
• Symfony teams on modern versions: Prefer actively maintained alternatives or a small custom event subscriber / kernel listener; a 30–80 line listener typically covers the need.
• Any compliance-sensitive or long-lived product: Avoid single-maintainer, zero-adoption dependencies for infrastructure-adjacent concerns.

Net: Treat this as "do not adopt; optionally study, then build." The feature is cheap to implement and the external dependency adds risk without proportionate value.

How to Pitch It (Stakeholders)

To executives: We evaluated a third-party library for "maintenance mode" — the ability to gracefully show users a holding page during deploys or incidents. Recommendation: do not adopt it. It's a single-maintainer Symfony component with no adoption or maintenance signal, which introduces supply-chain and upgrade risk for a feature we can build in-house in a day or two. The business outcome (clean downtime communication, controlled access during maintenance) is achievable without the dependency, at lower long-term risk and cost.

To engineering: This is a Symfony bundle mislabeled as a general PHP/Laravel package. With 0 stars and 0 dependents, it's effectively unmaintained — no upgrade path, no security response, no community. For Laravel, use the native artisan down/up. For Symfony, implement a lightweight kernel request listener (or use a maintained alternative) that returns a 503 with a branded template and supports an IP/token bypass for internal staff. This keeps the surface area small, testable, and fully under our control.

Ask: Approve a small in-house build (est. 1–2 dev days including tests and runbook) and add "minimum dependency health" criteria (active maintenance, meaningful adoption, clear ownership) to our OSS intake checklist.