Open-Source Magento 2 Extensions in 2026

How big is the open-source Magento 2 ecosystem in 2026?

Bigger than it looks from any one vantage point. The harvest behind this guide merged three sources, each with a different blind spot, and counted 7,769 public Magento 2 repositories and packages active in the last two years. "Active" means a git push or a Packagist release between 2024-10-11 and 2026-10-11; forks, archived and private repositories were excluded.

The practical consequence: a team that evaluates extensions with a single magento2 search on GitHub is choosing from roughly half of what exists. A team that only reads a curated list is choosing from about two percent of it. Neither half is systematically better than the other; the split is driven by metadata, not by code quality.

Why do good modules stay invisible?

Three layers of metadata decide whether a module is ever seen. Most of the ecosystem is missing at least one of them.

Stars. Of roughly 6,100 modules in the catalog, about 3,570 have zero stars and about 5,100 have fewer than five. Stars are often read as a quality signal. In this ecosystem they are mostly an exposure signal: a module gets stars after it is discovered, and discovery depends on the two layers below. A zero-star module is not evidence of a bad module; it is evidence that nobody was pointed at it.

Packagist. About 3,630 entries are not on Packagist at all. A module that cannot be installed with a plain composer require from the public registry needs a VCS repository entry or a manual copy. Most teams evaluating options will not take that step for something they have never heard of, so these modules are rarely trialled and rarely starred.

Topics. Roughly three quarters of the entries carry no GitHub topics. Only about 1,620 carry the magento2 or magento-2 topic, and those two topics are what most discovery tooling queries. A repository without them is outside the loop that feeds every list, bot and dashboard built on top of GitHub.

Put together, the mechanism is circular. Discovery tools query topics. Search results rank by stars. Stars come from being discovered. A module that starts without topics, a description or a Packagist package has no way into the loop, regardless of how well it is written.

How much do curated lists actually cover?

Very little, and the gap is structural rather than careless. Only around 100 modules appear in any curated list that was checked, about two percent of the active catalog.

Curated lists are small by design. Most are fed by a narrow input, such as a few GitHub topics or a handful of known organisations, and then filtered by quality gates: a minimum number of stars, a license, recent activity. Those gates are sensible. The problem is the funnel in front of them:

• The input is narrow. A repository without the expected topics is never seen, and most of the ecosystem has none.
• A missing license is an automatic no. 232 active repositories with 10 or more stars have no license file. Many are usable; they are simply missing one file.
• Lists move slower than the ecosystem. They are kept up by hand or by small bots, so new modules arrive late and quiet ones can stay listed long after they stop changing.

None of this makes curated lists wrong to use. It makes each one a small sample, not a map. The atlas marks every entry that appears in a curated list so you can see what the sample looks like against the whole.

What should a team evaluating extensions do differently?

Stop treating star count as the first filter. It removes most of the ecosystem before any real evaluation starts, and it keeps popular-but-abandoned modules at the top. Replace it with signals that measure maintenance and fit:

• Last activity, and what kind. A tagged release is a stronger signal than a push. A module with no stars and a release last month can be in better shape than a popular one whose last push predates the Magento version you run.
• Install path. Is it on Packagist with the right type? If not, the module can still be excellent, but you own the composer wiring and the update discipline.
• Supported versions, stated. A README that names the Magento and PHP versions it was tested against. Silence here usually means nobody checked.
• License. No license means you have no right to use it in a commercial store, however good the code is.
• Tests and a changelog. Either one shows that someone expects the module to be upgraded rather than installed once.

The atlas is built for this kind of evaluation: sort by "Recently active", leave the minimum stars at zero, filter by kind, and search by the function you need rather than by a module name you already know. Then apply the code review checklist to the shortlist, because none of these signals replaces reading the plugin and observer declarations.

What should a maintainer do to get found?

The fix is not marketing. It is a short list of metadata changes, each of which opens one discovery channel that is currently closed. In order of effort:

1. Add GitHub topics. At minimum magento2, magento2-module and adobe-commerce, plus topics for what the module does (checkout, shipping, payment, hyva, b2b, erp). This is the single change that puts the repository in front of every bot and list that exists today.
2. Write a description. One sentence in the repository description field. It is indexed by GitHub search and shown in every list, including the atlas.
3. Add a LICENSE file. Pick one and commit it. Without it the module is rejected automatically by curated lists that require one, and is unusable by any company with a legal review.
4. Publish to Packagist with "type": "magento2-module" in composer.json. This is what makes the module installable with one command, and it is how the roughly 1,350 "Packagist only" modules get found even when GitHub search misses them.
5. Tag a stable release. A 1.0.0 tag tells evaluators the author considers it usable, and it gives composer a version to pin.
6. Write the README that the quality gates look for: purpose, installation, supported Magento versions, requirements. This is the bar curated lists apply, and it is the bar most evaluators apply without writing it down.
7. Then submit to curated lists. Only after the six steps above; a submission that fails the license or README check is wasted.

A maintainer who does all seven moves from the invisible majority into the small set that search, package managers and lists all agree on. Check the result in the atlas after the next refresh: the entry should carry the packagist tag, the topics, and eventually the curated-list tag.

How was the atlas built, and how should you read it?

The Magento 2 Extension Atlas merges three harvests by repository. GitHub search ran 14 queries for magento2, magento-2, "magento 2", magento and mage-os in names, descriptions and topics, plus the topics magento2-module, magento2-extension, adobe-commerce, hyva and mage-os, each split into date windows to stay under GitHub's 1,000-result cap. Packagist contributed all 11,810 packages of the four Magento 2 types with their last release dates. Public curated lists of Magento 2 extensions contributed their links, which are used to find candidates and to set the curated-list tag; the lists themselves are not extensions and are not entries. Stars, topics and last push come from the GitHub API.

Two reading rules. First, "kind" is the Packagist type where one exists and a heuristic from the name and topics otherwise, so a few entries are mislabelled. Second, the catalog includes Magendoo's own repositories under github.com/magendooro; they were harvested and ranked like every other entry and get no special placement.

The data is refreshed periodically and every refresh replaces the whole set. Maintainers who find an entry wrong, or who would rather not be listed, can write to [email protected].