What RubyGems Stats Actually Reveal About the Ecosystem

May 4, 2026

Lately I’ve been checking RubyGems more often.

Part of that comes from having a couple of gems I care about, but also because it’s one of the few places where you can observe the Ruby ecosystem as a system, not just as isolated projects.

Today I stumbled into the stats section and it’s more interesting than it looks at first glance.

A quick look at the numbers

• ~192,000 gems published
• ~242,000 users
• 248+ billion downloads

At face value, that’s just scale.

But the real signal is in the ranking of most downloaded gems.

At the top, unsurprisingly, sits bundler. Right behind it: a cluster of AWS-related gems.

Then you start seeing familiar building blocks:

• i18n
• activesupport
• rake
• rack

The second page continues with equally recognizable names:

• concurrent-ruby
• json
• minitest
• nokogiri
• faraday
• rspec-core

Nothing shocking but very revealing.

This is not popularity it’s dependency gravity

One obvious question comes up:

Why is Ruby on Rails not at the top?

Because these numbers are not measuring what developers choose directly.

They measure what gets installed.

Every time you run bundle install, you’re not just installing your gems you’re pulling an entire dependency graph.

That means:

• Core libraries accumulate massive counts
• Infrastructure gems dominate the rankings
• High-level frameworks get “diluted” across their components

So what you’re really looking at is:

A map of the most structurally critical pieces of the Ruby ecosystem

Not the most “famous” ones.

Reading the ecosystem through its edges

Seen this way, the stats tell a deeper story:

• AWS gems → strong cloud integration footprint
• i18n → internationalization is not optional
• rack → the web abstraction layer remains fundamental
• json → serialization is everywhere
• concurrent-ruby → concurrency is increasingly relevant

These aren’t trends they’re constraints. They define what most Ruby systems must solve.

Where smaller gems fit in

Looking at this scale can be intimidating but also clarifying.

For example, some of my own work:

• ruby-libgd 0.3.0 → 4,077 downloads
• libgd-gis 0.5.0 → 5,340 downloads

These numbers are tiny compared to the billions above.

But that’s not the right comparison.

Gems like these live in a different layer:

• more specialized
• more domain-specific
• closer to actual problem-solving than infrastructure

They don’t need to dominate the dependency graph to be valuable.

They need to be useful in the right context.

RubyGems as more than a registry

What this reinforces is that RubyGems is more than just a distribution platform.

It acts as:

• a dependency graph index
• a telemetry source
• a discovery hub
• a bridge to source code and documentation

Even release notes like the recent Bundler and RubyGems updates become part of that ecosystem narrative.

Final thought

If you look at RubyGems stats as a leaderboard, you miss the point.

If you look at them as a graph, you start to understand the system.

And once you see it that way, even a few thousand downloads stop looking small they start looking specific, and that’s where real engineering usually lives.