The Magento Marketplace + EQP Slowdown — Why It Matters in 2026

The Magento Marketplace and its Extension Quality Program (EQP) are the official channel for publishing third-party modules to Adobe Commerce and Magento Open Source 2.4.4 — 2.4.9 stores. For roughly a decade the deal was clear — pay the fee, get an EQP code review, ship to a trusted catalog. In 2025–2026 that exchange has quietly fallen apart. The 14-day baseline is gone, vendor flight is measurable, and merchants paying for Marketplace-only extensions are absorbing risk the badge no longer absorbs. This is the editorial read from the kishansavaliya.com vantage — what changed, who left, where merchants are exposed.

EQP is no longer the fast-lane it was sold as, and the vendor economy is routing around it.

The Marketplace^[1] shipped EQP as a quality gate — coding-standards scans, security checks, compatibility testing, and a manual code review before any vendor submission goes live. The published expectation circa 2020–2023 was a 14-day end-to-end review for an ordinary submission. Vendors planned release cycles around that number. Merchants timed patch rollouts around it. The whole Marketplace value proposition leaned on it.

Across 2025 and the first half of 2026, vendor-side reports tell a different story. The same submission shape that used to clear in two weeks now sits in queue for 30 to 60 days. Some non-critical updates have been observed past the 90-day mark with no reviewer response. The EQP team has not published a public SLA revision; the slowdown is what vendors and merchants discovered by trying to ship.

When the queue gate goes opaque, the people who can move route around it. Marketplace did not lose vendors to competitors — it lost them to GitHub.

Effect 1 — Vendor flight: GitHub, Hyvä Marketplace, and Mage-OS are the new shelves

Small and mid-size extension shops are the most visible movers. A two-or-three-person vendor cannot finance a 60–90 day cash-flow gap on every release. The math is simple — at 14 days a vendor could ship a patch and recognize revenue inside a sprint. At 60 days the working-capital cost of every release tripled and predictability collapsed.

The flight pattern is consistent across the vendors we work with at kishansavaliya.com. The pragmatic answer for a small shop is to publish on GitHub, ship via Composer through a private Packagist or public release tag, and document the install path on the vendor's own site. Yireo^[2], Hyva-Themes^[3], MGS, and many one-developer publishers have operated this way for years. The 2025–2026 EQP slowdown turned that minority pattern into a majority one.

"We pulled three of our 2026 releases out of EQP after they crossed 45 days in queue. We ship through Composer now. Our customers update faster, our refund rate dropped, and we no longer time releases against a queue we cannot see into." — paraphrased from a Hyvä-compatible vendor we ship with

The second destination is Hyvä Marketplace^[4]. Hyvä Themes runs its own compatibility program — automated PHPCS, manual review for frontend overlays, and a badge against a tracked Hyvä version. The cadence is published, the reviewer is reachable, and the queue does not exceed two to three weeks in 2026. For a Hyvä-focused module the choice between EQP and Hyvä Marketplace is no longer a debate.

The third destination is Mage-OS^[5] — the community fork that maintains module mirrors and patches for the Open Source codebase. It is not a paid marketplace; it is a coordination project that keeps forks updated when an upstream vendor goes quiet. For Open Source merchants this is the safety net under everything else.

Effect 2 — Merchant risk: security patches in limbo and unsigned vendor zips

The second knock-on is the one merchants feel directly. When a vendor identifies a security issue in their own module and submits a patch through EQP, the patch is gated by review. A 14-day window is recoverable. A 45-day window is not — not for anything security-relevant. The vendor has the fix, the merchant has the unpatched module, and EQP is the gate between them.

The work-around the ecosystem has settled into is the unofficial channel — the vendor emails affected customers a zip outside Marketplace, the customer installs it manually, the formal listing updates whenever EQP gets to it. That removes the entire vetting layer. The merchant is now installing an unsigned zip from a vendor's email into a production Magento 2.4.4 — 2.4.9 instance, with no Marketplace audit trail.

# the unofficial workflow merchants are running in 2026
wget https://vendor-site.example/private/vendor-module-2.3.7-hotfix.zip
unzip vendor-module-2.3.7-hotfix.zip -d app/code/Vendor/Module/
bin/magento setup:upgrade
bin/magento setup:di:compile
# no signature check, no diff against the Marketplace-listed version, no audit log

Every Open Source security audit we have run since mid-2025 has surfaced at least one module installed through this informal channel. The merchant did the right thing — they applied a vendor-supplied patch as soon as they had it. The Marketplace gate that was supposed to make that decision safe was not in the loop.

