Pumukit Podcast Bundle Laravel Package

Product Decisions This Supports

• Distribution surface expansion (roadmap): whether recorded media becomes subscribable in Apple Podcasts, Spotify, and Overcast, versus staying behind a portal login. Podcast feeds answer "can our lecture archive travel with the learner?"
• Build vs. buy for feed generation: RSS 2.0 with <enclosure> and the iTunes namespace is a bounded, well-specified problem. This bundle is the "buy" option — but only if you are already inside Pumukit. Outside that ecosystem, the buy side of the ledger is empty.
• Audio-first / low-bandwidth tier: extracting audio tracks into a podcast feed is a cheap accessibility and offline-learning feature. Useful for commuter, part-time, and low-connectivity personas who will not stream video.
• Series vs. asset modeling: forces an explicit decision on whether the catalog is organized as channels/seasons/episodes (podcast-native) or courses/recordings (VLE-native). The channel abstraction here is a hint at how much mapping work the integration really costs.
• Not a platform bet: with 1 star and 0 dependents, this is a tactical enabler inside a Pumukit deployment, not a strategic dependency. Treat any adoption decision as "vendor and own," not "integrate and rely."

When to Consider This Package

Consider it when:

• You already run Pumukit (Symfony-based, not Laravel) and need podcast feeds without bespoke development.
• Your media model already matches Pumukit's document/track/series structure — the bundle's real value is the wiring to that model, not the RSS itself.
• You need iTunes-compatible feed semantics (enclosures, episode metadata, artwork) quickly and can accept the bundle's conventions.
• You have the appetite to fork and own the code — treat it as a reference implementation you vendor into your repo.

Look elsewhere when:

• You are on Laravel or a non-Pumukit Symfony application. Integration cost will likely exceed writing the feed generator yourself; the spec is small and well documented.
• You need active maintenance, security patching, or a support contract. The signals here (1 star, no dependents) point to a low-traffic project with no upstream safety net.
• You need podcast analytics, dynamic ad insertion, DRM, or per-listener tracking — all outside this bundle's scope.
• You need multi-tenant or high-volume feed generation. You will want CDN caching and a purpose-built publisher rather than a bundle bolted onto an application server.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost way to push existing recorded content into podcast apps — a reach and accessibility play, not a new product line. Upside is incremental audience at near-zero licensing cost; the risk is that the package is effectively unmaintained community code, so adoption implies a small, ongoing engineering ownership cost. Recommend it as a scoped experiment with a defined pilot audience, not a platform commitment.

To engineering: It is a Symfony bundle for Pumukit — RSS and enclosure generation bound to Pumukit's media model. Assume we vendor or fork it rather than depend on upstream. The feed spec is the easy part; the real work is catalog-to-channel mapping and getting enclosure URLs right behind our CDN and signed-URL scheme. Validate PHP/Symfony version compatibility and the maintenance health of Pumukit itself before we commit, and size the effort as a spike plus a small owned module, not an integration project.