Product Decisions This Supports
- Build vs. buy vs. "don't build at all": This package is explicitly flagged DEPRECATED and the repository is archived. It should not factor into a build-vs-buy decision as a viable option — it is a negative signal, useful only as a data point in a "what not to do" evaluation.
- Event-streaming strategy for a Symfony/Laravel PHP stack: If you are evaluating Kafka integration for a PHP service, this bundle surfaces the historical pattern (thin Symfony wrapper over
php-rdkafka) but offers no modern implementation. It informs the architecture conversation — decouple producer/consumer config from framework internals — not the dependency selection.
- Roadmap risk assessment: Adopting this would introduce immediate tech-debt: no security patches, no PHP 8+ compatibility guarantees, no maintenance owner. This is a "known liability" input for a deprecation/upgrade planning ticket, not a feature-enabler.
- Migration and legacy-audit scoping: Relevant only if your codebase already depends on it (none of the tracked dependents here — 0). In that case it supports a decision to plan and budget a migration off the package toward a maintained transport.
- Vendor/ecosystem diligence: Low stars (8), zero dependents, no release since June 2017 — a concrete example of the "abandoned package" pattern your dependency-governance policy should catch automatically.
When to Consider This Package
Adopt only under narrow, defensive conditions:
- You are already running it in production and need a short-term pin while you plan migration. Even then, treat this as incident-response, not a strategy — the archive status means no fixes will ever land.
- You need a historical reference for how Symfony bundles wired Kafka at the configuration/DI level, e.g., during a spike evaluating a replacement.
- You are doing academic or archival code review of PHP Kafka tooling circa 2016–2017.
Look elsewhere — decisively — when:
- Any new build. Use
mateusjunges/laravel-kafka (Laravel-native, actively maintained), Symfony Messenger's Kafka transport, enqueue/rdkafka, or the php-rdkafka extension directly.
- You require PHP 8.1+ or Symfony 6/7 support. This package predates all of it.
- You need security patching, CVE response, or a support contract. Archived = zero.
- You have a compliance or supply-chain policy that requires maintained dependencies.
- You need Schema Registry, exactly-once semantics, or transactional producers — no evidence of support here, and no roadmap.
How to Pitch It (Stakeholders)
Bottom line: do not adopt. m6web/kafka-bundle is an archived, explicitly deprecated Symfony Kafka bundle — last release June 2017, 8 stars, zero dependents. It is a maintenance liability, not a capability.
For executives: "This is an abandoned library. Selecting it would put our event-streaming integration on code no one maintains, with no security updates and no PHP 8 compatibility — a foreseeable outage and audit risk. We should standardize on one of the actively maintained Kafka transports instead, at no meaningful extra cost."
For engineering: "Skip it. Use mateusjunges/laravel-kafka for Laravel services, Symfony Messenger's Kafka transport for Symfony, or php-rdkafka directly if you want minimal abstraction. Add a dependency-governance rule — archived repos, stale releases (>24 months), and near-zero dependents — to auto-flag packages like this in CI."
The one caveat to state plainly: if anything in our estate somehow still imports it, that's a migration ticket with a real timeline, not a "keep as-is." Everything else is a straightforward "no."