Effect 3 — Adobe's incentive: Marketplace revenue is small, Adobe Commerce subscriptions are not

The harder editorial read is on Adobe's side. Marketplace is a cut of vendor revenue plus a per-release submission fee. Adobe Commerce subscriptions and the Edge Delivery Services stack are an order of magnitude larger as revenue contributors. EQP review is engineering staffing that produces a small revenue line.

Inside any large software company, that revenue gap shows up in prioritization meetings. EQP queue throughput competes with Edge Delivery Services rollouts and the Adobe Commerce 2.4.9 release itself. The slowdown is the empirical evidence of that prioritization, even if Adobe has never said it on a public roadmap.

The asymmetry that matters for merchants — Adobe Commerce subscribers get expedited paths through their account teams. Magento Open Source merchants who paid only the per-extension fee do not. When the queue gets long, it does not get long evenly.

Channel-by-channel: vetting, review time, cost, coverage

Here is the honest comparison across the four channels a Magento 2.4.4 — 2.4.9 merchant can buy modules through in 2026. The numbers are the operational reality vendors and merchants are reporting in 2025–2026, not historical baselines.

The worst-case lock-in scenario for a Magento Open Source merchant

Lock-in does not feel like lock-in until the vendor goes quiet. Here is the scenario we have audited three times in 2025–2026 — names anonymized.

A Magento Open Source 2.4.7 merchant runs nine paid Marketplace extensions covering tax, B2B, search, customer attributes, and a custom layered nav. Total Marketplace spend over four years is roughly $9,000. In late 2025 the merchant kicks off a 2.4.9 upgrade. Three of the nine vendors have not shipped a 2.4.9-compatible release. Two have updates in EQP queue 8+ weeks. One vendor has gone quiet entirely — the support inbox bounces, the listing is unmaintained, the GitHub mirror is untouched since 2024.

The merchant's options are all bad. Wait for EQP — upgrade delayed indefinitely. Apply the unofficial vendor zips — install unsigned code into production. Fork the abandoned vendor's module — take on maintenance of a domain the merchant does not own. Rip and replace nine extensions mid-upgrade — triple the project cost. There is no clean exit because the Marketplace's vetting promise was the reason the merchant did not keep an in-house evaluation process for these vendors in the first place.

The EQP badge was supposed to remove the need for a merchant to maintain vendor evaluation muscle in-house. When the badge stopped meaning "reviewed in 14 days", that muscle had already atrophied.

Practical procurement playbook for 2026 Magento Open Source merchants

None of this means abandon Marketplace. It means treat Marketplace as one channel among four. The playbook we recommend to clients on Magento 2.4.4 — 2.4.9 in 2026:

• Hyvä storefront modules — buy through Hyvä Marketplace^[4] first. The compatibility program is the gate that actually moves.
• Backend modules from GitHub-first publishers — Yireo^[2], Hyva-Themes^[3], MGS, Mageplaza for select modules — go direct via Composer. The vendor's own release engineering is the gate.
• Marketplace-exclusive modules — buy them, but maintain in-house evaluation: a code-read before install, a Composer pin to the version you reviewed, and a CI regression test on every update.
• Abandoned modules — check Mage-OS^[5] for a community fork before you fork in-house. The community fork has more eyes than a single-developer one.
• Security patches in EQP limbo — apply them, but through a versioned internal Composer repository, not vendor email zips. The audit trail is the difference between "hotfixed properly" and "unsigned code in production".

What this means for Marketplace itself

The Marketplace is not going away. The catalog is too broad and Adobe Commerce-tier merchants still need it. What is changing is the role. Marketplace is settling into being one channel among four rather than the default, and the EQP badge is reverting to what it actually is — a quality signal at point-of-purchase, not a guarantee of post-purchase patch velocity.

For a healthy 2026 procurement workflow on Adobe Commerce and Magento Open Source 2.4.4 — 2.4.9, that is the right mental model. Treat EQP as a credit-rating, not a service-level agreement. Buy from the channel whose review cadence matches the patch cadence you need. Keep an exit path from every vendor. And keep enough in-house muscle to read a module's code before it ships — the channel that promised to do that for you cannot promise the timeline anymore.

Related reading

• Magento 2.4.9 upgrade traps — five issues not in the release notes
• PWA Studio vs Hyvä — the honest 2026 comparison
• Hire me — Magento + Hyvä audits and sprints