Objectstorage Laravel Package

Product Decisions This Supports

• Storage abstraction vs. direct SDK coupling. The package is a thin abstraction for object storage in cloud PHP apps. Evaluating it forces a decision that outlives the package itself: do we hard-code S3/GCS/Azure SDK calls into our domain code, or put a provider-agnostic interface in front of them? Even if we reject this library, that architectural call is worth making explicitly on the roadmap.
• Vendor lock-in posture. If portability across cloud providers is a stated product or procurement requirement (multi-cloud, DR, or enterprise customer demand), a storage interface is a prerequisite. This package is a reference for what that seam looks like in PHP, not necessarily the implementation.
• Build vs. buy vs. adopt for file/media services. Useful input to scoping uploads, user documents, exports, and media pipelines. It helps frame the question "is storage plumbing a feature we build, or a commodity we compose from maintained libraries?"
• Roadmap risk assessment. Its last release in 2019 and near-zero adoption (10 stars) is evidence for a broader portfolio decision: inventory which of our dependencies are unmaintained and schedule replacement before they become a security or upgrade tax.
• Not a decision driver: this is not a candidate for a greenfield Laravel product's storage layer. It informs the architecture conversation and the dependency-risk register, not the implementation choice.

When to Consider This Package

Adopt only under narrow, unusual conditions:

• Legacy PHP codebase already using it. If an inherited service depends on linkorb/objectstorage and works, the decision is whether to extract the interface and migrate to league/flysystem, not whether to expand usage.
• You need a provider-agnostic API outside Laravel. If the application is framework-light PHP and you specifically want a minimal wrapper rather than a full filesystem abstraction, it can be read as a design reference.
• As a stopgap during a migration. A short-lived adapter layer while moving to a maintained library is defensible if time-boxed and owned.

Look elsewhere in essentially all other cases:

• Laravel projects should use the framework's own Storage facade built on Flysystem, plus league/flysystem-aws-s3-v3 (or the GCS/Azure equivalents). It is first-party, maintained, documented, and battle-tested.
• Any new product. No release since 2019 means no PHP 8.x guarantees, no security triage, no upstream fixes, and no community support. That is a compounding liability.
• Compliance-sensitive storage. Audit trails, encryption-at-rest policy, signed-URL semantics, and retention rules need a library with active maintenance and a security response process.
• Teams without spare capacity to own a fork. With 10 stars, the realistic worst case is that you become the maintainer.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed PHP storage wrapper — useful as a reference for how we should structure cloud file storage, but not something I recommend we depend on. It has had no release since 2019 and negligible adoption, which means no security patching and no upgrade path as we move to newer PHP versions. The decision it supports is sound — keep storage behind an interface so we can change providers without rewriting product code — but we should implement that on Laravel's maintained, first-party storage layer rather than this package.

To engineering: The abstraction idea is right; the artifact is stale. Use Storage + Flysystem, define our own narrow interface over it, and keep provider-specific configuration out of domain code. If any existing service already uses this package, treat it as technical debt: open a ticket to replace it, scope it as a small adapter swap, and do not add new call sites. I'm also adding "unmaintained dependency" to our quarterly review so we catch the next one before it's load-bearing.