To me, this feels almost inevitable for any service that might need to provide lots of storage to its users. It's actually kind of surprising how expensive most cloud storage is.
Personally, I just migrated over to having my own Nexus instance for all of my container images, with custom cleanup policies (e.g. dev repository is purged every week, prod one has a different policy), as well as there's the obligatory proxy repository that acts as a cache for pulling things from Docker Hub or elsewhere. Currently it's hosted in a VPS with a HDD, though if I need even more storage, I'll just move over to my homelab with more HDDs, which are way more cost effective than renting lots of space, even with smaller local providers.
Of course, for many it will be infinitely more cost effective (e.g. when they don't want a learning experience) to just pay Docker Hub or another provider to use their managed container registry. That might not always be viable when planning things for an enterprise setting, though, which is when this knowledge about self-hosting and on-prem deployments might come in handy.
> Now, GitLab is making changes to its free tier and may zap inactive repositories or repos that are too large.
In my eyes, that's probably the same problem and honestly the idea of purging data that nobody has accessed for a while seems like the logical outcome.
Let's take this argument to the extreme, just for fun - what would happen if GitLab would store this data in perpetuity (assuming the company survives)? Would we end up with 100 year old repositories by people whose descendants will manage them? Or, you know, a bit of a graveyard?
> When CentOS moved from a direct clone of RHEL 8 to the CentOS Stream model, hordes of people raised virtual torches and pitchforks because they were no longer able to run a freebie RHEL clone.
Here, I think there is more nuance. I think the thing that upset the community was not that CentOS was killed off (in its previous free-RHEL-alternative sense), but rather that the EOL was changed. Instead of announcing that CentOS 8 will be supported until its approximate EOL of 2034 (since most other releases were supported for ~10 years), instead they changed it to 2021, just 2 years after release.
Even CentOS 7 will outlive it, its life span being 2014-2024. So many enterprise deployments went wrong because of this choice and people were understandably upset. Moreso, there weren't really that many alternatives to it with a similar reputation: Rocky Linux took time to get up to speed, Alma Linux isn't quite as widely trusted and many would prefer not to use Oracle Linux for certain reasons.
Alas, it was a bit of a mess, especially when you are in circumstances where nobody will feasibly pay for RHEL but want something like it.