Pumukit Oai Bundle Laravel Package

Product Decisions This Supports

• Metadata interoperability and discovery: OAI-PMH is the harvesting protocol used by aggregators and academic indexes (Europeana, OpenAIRE, BASE, DPLA, union catalogs, institutional repository networks). This bundle's job is to expose a media catalog for harvesting — a distribution decision, not an end-user feature.
• Roadmap fit for repository / archive products: relevant if the roadmap includes lecture capture archives, university media portals, cultural heritage collections, digital libraries, or any "our content should be indexed elsewhere" requirement. Not relevant for consumer video, LMS, or streaming-first products.
• Compliance and funding mandates: many institutional and publicly funded content programs require OAI-PMH endpoints as a condition of participation. That can turn this from a nice-to-have into a checkbox on a grant or procurement form.
• Build vs. buy vs. borrow: OAI-PMH 2.0 is a small, well-specified protocol (six verbs); the hard part is your metadata schema mapping, not the protocol. This package is best evaluated as a reference implementation of the protocol + schema mapping pattern, not as a dependency to adopt wholesale.
• Prioritization signal: with 1 star, 0 dependents, and a composite score of 0.005, the market is telling you almost nobody is reusing this. That argues for not allocating roadmap capacity to adopting it unless you are already on the host platform.
• Platform lock-in decision: this is a Symfony bundle bound to Pumukit's domain model (series/multimedia objects), not a framework-agnostic or Laravel-native library. Choosing it is effectively choosing Pumukit. That is a platform decision that belongs in an architecture review, not a backlog ticket.

When to Consider This Package

Consider it when all of the following hold:

• You are running Pumukit (or a fork) on Symfony and want OAI-PMH exposure without writing the endpoint yourself.
• You need standard harvesting output (Dublin Core and related formats) for named aggregators, and the required schema mapping is close to what the bundle already emits.
• You have a small team and prefer configuration over a bespoke protocol implementation.
• You can accept vendoring or forking the code, because the maintenance signal is weak (1 star, 0 dependents, effectively no community to triage issues or ship fixes).

Look elsewhere when:

• You are on Laravel or any non-Symfony stack. There is no port, and the coupling to Pumukit's entities means a rewrite is cheaper than an adapter.
• You need a maintained dependency. Zero dependents and negligible stars means no ecosystem pressure to keep it current with framework or PHP versions; assume you own the code the day you adopt it.
• Your metadata requirements are bespoke (custom schemas, non-DC formats, complex rights/embargo logic). At that point the protocol scaffolding is a small fraction of the work and the bundle's opinions become friction.
• You only need a feed for one aggregator. A scheduled export to their ingest format is often simpler and cheaper than standing up a harvesting endpoint.
• You need SLAs or vendor support. None is implied here.

How to Pitch It (Stakeholders)

To executives: This is a small, niche piece of plumbing that makes our media catalog harvestable by academic and cultural aggregators. It creates discoverability and can satisfy institutional or funder requirements that ask for OAI-PMH. It is only cheap if we are already on the Pumukit platform; on our current stack it is a build, not a buy. The package itself shows essentially no adoption (1 star, 0 dependents), so treat it as a blueprint rather than a product we depend on. Recommendation: fund an OAI-PMH endpoint only if discovery in these aggregators is on the roadmap; otherwise defer.

To engineering: It is a Symfony bundle for Pumukit that implements an OAI-PMH provider over the platform's series/multimedia objects. It is not Laravel-compatible and its models are Pumukit's, so integration outside that platform means reimplementation. Assume fork-and-own: pin the version, read the code before trusting it, and expect no upstream fixes. The reusable asset is the schema-mapping approach, not the code — budget the real effort for metadata mapping and identifier stability, which is where these projects usually fail.

To product/GTM: The capability, not this package, is what we can sell: "your collection is discoverable in the indexes researchers actually use." That claim needs a named target aggregator and a validated schema mapping before it goes on a roadmap or a slide.