Storage Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the content storage layer. This bundle is the storage abstraction inside Superdesk Web Publisher (SWP), a multi-tenant editorial publishing platform. Reading it tells you how a production newsroom system separated content persistence from rendition/theme/asset storage — useful input when deciding whether to build a tenant-aware storage seam yourself or adopt an existing one.
• Multi-tenant publishing roadmap. If your roadmap includes per-tenant themes, per-tenant media, or per-tenant content isolation, the bundle's tenant-scoped storage conventions are a concrete reference model for how those boundaries get enforced in code rather than in documentation.
• Architecture review of an existing SWP investment. If your organization is already running or evaluating SWP, this bundle defines a dependency boundary you will inherit. Knowing it exists — and that it is a read-only subtree split — tells you where fixes must be filed (upstream) and what your upgrade surface looks like.
• Licensing and distribution decisions. AGPL-3.0 is a product decision, not a legal footnote. Adopting this into a network-served product triggers AGPL §13 source-availability obligations. That materially constrains SaaS packaging, white-labeling, and OEM deals, and should be settled before any engineering spike, not after.
• Reference for a "don't build this" call. With zero stars, zero dependents, and no release since June 2018, this is a clean example of an internal component published for transparency rather than for reuse. It supports a decision to study rather than depend.

When to Consider This Package

Consider it only under narrow conditions:

• You are already on Superdesk Web Publisher and need to understand, extend, or debug the storage layer. In that case it is not optional — it is part of your stack, and your job is to track it upstream, not here.
• You are evaluating SWP as a platform and want to assess the maturity and coupling of its internals before committing.
• You need a reference architecture for multi-tenant content/asset storage in a PHP publishing domain and are willing to read code, not install it.

Look elsewhere in every other case:

• Laravel teams. This is a Symfony bundle, not a Laravel package, despite being framed that way. There is no service provider, no config publishing, no facade. The integration cost is a full framework boundary, not a composer require. Use Laravel's filesystem/Flysystem integration, or a maintained media library, instead.
• You need maintenance. No release in roughly seven years, no dependents, and the repository is a [READ-ONLY] subtree split — you cannot open issues or PRs against it. Any bug you hit is your bug.
• You need a permissive license. AGPL-3.0 is a hard blocker for most commercial SaaS and any embedded/OEM distribution. If legal has not signed off, stop here.
• You need modern PHP support guarantees. A 2018 cut predates current PHP runtime expectations; assume you own the upgrade work.

How to Pitch It (Stakeholders)

To executives: This is not a component we should adopt. It is a seven-year-old internal piece of a newsroom publishing platform, published as a read-only mirror, carrying an AGPL-3.0 license that would force us to disclose source for anything we serve over a network. The value here is intelligence, not dependency: it is a worked example of multi-tenant content storage that can inform our own design at the cost of a few days of reading, versus weeks of integration and an open-ended maintenance liability. Recommendation: study, do not adopt; revisit only if we formally commit to Superdesk Web Publisher as a platform.

To engineering: Treat this as a reference implementation. Read it for how tenant-scoped storage, content renditions, and asset paths were modeled in a Symfony-based CMS. Do not add it as a dependency — there is no supported upgrade path, no issue tracker on this repo, and no Laravel integration. If we want the pattern, we reimplement it against Laravel's filesystem and Flysystem in a fraction of the time it would take to bridge frameworks. If we ever do need the real thing, we go upstream to SWP and evaluate it as a platform decision, complete with a license review.