Pumukit Blackboard Bundle Laravel Package

Technical Evaluation

Architecture fit. teltek/pumukit-blackboard-bundle is not a general-purpose library — it is a Symfony bundle that only functions as a plugin to a running PuMuKIT instance (Teltek's open-source, Symfony/MongoDB-based video platform). Its scope is narrow and prescriptive: it adds an import/ingest API surface that lets a Blackboard LMS instance push or expose course-associated video content into the PuMuKIT media catalogue. Outside a PuMuKIT deployment it has essentially no reusable value; the code is wiring (DI configuration, routing, controllers, and a Blackboard-facing client/service) against PuMuKIT core domain objects. The "Laravel/PHP package" framing in the intake record is inaccurate and is itself a red flag for whoever triaged it.

Integration feasibility. Composer-installable in principle, but feasible only under a conjunction of preconditions: a PuMuKIT deployment at a compatible release, a Symfony major version that matches the bundle's constraints, MongoDB ODM and PuMuKIT core services present, a reachable Blackboard tenant with the correct API credentials and the matching Blackboard-side integration (REST/LTI vs. legacy Building Block), and network/security changes to expose an ingest endpoint. None of these preconditions are documented in a way a TPM can verify from the repository alone — no released version matrix, no compatibility table, no example configuration.

Technical risk: High.

• Bus factor / abandonment. 0 stars, 0 dependents, negligible score. There is no community, no downstream validation, and no evidence of use beyond the vendor's own customer base. Assume single-vendor maintenance with no obligation to respond to issues.
• Coupling risk. Tight coupling to PuMuKIT internals means every PuMuKIT upgrade is a potential breaking change, and we inherit PuMuKIT's own upgrade treadmill.
• Security surface. An unauthenticated-or-loosely-authenticated content ingest endpoint is exactly the class of component that needs a threat model before it touches production.
• Contract risk. The Blackboard integration contract (auth model, payload schema, pagination, idempotency) is undocumented here; we cannot size the work until we read the code.
• Licensing. Must be confirmed before any fork-and-own decision.

Key questions for the vendor/repo.

1. Which PuMuKIT release(s) and Symfony major version does this track — and is the constraint declared in composer.json?
2. Which Blackboard integration is implemented: REST API, LTI 1.3, or legacy Building Block/SOAP? Does it pull from Blackboard or receive pushes?
3. What is the authentication and authorization model on the ingest endpoint, and how are tenant/course mappings resolved?
4. Is the import idempotent? What happens on partial failure, retry, or duplicate delivery?
5. Does it hand media off to PuMuKIT's transcoding pipeline, or does it assume pre-transcoded input?
6. Who maintains it, what is the release cadence, and is commercial support required?

Integration Approach

Stack fit. The decisive question is our runtime. This bundle is Symfony-only and cannot be dropped into a Laravel application — there is no service provider, no facade, no Laravel-style config publishing, and its controllers are bound to Symfony's HTTP kernel, DI container, and routing. Two viable paths:

• Path A — we operate PuMuKIT. Register the bundle in the kernel, expose and secure its routes, supply Blackboard credentials, and pin versions. Lowest effort, highest lock-in.
• Path B — we operate anything else (Laravel or bespoke PHP). Do not attempt to install it. Treat the repository as a reference implementation for the Blackboard ingest contract, and re-implement the adapter natively: a Blackboard API client, a normalizing mapper into our media model, and a queue-backed ingest job. This is the recommended path unless PuMuKIT is already strategic.

Migration path. No migration is implied — this is greenfield integration, not a replacement. If Path A, there is no data migration; if Path B, the "migration" is knowledge transfer from their code into ours, which is cheap because the repo is small and readable.

Compatibility. Pin Symfony and PuMuKIT to exact versions, vendor the package into our own namespace if we fork, and add CI that runs against the pinned matrix. Do not accept floating constraints on a 0-star dependency.

Sequencing.

1. Confirm runtime strategy (Path A vs. B) — this gates everything.
2. Stand up a disposable PuMuKIT environment in a sandbox; read the bundle source end-to-end (half a day for a senior engineer) and extract the actual API contract.
3. Provision a Blackboard developer/test tenant and credentials; this is typically the longest lead-time item — start it in parallel on day one.
4. Smoke-test the endpoints end-to-end with a small, representative content set.
5. Document the contract as an OpenAPI spec — this is the deliverable that survives regardless of path.
6. Decide fork-vs-reimplement based on that spec, then harden auth, idempotency, and observability.

Operational Impact

Maintenance. Budget for owning this code, not consuming it. With zero dependents, we are the only ones who will notice a break. Expect to fork, pin, and patch; upstream contributions are unlikely to be reviewed on our timeline, if at all. Assign a named owner and add it to the dependency register with a review cadence.

Support. Effectively commercial-support-only, via Teltek. There is no community forum backstop, no Stack Overflow corpus, and no third-party integrators to hire. If a support contract is not on the table, treat the package as unsupported software and price the internal expertise accordingly.

Scaling. The bundle's own footprint is thin — an API surface plus mapping logic — so it is unlikely to be the bottleneck. Real scale pressure lands downstream: transcoding, object storage, and the media database. Design the ingest path to be asynchronous and queue-backed from day one so Blackboard burst uploads (e.g., end-of-term lecture dumps) don't saturate the web tier or trip request timeouts on large files.

Failure modes to instrument for.

• Blackboard credential expiry or rotation → silent import stoppage; alert on zero successful imports per interval.
• API rate limiting / throttling during bulk sync → partial catalogues with no error surfaced to the LMS side.
• Schema drift on the Blackboard side → deserialization failures that look like empty payloads.
• Non-idempotent retries → duplicate media records; require a dedupe key on external content ID.
• Large-file upload timeouts and half-written media assets; need cleanup/reconciliation.
• MongoDB/PuMuKIT-side write failures mid-import leaving orphaned records.
• Upgrade coupling: a PuMuKIT or Symfony bump breaking DI wiring at deploy time with no test coverage to catch it.

Ramp-up. Steep and narrow. A competent PHP engineer needs roughly two to four weeks to become productive, and that time is dominated not by this bundle but by PuMuKIT's domain model (media objects, series, tracks, transcoding profiles) and Blackboard's integration semantics. The bundle itself is a one-to-two-day read. The scarce skill is the intersection of Symfony bundle architecture, PuMuKIT internals, and LMS integration — assume exactly one person can hold this, and plan for knowledge duplication before that person becomes a single point of failure.

TPM recommendation. Do not adopt as a dependency on the strength of the repository signal (which is effectively nil). Adopt the contract, not the code: mine this bundle for its Blackboard integration design, then implement the ingest path in our own stack. Revisit only if PuMuKIT is already a committed platform decision.