Providence Bundle Laravel Package

Product Decisions This Supports

• Metadata schema as code (the core decision). CollectiveAccess Providence stores its data model in a profile — an XML document defining metadata elements, UI layouts, relationships, and validation. Today that artifact is usually hand-edited in CA's web UI or by editing XML directly. This package appears to give PHP a way to read, generate, or manipulate those profiles, which changes the question from "who clicks through the CA admin UI?" to "can our profile live in Git and ship with the app?" That is the decision worth having.
• Environment promotion and multi-instance parity. If it works, it lets you promote a profile from dev → staging → production, or stamp a templated profile per institution/client, instead of re-creating schemas by hand and hoping they match. This is the strongest argument for looking at the package at all.
• Build vs. buy for GLAM verticals. For a museum/archive/library product line, the strategic question is whether to adopt CollectiveAccess as the system of record at all. This package is a signal that someone is trying to make CA more "developer-shaped" — useful input to that roadmap conversation, but not sufficient evidence on its own.
• Integration surface for downstream tools. A programmatic handle on profile definitions enables schema-aware validation of ingest files, generated admin forms, or documentation of the data model for clients. Relevant if your roadmap includes ingest pipelines, cataloging UIs, or client-facing schema docs.
• Adoption risk as a first-class product input. With zero stars, zero dependents, and a quality score of 0, the real decision this package supports is a make-or-buy-or-fork call: sponsor it as an internal spike, vendor it, or write the ~few hundred lines of XML handling yourself.

When to Consider This Package

Consider it if:

• You already run CollectiveAccess Providence in production and are maintaining profiles by hand — the pain is real and recurring.
• Your team is Symfony/PHP-native. The package name and authorship ("Bundle") indicate a Symfony bundle with DI/config conventions, not a Laravel package; that mismatch is a cost, not a footnote.
• You need a narrow capability — parsing, diffing, or emitting profile XML — that you can validate in a day or two.
• You are comfortable treating third-party code as a starting point you will own: vendoring, forking, or wrapping it. MIT licensing makes that legally clean.
• You are pre-committed to CA and need tooling around it, not tooling instead of it.

Look elsewhere if:

• You are a Laravel shop without Symfony bundle experience — you will fight the service-container integration for marginal gain.
• You are not already on CollectiveAccess. Do not adopt a collections platform because a helper library exists; evaluate CA's fit first.
• You need supported, maintained dependencies — no stars, no dependents, and a zero quality score means no community safety net, no issue triage, and no guarantee the maintainer is still active.
• Your actual need is data movement, not schema movement: bulk ingest, exports, or public-facing search. CA ships its own importer and Pawtucket front end, and the Providence Web Services API is the supported integration path for record-level work.
• You need documentation, CI, tests, or release tags before your procurement/security review will pass. Assume all are absent until verified.
• Profile XML is only a one-time migration task — write a throwaway script instead.

Before committing, verify: does it target the profile schema version your CA install uses? Is it bidirectional (read + write) or one-way? Are there any tests? Last commit date? Does it depend on CA's PHP internals or talk to it over HTTP? The API-vs-internals answer determines how badly a CA upgrade breaks you.

How to Pitch It (Stakeholders)

To executives: This is a cheap experiment, not a platform bet. It addresses a genuine operational cost — keeping our collections metadata schema consistent and auditable across environments — but it arrives with zero adoption and no support. Recommendation: fund a one-to-two-day technical spike against a real profile, with a written go/no-go. Do not put it on the architecture diagram yet. Budget expectation is effectively zero in license cost and modest in engineering time; the downside is bounded because we can reimplement the narrow slice we need.

To engineering: The value proposition is "profile XML as a first-class artifact in our repo instead of click-ops in the CA admin UI." That is worth having. The catch is that we would be the only users: no stars, no dependents, a Symfony bundle in what may be a Laravel codebase, and a quality score of 0 that suggests thin docs and no tests. Treat it as reference-quality code: read it, spike with it, and expect to vendor or fork it. Explicit non-goals: it is not a data ingest path (use CA's importer or the Web Services API) and it is not a reason to adopt CollectiveAccess.

The ask: a timeboxed spike, a named owner, and a documented exit plan — either "wrap and vendor," or "reimplement the two functions we actually need in-house." Default to the latter unless the spike shows meaningful complexity we'd otherwise reproduce.