PointlessOne 
I see people working on alternatives to rubygems.org.
I don't know all the initiatives but one of the proposals is to set up an alternative gem index. With tiered access and higher tiers are paid and are supposed to finance the operation.
I'm glad people are organisig and doing something. But I think this is ultimately a wrong approach.
First, a simple caching proxy (such as Artifactory) can easily alleviate the need for a higher tier access to the index. And most big orgs already have something like that in place so won't even need additional effort.
Second, a centralised index is subject to all the same issues that befell rubygems.org. It's expensive, requiring some sort of financing on a regular basis. Eventually this might result in the very same issue: either become dependent to corporate interests, or shutdown. Tiered access might also be detrimental for mirroring which may or may not be desirable.
I suggest we should go distributed. Every project should host their gems wherever. Do you have a domain associated with your project where you host it's web site/docs? Host the gems there as well. See `gem generate_index`. Do you host your code on Codeberg/Forgejo? It also can host gems.
I'm not very concerned about gem hosting. We already have tools to do that without rubygems.org.
My bigger concern is that the tools are under… let's say, uncertain control.
RubyGems (the CLI) and bundler are under RC control. The repos can be forked and other people can work on them but, I'm afraid, that doesn't matter. Ruby (the language) bundles both rubygems and bundler. Can we convince Ruby maintainers to use a version that is not under RC control? I doubt. Given that HSBT is on the Ruby Core team, and he was instrumental in the takeover, and that there was no concern voiced by anyone else from Ruby Core team, I take it this move is supported by the Ruby Core.
I'm afraid that any effort to take the development back to the community is futile because of this.
I suspect that for a while all the projects will keep accepting contributions from the community, and will keep insisting they're for the community benefit. But eventually there will be some change that goes against the community interests but is requested by some corporate backer and RC will show their chosen side again. All community concerns will be ignored and the change will be implemented anyway.
My concern is that Ruby transitions from a community, a diverse network of projects to an openly extractive ecosystem. A few wealthy corporations fully control the development of the technology and extract existing value, ride the inertia of the community.
This is a natural progression of every technology. Enthusiasts go elsewhere as the technology stagnates and new shiny things appear, while big corpo stays as it's expensive to migrate away. They become the only benefactors, and effectively, supporters of the technology. And since there's not much interest anyway they can stir it wherever they want.
This certainly was happening with Ruby for a while. The concern that Rails is the major use case for Ruby was around for years. New alternative technologies appear and mature so there are places for people to go, while Ruby has not found new niches to expand to.
RC takeover of rubygems/bundler greatly accelerated this natural process. Whether there was corporate pressure, a prominent figure in leadership ego burst, a malicious intent, or a fumbled attempt at stewardship backed by the best intentions, either way the community is effectively removed from the tools development. Maybe not completely but I find surprising (mostly) silent agreement between RC, Rails Core, and Ruby Core. Basically all technical leadership of the most prominent parts of the Ruby ecosystem are perfectly aligned between themselves even when there's a great deal of concern and uncertainty in the community.
reinteractive
Joshua Wood
FastRuby.io
Mark Wyner Won’t Comply 
Rad Web Hosting
Tropical on Rails
Raff de Blois
Matt Jordan
Yesterday's Rose