So, ignoring everything that got us here, what do people think about this? As I see it, there is the original rubygems, which has lost all of it's maintainers, and this new one, that has most of the original active maintainers? (how many were there before? it has most of the ones I think about, but I didn't know who was active over there. I mostly saw activity from deivid and didn't know about most of the others to b…
The suckiest thing is if the fork pans out, it will look a lot like JS: "Which package manager do you want to use?". That beautiful simplicity of "just use bundler and ruby gems" will be gone.
One thing I will give them massive credit for is walking-the-walk. There wasn't really that much complaining for the aggrieved maintainers of RubyGems. They made a public statement describing their grievances, then quietly got to work on a fork. Taking on a fork of RubyGems seems impossible and foolish, but they now have a non-zero chance of succeeding because they're doing it.
Most people I've talked to inside of big orgs are going to stick with the "safe boring" thing, which will probably be RC backed by Shopify. They will probably throw security bureaucracy at the problem, which will make SOC 2, ISO 270001 auditors. I don't think we'll see a lot of innovation coming from RC since the executive director is non-technical and has demonstrated a very ham-fisted approach to running the organization that seems to be out of touch with developers.
On the flip side, I think if gems.coop takes off, it will be because it's a "better mousetrap". One of the people behind it, André, is working on https://rv.dev, which promises to be a faster, "all-in-one", tool for managing ruby versions, gem dependencies, and even has an "npx-like" run this from from the CLI, the right version of Ruby will install, the gems will install, and it will run. That's a much better DX that I could see developers going for.
I've seen discussions on the periphery of adding namespaces to gems, bringing in checksums, and overall taking a more aggressive technical approach to security. I could see that "winning" over a long enough timeframe if RC continues on their current course.
From a fund-raising PoV, I'm starting to put together the clues that André believes organizations with the means to pay for OSS infrastructure should pay for it. I think I agree with this point-of-view and think it's a path for funding that's more transparent than "A group of donors". I hope we start to see infrastructure run in a manner where the costs are accurately estimated, then divided by the number of companies with the means to pay to arrive at the price.
There's absolutely on consensus on my final point, but I think the root cause of RC's catastrophic failure is having too much of a concentration of funding from a few donors. If you're new to this drama, a major donor pulled funding from RC because they didn't ideologically agree with a conference guest. The details are out there if you want to dive into it, but to keep this thread on point, I hope Ruby Co-op figures out how to spread out their funding model across 100's or 1000's so this doesn't happen again.