RubyGems Blog

"Open Source Isn't Dead."

Well ...

Open Source as such will never "die", but we only need to look at what happened in, say, the last 5 or 10 years. Private entities with a commercial interest, have been flexing their muscles. Microsoft - also known as Microslop these days - with Github is probably the most famous example still, but you can see other examples. One that annoys me personally is Shopify's recent influence - rubygems.org is basically just shopifygems.org now. See: https://blog.rubygems.org/2026/04/15/rubygems-org-has-a-public-roadmap.html

"Contributors from both the RubyGems client team and Shopify are already working with us on making native gems a better experience for the Ruby community. "

There is a lot more I could add to this (see my complaint about how rubygems.org hijacks gems past the 100.000 download barrier; this was why I retired from using rubygems.org, and then the year afterwards ruby core purged numerous developers. The handwriting is soooooo clear that shopify flexed their muscles here).

I think we need to make open source development more accessible to everyone, not just corporations throwing their money to gain influence and leverage. I don't have a great idea to make this model work; economic incentives kind of have to be there too, I get that part, and I am not sure which models could work. But right now we really have a big problem. We can also see this with age sniffing (age verification - see the article that pointed at Meta at…

I think I basically agree with this, but my thoughts are more on which org is better placed now to respond to things like the recent supply chain attacks (ref for the specific recent ruby one[0][1]).

I'm unsure on who is better placed to handle that stuff now. My view is that the people that were doing that are now with gem.coop, but rubygems still has the infra (i.e. you'd email security@rubygems.org still for now).

I'm unsure about what to think about longer term (my personal approach is currently "wait and see").

Similarly, I'm perfectly happy with bundler for now, but if `rv` turns out to be like `uv`, I'd happily switch (drop-in replacement, but faster/some better features).

[0] https://www.bleepingcomputer.com/news/security/60-malicious-ruby-gems-downloaded-275-000-times-steal-credentials/

[1] https://blog.rubygems.org/2025/08/08/malicious-gems-removal.html

So, apologies for being a bit cynical here, but I don't see this one being addressed any time soon.

it's been at least 5 years since npm started getting scrutiny relating to security weaknesses https://blog.andyet.com/2012/03/08/compromising-the-integrity-of-the-npm-registry/

and 4 years since Rubygems was compromised http://blog.rubygems.org/2013/01/31/data-verification.html

and yet, I don't see substantial movements relating to package security and trustability in these repo's. To be clear I'm not suggesting these two are any worse than others, they're just large repo's who have had incidents in the past.

The problem here (to my view) is that increasing the security of package repo's will slow down releases (additional checks take time) and cost money (additional security, hosting etc) and until there's a market demand for those service, they won't happen.

I think you're right, but I suspect the root here is one of legal liability - if rubycentral is operating as a nonprofit that hosts _a recurring attack vector on other companies_, they'll have legal obligations to secure that service against those attacks. I assume they are continuously deploying out of that repository, and took the simplest route to controlling the attack vectors?

I'm not sure how anyone familiar with open-source communities would fail to predict the backlash though. They really should have forked the repository and switched the deployments over to their downstream fork (if I'm right about the root cause here).

(I'm mostly thinking in terms of supply-chain attacks, like this one: https://blog.rubygems.org/2025/08/25/rubygems-security-response.html)

> You can yank a version, which tells Cargo not to allow any projects to form new dependencies on that version, but the version isn't actually deleted

That's how RubyGems used to work, except you could contact the support team and ask them to permanently delete your gem version if something really sensitive and irrevocable was put into it. They had to change that due to their support log getting too big: http://blog.rubygems.org/2015/04/13/permadelete-on-yank.html