My story on maintaining packages

My story on helping others with PHP packages started with Joomla, Magento 1 and is now mainly focused on Magento 2 with only a small (growing) slice of Shopware 6 work. I joined Joomla in a time when WordPress did not exist, Drupal was creating their own design patterns in ugly functional code, PHP frameworks were merely beginning to adopt MVC and Joomla was a great choice.

I started to create various extensions, first offering them for free, then trying to make a buck out of it. Some became really popular, some of them did not. And some of them became popular without me knowing about. I still remember creating an Yth class (Yireo Template Helper) that could be used to do all kinds of checks in a Joomla template.

After years of maintaining it, seeing zero stars on GitHub, receiving zero feedback on it, I decided to pull the plug. And I ended up with 2 mails from 2 separate large theme vendors, that were shocked because they have been using Yth for years in their own commercial themes. Without me knowing about it. I'm still waiting for a postcard from them, after I unabandonded (is that a word?) the repository.

Packagist changed things

Composer changed things, or actually Packagist.org did. Suddenly there was this great reason to ditch PEAR and more importantly (well, from the perspective of this blog) to see some statistics on downloads. While with true open source projects, GitHub stars, Pull Requests and Issues are ways to see how healthy a project is, for the popularity under users, download statistics make more sense.

For instance, the Yireo GoogleTagManager2 extension was downloaded 225.930 times. And it has 91 stars. What the fork?

With additional comments to make

The statistics are misleading. First of all, there is the angle of the download number versus popularity that could be mistaken. And second, the download number itself is misleading - let me get back to that second point later on. Let me illustrate the first point with a couple of my extensions:

• Take a look again at the example of Yireo GoogleTagManager2. Great number you might say. But personally I consider it one of my worst projects, because I hate Google Analytics (so Tag Manager) and I hate leechers that only ask for support without contributing. Don't worry, I'm not going to pull the plug. (Even better, I plan to make major improvements still this year.) But the numbers show the popularity of downloads, not the popularity amongst human beings.

• Yireo DeleteAnyOrder2 had 28 downloads and 4 stars. Thanks, Simon. So this seems to be a very thin extension. However, believe it or not, the Magento 1 counterpart of this extension was sold more than 30.000 times for a price between 10 Euro and 100 Euro. Do the math to learn that you can become stinking rich in this business. Not me, because of partnerships gone wrong I didn't see a dime. The Magento 2 extension was kept commercial for some time as well, but this led only to 100 sales or so. Better to make it open source. But the numbers have fallen behind. Because of reasons.

• Yireo EmailTester2 has the same story as DeleteAnyOrder2, but different. The Magento 1 extension was popular, the Magento 2 extension was popular. But because the extension was sold using a Magento 1 shop, I needed to migrate this shop to Magento 2 and I decided the migration would be dead-cheap (as in: not needed) if I would drop all commercial extensions. The number of downloads (4614) is increasing every day, simply because all Magento Marketplace customers are now using Packagist. There are 10 stars. Thanks Simon.

So hopefully you can see that the Packagist number will give a different (or wrong) impression, if the extension has been on different platforms. But there is more: The number itself is wrong.

The download number

How does Packagist keep track of downloads? Simple, by just hooking into fresh composer downloads. Every time that somebody runs composer require a/b then the download stat of a/b goes up. If the second time that this command is run, the package is already in the composer cache, then there is no download. Now, composer caches might become outdated, they might be emptied manually (I include this as a troubleshooting tip) or the cache might not work at all.

And worse, in a lot of CI/CD environments (like my own GitHub Actions based on ExtDN) don't use caching either. Which means that every time that somebody would make a Pull Request towards one of my open source extensions, the Packagist number goes up. Hell, perhaps I'm personally responsible for half of the download statistic, with all of my releases, commits and testing.

Conclusion

The Packagist download numbers might look nice, because they are high. But note that these numbers do not equal real people, or usages in real-life projects. They are just not numbers. 42 is a nice number too.