The Activity Assumption
Enterprise technology decisions often rely on a proxy metric: development activity. If a framework ships frequent releases, attracts contributors, and maintains a steady commit cadence, the assumption is that security follows. The logic feels sound. Active projects fix bugs faster, respond to disclosures promptly, and signal ongoing investment. Joomla tests that assumption against data and the results are instructive.
Joomla averaged 644 commits per year in WebPulse's latest GitHub collection. It maintains 283 active contributors. It shipped 50 releases. By every conventional measure of project health, Joomla is alive and functioning. The open-source community is engaged. The release pipeline is disciplined. And yet Joomla carries 1,313 CVEs in the National Vulnerability Database, earning a WebPulse composite score of 63 out of 100.
What the Numbers Actually Say
The disconnect between Joomla's activity metrics and its security profile is not a paradox. It is the predictable outcome of maintaining a large, monolithic codebase with an extensive plugin ecosystem and backward-compatibility constraints stretching back two decades. Commits do not erase architectural debt. Releases do not eliminate attack surface. Contributors do not reduce the number of code paths that accept untrusted input.
Compare Joomla's profile to Next.js. Both shipped 50 releases in the same period. Next.js averaged 5,706 commits per year from 427 contributors and holds a WebPulse score of 90. Its CVE count stands at 92. The gap is not explained by effort — Joomla's contributors are putting in work. The gap is explained by architecture. Next.js was designed for a world of server-side rendering, API routes, and edge functions. Joomla was designed for a world of shared hosting, PHP templating, and FTP deployments. Both have evolved, but their foundations set different ceilings.
Astro offers another instructive comparison. With 2,909 commits per year, 335 contributors, and 50 releases, Astro matches Joomla's release cadence with roughly four times the commit velocity. Astro's WebPulse score is 90. Its CVE count from the NVD is negligible. Astro achieved this not by working harder than Joomla but by starting with a fundamentally different architecture: static-first output, island hydration, zero client-side JavaScript by default. The attack surface was designed out, not patched away.
The Illusion of Progress
Joomla's 5,094 GitHub stars place it well below the community enthusiasm curve of modern frameworks. Next.js has 140,000 stars. Astro has 60,000. Star counts are imperfect proxies for adoption, but the ratio matters: Joomla has roughly 3.6% of the community signal that Next.js commands, while carrying more than fourteen times the vulnerability count. The efficiency of each commit, measured against security outcomes, diverges dramatically.
This is not an argument that Joomla's maintainers are negligent. The project's activity metrics confirm genuine investment. But the data reveals a structural problem that effort alone cannot solve. Each Joomla release must maintain compatibility with extensions, templates, and hosting environments that predate modern security practices. Each commit operates within an architecture that was not designed to minimize attack surface. The result is a treadmill: significant effort producing marginal security improvement.
What Executives Should Measure Instead
The Joomla case illustrates why procurement and risk teams need to look beyond activity dashboards. A framework that ships 50 releases per year can still carry four-digit CVE counts. A project with hundreds of contributors can still score in the bottom third of WebPulse's composite index. The metrics that matter are not inputs (commits, releases, contributors) but outputs (CVE density, vulnerability severity distribution, time-to-patch, and architectural attack surface).
WebPulse's seven-dimension scoring model weights security data from the NVD alongside GitHub activity, community engagement, and AI readiness. The composite score is designed to capture exactly the nuance that single-metric dashboards miss. Joomla scores well on community and release cadence. It scores poorly on security. The composite reflects both realities, landing at 63 — a number that tells decision-makers more than any individual metric could.
The Decision Framework
Organizations running Joomla face a decision that activity metrics alone will obscure. The project is maintained. Updates are available. The community exists. But 1,313 CVEs represent a cumulative attack surface that each new release inherits. Migration is expensive and disruptive. Staying carries compounding risk. The data does not make the decision for executives, but it reframes the question. The relevant question is not whether Joomla is active — it is. The relevant question is whether activity, absent architectural change, produces the security outcomes the organization requires.
The cost accounting matters. Each CVE in Joomla's record represents an incident response cycle, a patch evaluation, a testing window, and a deployment risk for every organization running the platform. Multiply 1,313 vulnerability records by the operational cost of evaluating each one, and the cumulative burden on IT and security teams becomes a line item that activity dashboards never surface. Next.js at 92 CVEs and Astro at negligible counts impose a fraction of this operational overhead on their adopters. The framework choice is not just a technology decision — it is a recurring cost structure that compounds annually.
