Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the domain foundation layer. runn/core is a framework-agnostic PHP primitive/utility library (base value objects, collections, data structures) rather than a Laravel integration. The decision it informs is whether to adopt an external base layer for entities/DTOs or write a thin internal package (~hundreds of LOC) we own. Primitive layers are the highest-leverage, lowest-differentiation code in the product — the cheapest thing to write and the most expensive thing to replace.
• Architecture standardization across the PHP estate. Relevant if we run non-Laravel or mixed PHP services and need a shared object model. For a Laravel-first product the answer is usually no: we already have Illuminate\Support\Collection, Symfony Serializer/Validator, and spatie/laravel-data. Introducing a parallel object model creates two dialects in one codebase — a velocity tax paid on every PR, not a one-time cost.
• Licensing/legal gate as a product risk item. LGPL-3.0 is copyleft-adjacent. For pure SaaS (no distribution of the library) it is generally benign; for on-prem, appliance, SDK, or white-label distribution it triggers obligations (source availability, relinkability) that must be priced and cleared before the code lands in the domain model.
• Support/ownership commitment. With 32 stars and 0 dependents, there is no upstream bug-fix leverage. Adoption is effectively a decision to fork and internally own — that's a headcount line, not a dependency line.
• Roadmap sequencing. If we were to adopt it, it belongs in a greenfield service, never retrofitted under an existing model — the migration cost scales with every entity that extends it.

Caveat: this assessment is drawn from package metadata (stars, dependents, license, description) rather than a code audit. Confirm actual API surface before any final call.

When to Consider This Package

Consider it when:

• We need lightweight, framework-agnostic value-object/DTO primitives and are not already standardized on Symfony or Illuminate equivalents.
• The team is prepared to vendor/fork it and treat it as internal source, with a named owner.
• The estate is non-Laravel or mixed-stack, so Laravel helpers aren't available.
• Legal has cleared LGPL-3.0 against our distribution model (or we ship SaaS-only).
• Scope is a small, isolated service where the blast radius of abandonment is contained.

Look elsewhere when:

• The product is Laravel-first — spatie/laravel-data, Illuminate Collections, and Symfony components are better maintained, better documented, and cheaper to hire for.
• The library would sit under the core domain model. Single main­tainer, no dependents, and no visible release cadence is the wrong risk profile for a foundation layer.
• We distribute proprietary software where LGPL obligations are non-trivial.
• The library touches untrusted input, serialization, validation, or auth-adjacent paths — an unaudited, low-traffic package is a poor place for a security boundary.
• Nobody can answer "who ships a fix if a CVE lands here in 48 hours?"

How to Pitch It (Stakeholders)

To executives: This is a foundational PHP utility library — value objects and data structures, not a user-facing feature. The economics are weak: modest scaffolding savings against meaningful lock-in risk on the layer that's hardest to change later, plus an LGPL-3.0 license that needs legal sign-off if we ever distribute software. Recommendation: do not adopt as a core dependency. It's a single-maintainer project with no downstream users and no evident release cadence. If a team wants the patterns, fund a 1–2 week internal spike to implement the small subset we actually need, under our license and our ownership. Same benefit, no vendor risk.

To engineering: The library offers DDD-flavored primitives, but we already have functional equivalents in Illuminate and Symfony. Adopting it means two object models in one codebase plus a fork we'd have to own and patch. If the patterns are genuinely useful, read them and reimplement the small pieces we need rather than depending on them — that also removes the LGPL distribution question entirely. If any team still wants to proceed, the ask is: name an internal owner, define the fork policy, and confine it to a single greenfield service.