Storage Laravel Package

Product Decisions This Supports

• Build vs. buy: Treat swp/storage as a reference implementation or legacy integration component, not a commercial “buy” dependency. Its AGPL-3.0 license, 2018 last release, single star, and zero dependents make it unsuitable as a default building block for a modern Laravel product.
• Roadmap dependency: Only relevant if the roadmap explicitly includes Superdesk Web Publisher compatibility, migration, or reuse of its storage model. It should not appear on a greenfield Laravel roadmap.
• Feature scope: May inform storage abstraction, content persistence, or CMS-style storage design, but the PM should not assume Laravel-native integration, modern framework support, or ongoing maintenance.
• Use cases: Legacy SWP interoperability, data migration research, architecture reference, or a time-boxed technical spike. Poor fit for customer-facing storage, file handling, media pipelines, or core persistence unless the team already operates inside the SWP ecosystem.
• Risk decision: The package is a read-only subtree split, meaning changes belong upstream. That reduces the practicality of local patches and increases coupling to a project with no evident adoption signal.
• License decision: AGPL-3.0 can create source-disclosure obligations for modified network services. Legal review should precede any production use, especially in SaaS or distributed products.

When to Consider This Package

Consider it only when most of these are true:

• You are already maintaining or integrating with Superdesk Web Publisher and need compatibility with its storage component.
• Your legal and engineering teams have explicitly approved AGPL-3.0 obligations.
• You need a reference implementation for CMS storage patterns, not a supported production dependency.
• You can absorb the cost of validating PHP/framework compatibility, security posture, and upstream maintenance yourself.
• The work is a time-boxed spike or migration aid, with a clear exit plan and no critical-path dependency.

Look elsewhere when:

• You are building a new Laravel application and need standard storage, file abstraction, persistence, or media handling. Prefer actively maintained Laravel-native options such as Laravel’s filesystem/Eloquent layers, Flysystem integrations, Doctrine where appropriate, or well-supported community packages.
• You require permissive licensing, vendor support, security patches, SLAs, or a healthy dependent ecosystem.
• You need predictable compatibility with current PHP and Laravel versions; a package last released in 2018 is a maintenance liability until proven otherwise.
• You expect to modify the package locally. The read-only subtree split makes patching and long-term ownership awkward.
• Adoption risk matters: one star and zero dependents provide almost no signal of community validation or production use.

How to Pitch It (Stakeholders)

Executive summary: swp/storage is not a strategic dependency for a modern Laravel product. It is an old, low-adoption, AGPL-licensed component from the Superdesk Web Publisher ecosystem, distributed as a read-only subtree split. We should not put it on the critical path or assume it is maintained. Its value is limited to SWP compatibility, migration research, or architecture reference.

For engineering: Evaluate only as a reference or legacy integration aid. Verify PHP version constraints, framework coupling, test coverage, and whether any Laravel service-provider integration exists. Do not assume modern Laravel support. If we adopt it, assign an owner, pin versions, document AGPL obligations, and create an exit plan.

Recommendation: Avoid for greenfield work. If an SWP integration is genuinely required, run a short legal and technical spike, then decide whether to integrate upstream, reuse patterns, or build a small internal abstraction instead. Otherwise, choose an actively maintained, permissively licensed Laravel/PHP storage solution.