That list is of the top packages. If internal Mozilla tools are downloaded enough to become top 200, then either Mozilla is larger than I thought or Python is smaller than I thought.
Download counts -- which usually power "most popular" charts -- are extremely misleading, because usually every run of an automated CI system triggers a download.
Arguably that works better as an indicator, as you can see which packages are being actively developed with. But that's beside the point.
Are you suggesting that Mozilla's CI system runs so often as to artificially inflate the download numbers of their internal only packages to the top 200 Python packages? Because if so, then my point still stands. Either Mozilla is a lot bigger than I thought or the Python community is a lot smaller than I thought.
I also am of the belief that if any team would think to cache their dependencies, it would be the team behind a modern browser.
Keeping in mind it's been a few years (my last day at Mozilla was in mid-2015), and I was in the web dev org, not the browser...
The sheer number of platforms, variants, etc. of the browser and the number of test runs that need to happen are mind-blowing. So it's entirely within the realm of believability for me that the mozbase packages (which provide a lot of the foundation for all of that automated infrastructure) could hit the most-downloaded list. It's not that Mozilla is necessarily that much bigger than other big-name tech companies, it's just that Mozilla open-sources everything by default and puts most stuff on PyPI.
As an aside, though, I think people do tend to underestimate the scaling stuff Mozilla deals with. Once I got to give a conference lightning talk pointing out we could probably claim the highest-traffic Django deployment in the world, for example (the version check done by Firefox on startup, if you're curious, is or at least was a Django-backed service). Though I'm pretty sure Instagram has taken that title now; back in 2013 when we talked about that we "only" served on the order of a billion requests/day :)
Even things like MDN -- which is what I worked on in my time there -- presented interesting challenges. Building a wiki with the kinds of features technical writers need, that's still responsive and fast to build and render the pages post-edit and capable of handling the traffic of a top-300-ish (Alexa currently puts MDN at #107 worldwide) site, isn't entirely simple to do.
