Common Laravel Package

Product Decisions This Supports

• Reference for content-publishing domain modeling, not a dependency. swp/common is a subtree split of the Superdesk Web Publisher monorepo — a curated set of shared building blocks (value objects, domain primitives, common contracts) used across the SWP platform. Its PM value is as a reference architecture when scoping the data model and shared abstractions for a CMS/editorial product, not as something you composer require.
• Informs a build-vs-buy conversation on the content core. If your roadmap includes multi-source publishing, article workflow, or a syndication pipeline, skimming this codebase helps your team estimate what "common primitives" actually cost to design — useful input when comparing against a commercial CMS or a headless platform.
• Not a roadmap accelerator. With zero dependents, one star, and a final release from June 2018, this package carries no ecosystem signal. It should not appear in a "leverage open source to hit the Q3 milestone" plan; treat any proposal to adopt it as a spike, not a commitment.
• Framework-fit caveat for prioritization. Despite being framed here as a Laravel/PHP package, SWP is a Symfony-based platform. Budget explicitly for framework-translation risk (service container, eventing, HTTP abstractions) if anyone proposes reuse in a Laravel codebase — that cost is a roadmap line item, not a footnote.

When to Consider This Package

Consider it (as reading material, not code) when:

• Your team is designing the domain layer of an editorial/publishing product and wants a worked example of shared value objects and contracts, extracted from a real platform.
• You are evaluating Superdesk Web Publisher itself and want to understand how its modules share primitives before a deeper platform assessment.
• You need a cheap, time-boxed spike (a day or two) to sanity-check your own abstraction design against prior art.

Look elsewhere — decisively — when:

• You intend to ship it in a commercial product. It is AGPL-3.0, a strong copyleft license. Bundling it can impose source-disclosure obligations on your service. This is a legal-review blocker, not a preference.
• You need maintained code. Last release 2018-06-08; no dependents and no community. No security patches, no PHP-version compatibility guarantees, no support path.
• You need framework alignment. It is not a Laravel package; expect glue work and version friction against modern Laravel/Symfony.
• You need more than primitives. A "common" component deliberately provides no application scaffolding, no persistence layer, no admin surface. It will not shorten a delivery timeline on its own.
• You require vendor assurance. A READ-ONLY subtree split carries no independent release cadence, changelog discipline, or issue tracker of its own.

How to Pitch It (Stakeholders)

For executives: This is a small, dormant component extracted from an open-source publishing platform. It is not a product you buy or depend on — it is a design reference. Its license (AGPL-3.0) makes it unsuitable for embedding in our commercial offering, and it has had no releases since 2018. Recommendation: do not adopt; spend at most a short, capped engineering review if the publishing domain is on the roadmap.

For engineering: Treat swp/common as prior art for content-domain primitives. Read it, don't require it. Note three hard constraints before any evaluation: AGPL-3.0 copyleft, a 2018 release with no maintainer, and a Symfony lineage that does not map cleanly onto Laravel. If we pursue a shared domain layer, we build it in-house or adopt a maintained, permissively licensed alternative — this package informs the design, it does not deliver it.

Bottom line: Low opportunity, high legal and maintenance risk. Value is educational; the correct product decision is to cite it as a reference during design and keep it out of the dependency tree.