Gearman Bundle Laravel Package

Product Decisions This Supports

• Queue/background-job strategy for legacy PHP services. This bundle is the integration layer for Gearman, a pre-Redis-era job server, inside a Symfony application. It informs whether to keep, containerize, or retire an existing Gearman worker tier.
• Build vs. buy vs. adopt. It answers “do we wire Gearman into our app ourselves, or take a bundle?” — the answer here is neither: vendor the code if already in use, and treat new adoption as out of scope.
• Migration scoping and roadmap sequencing. If Gearman is on the deprecation list, this package marks the exact integration surface (services, DI config, worker commands) that a move to Symfony Messenger or Laravel queues must replace. That bounds the migration estimate.
• Maintenance-risk and tech-debt triage. Zero stars, zero dependents, and a fork lineage mean this is a single-point-of-failure dependency. That feeds a “replace or own” ticket in the debt backlog with a concrete owner and deadline.
• Platform fit checks. It surfaces the real constraint — Gearman requires the gearman PECL extension and a running gearman-job-server — which is an infrastructure decision, not a library one. That affects hosting, container images, and ops runbooks.
• Feature feasibility for async work (thumbnailing, email fan-out, PDF generation, webhook retries) where Gearman is already deployed: viable, but only with the caveats below.

When to Consider This Package

Consider it only as a short-lived bridge, and only when all of the following hold:

• You already run Gearman in production and have a Symfony (not Laravel) application that needs to enqueue or consume jobs. This is a Symfony bundle; it is not a Laravel package and will not drop into a Laravel app without a custom service provider and adapter work.
• The upstream mmoreram/GearmanBundle is unmaintained or incompatible with your PHP/Symfony version, and this fork is the only working option.
• Your team already operates gearman-job-server and the PECL extension, and understands its failure modes.
• You can pin the dependency to a specific commit, vendor or fork it internally, and accept that you own the code.

Look elsewhere when:

• The project is new. Use Symfony Messenger (with Doctrine, Redis, or AMQP transports) or Laravel’s queue system with Horizon. Both are maintained, tested, and observable.
• The app is Laravel. Use the native queue API; do not introduce Gearman. Reaching for this package means adding an unfamiliar daemon and extension to a stack that already solved the problem.
• You need retries, dead-letter handling, scheduling, a monitoring UI, or per-job timeouts. Gearman gives you almost none of this out of the box; you would be building it.
• You need a supported dependency. Zero stars and zero dependents is a direct signal: no community, no security response, no PHP-version guarantees. A single-maintainer fork with no downstream adoption is a bus-factor of one.

Practical diligence before any adoption: confirm PHP and Symfony version constraints, check whether the bundle wraps the PECL extension or speaks the protocol directly, read the test suite for coverage of failure and retry paths, and diff against upstream to see what the fork actually changed.

How to Pitch It (Stakeholders)

To executives: This is not a strategic dependency and should not be presented as one. It is a compatibility shim for infrastructure we may already be running. Adopting it costs nothing today but creates a maintenance obligation with no vendor, no community, and no upgrade path — effectively an internal fork we must own. The decision on the table is not “should we use this,” but “how long are we willing to run Gearman,” and the answer should include a dated exit.

To engineering: Treat it as legacy glue. Pin the commit, vendor it if it is already in the codebase, and isolate it behind an interface — a JobDispatcher abstraction with one Gearman implementation — so the transport can be swapped without touching call sites. That single seam turns a rewrite into a contained change. Then schedule the migration: Symfony apps to Messenger with an AMQP or Redis transport; Laravel apps to the native queue with Horizon. Both give us retries, failure queues, and visibility that Gearman does not.

Recommended framing: a two-to-three sprint, low-drama migration, scoped by the interface boundary, rather than an open-ended commitment to an unmaintained bundle. The risk is not that it breaks tomorrow; it is that it breaks in two years, on a PHP upgrade, with no one to call.