Pumukit Opencast Bundle Laravel Package

Product Decisions This Supports

• Lecture-capture publishing pipeline: This bundle is the connective tissue between an Opencast capture/processing server and a PuMuKIT web TV portal. It supports the product decision of whether to expose Opencast-hosted recordings through an existing PuMuKIT front end rather than building a separate media portal.
• Build vs. buy for academic video portals: If your organization already runs PuMuKIT and Opencast, adopting this bundle is effectively a "buy/integrate" decision — reusing an existing AGPL integration instead of commissioning custom import/publish tooling.
• Feature scoping for media ingestion: It clarifies the minimum viable feature set for Opencast-to-portal workflows: authenticated import of Opencast events, metadata mapping, publication into portal categories/channels, and lifecycle handling (retract/update).
• Roadmap input for LMS/EdTech integrations: Useful as a reference architecture when evaluating how a media portal should consume Opencast APIs (search service, admin API, workflow events) — even if you ultimately build a different connector.
• Vendor/platform lock-in assessment: The bundle's dependency on both PuMuKIT and Opencast makes it a concrete data point in decisions about standardizing on that stack versus a more generic video platform (Kaltura, Panopto, YouTube, self-hosted alternatives).

When to Consider This Package

Consider it when:

• You are already operating PuMuKIT as your web TV portal and Opencast as your capture/processing backend; the bundle is purpose-built for exactly that pairing.
• You need a proof-of-concept or internal integration to demonstrate Opencast import and publication into PuMuKIT quickly, with Symfony bundle conventions rather than bespoke glue code.
• Your team is comfortable with PHP/Symfony and can read/maintain bundle code, since the project is small (1 star, 0 dependents) and the last release was 2020-02-27.
• AGPL-3.0 is acceptable for your distribution model — including any obligations if you expose the service over a network.

Look elsewhere when:

• You are on Laravel or a non-PuMuKIT stack — this is a Symfony bundle for a specific platform, not a general-purpose Laravel package. The integration cost would likely exceed building a thin Opencast API client.
• You need a maintained, vendor-supported integration with SLAs, security patches, or compatibility with current Opencast/PuMuKIT versions. The 2020 release date and near-zero community signals are material risks.
• Your product is closed-source or commercially distributed and AGPL copyleft is incompatible with your licensing strategy.
• You require modern features (SSO, accessibility workflows, analytics, captioning pipelines) that are not evidenced in this bundle's scope.
• You want a multi-platform video publishing strategy; a platform-specific bundle creates lock-in to PuMuKIT.

Adoption criteria (gate review): existing PuMuKIT+Opencast deployment, internal engineering capacity to fork/patch, legal sign-off on AGPL, and a validated compatibility matrix against your Opencast version.

How to Pitch It (Stakeholders)

To executives: This is a small, narrowly scoped open-source connector that lets our existing PuMuKIT web TV portal pull videos from an Opencast server and publish them to viewers. It is not a strategic platform bet — it is integration glue. The upside is speed: if we are already on PuMuKIT and Opencast, it can shortcut months of custom development for a lecture-capture publishing workflow. The risks are equally clear: the project is effectively unmaintained (last release 2020, one star, no downstream dependents) and carries an AGPL-3.0 license that may constrain how we distribute or host the service. Recommendation: treat it as a time-boxed proof of concept or reference implementation, with a fork-and-own plan if it proves valuable, not as a long-term vendor dependency.

To engineering: The bundle provides Symfony service wiring and controllers to authenticate against Opencast, import events, map metadata, and publish them into PuMuKIT. Expect to audit the code for compatibility with your Opencast API version, to own security patching, and to confirm the AGPL implications for your deployment model. If we are not on PuMuKIT, the honest answer is that this package is not the right starting point — a thin Opencast client in our own framework would be cleaner.