9 ms·

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,

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 be honest). It kind feels like this fork is the better maintained piece of software now. Does anyone have any thoughts on this? Are any people thinking of moving over soon? Is there any information on what the funding model will be? Also @joeldrapper/anyone is there anything you can share about how the hosting is being covered?[0] [0] https://news.ycombinator.com/item?id=45490386 https://news.ycombinator.com/item?id=45490386

mijoharas 1y ago
re: funding model, looks like it's TBD[0] [0] https://bsky.app/profile/indirect.io/post/3m2j2pcinz22j https://bsky.app/profile/indirect.io/post/3m2j2pcinz22j
baggy_trough 1y ago
I personally cannot think of a new ruby gems or bundler feature from the past decade that I noticed or cared about. That isn't to say that there aren't any; I just don't know what they are.
- frenkel 1y ago
  Lockfile checksums are quite new and useful.
- mijoharas 1y ago
  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/ https://www.bleepingcomputer.com/news/security/60-malicious-... [1] https://blog.rubygems.org/2025/08/08/malicious-gems-removal.html https://blog.rubygems.org/2025/08/08/malicious-gems-removal....
  - knowitnone3 1y ago
    Socket.dev states "Since at least March 2023". RubyGems says "Our team first detected this activity on July 20th". This attack has ran for almost 5 months undetected. I wouldn't feel reassured at all.
- ilikepi 1y ago
  There have been several releases with incremental but still notable performance improvements. The overall cadence has been pretty steady, intentionally targeting roughly one minor release per year since 2019-ish, with handfuls of quality of life improvements in each. Arguably RubyGems and Bundler are infrastructure, so the major feature is stability. What sort of big feature are you imagining is missing from your dependency management system?
  - x0x0 1y ago
    André is working on a combination of rbenv/asdf, bundler, and gem that I think is interesting. Not that they're wildly broken, but I'd rather have fewer tools and it always seemed a bit odd that they're separate when they're notionally managing the environment in which your ruby code executes. Given the rise in supply chain attacks, I'd also like a private rubygem instance where I can whitelist gems and even versions for my company in a way that doesn't let anything else install. I'm not sure if they're taking that on or not, but I'd like it. the rv thesis is here: https://andre.arko.net/2025/08/25/rv-a-new-kind-of-ruby-management-tool/ https://andre.arko.net/2025/08/25/rv-a-new-kind-of-ruby-mana...
    - riffraff 1y ago
      > I'd also like a private rubygem instance that was always possible https://guides.rubygems.org/run-your-own-gem-server/ https://guides.rubygems.org/run-your-own-gem-server/ (there's also "gem server")
  - baggy_trough 1y ago
    That's basically my point. I'm not missing anything, so I'm happy if it just gets small / stability fixes, which doesn't seem like it needs a six member maintainer group. That team should go off and do a great job with 'rv' or whatever the next brand new idea is, and just let rubygems sit there with minor updates, same as we do for the ruby logger or date class.
    - woodruffw 1y ago
- ilvez 1y ago
  They made bundler output compact, previously it spammed all installed versions and updates mixed, now you can see just updates if you do those for example.. or quite concise "all OK" if everything is as it should be. Small but really nice quality of life change imo
phoronixrly 1y ago
I don't plan on switching to a rubygems fork that does not offer technical/security benefits over the original. They can win me over with a gem distribution site that requires code signing out of the box and a bundler that enforces it out of the box.
- mijoharas 1y ago
  For me, having the software be maintained (and have a security engineer working on it) feels like a security benefit. Does the original have many maintainers left?
  - phoronixrly 1y ago
    It has allegedly been taken over by Shopify. I expect it to be very well maintained. The issues are of ethical character.
    - mperham 1y ago
      Well maintained? Rubygems has had no commits in the last 10 days and that's not a good sign. I don't think you can find a window with no commits for 10 days in its 15+ year history. History has shown over and over that when a for-profit org takes over public infrastructure, maintenance is cut to the bone.
      - gkbrk 1y ago
        > Rubygems has had no commits in the last 10 days and that's not a good sign. I honestly can't tell if this is satire. You think no commits for 10 days for a piece of software that has existed for around 20 years is a sign that it's dead? What kind of code churn do you think this project requires? Perhaps the old development was too unstable if there wasn't a single 10 day window without a commit in 15 years, for what is essentially a solved problem and a tool that people depend on to be stable.
        RhythmFox 1y ago
shadowgovt 1y ago
I think right off the bat since they chose .coop as their TLD, a lot of corporate firewalls auto-block them and they have immediately decided to fight an uphill battle to get allow-listed to be a gem repo. This does not bode well for the team having the socio-technical savviness to see this project through.
- w0m 1y ago
  seems like an easy fix in a month with a new TLD though.
- spit2wind 1y ago
  Really? Maybe I'm naive, but why would .coop be blocked?
  - lbhdc 1y ago
    It is pretty common that "weird" tlds get blocked more or less whole sale in places you might not expect. The reason is spam. Before these can get wide spread "normal" adoption they can be heavily used by spammers. Its hard to say if that is because they have desirable look-a-likes available, or if its because the first year is offered at a deep discount. So, systems will get flooded, and on inspection they will see that they don't have any legit traffic from those tlds and will whole sale block them. .xyz is kind of infamous for being in this situation. https://news.ycombinator.com/item?id=28554400 https://news.ycombinator.com/item?id=28554400 I have no idea if that applies to .coop though.
    - chillfox 1y ago
      Pretty sure it is because they are cheep for the first year. And the blocks are often for domains younger than one year, instead of whole tld.
    - krainboltgreene 1y ago
      coop has around 12 years of age on xyz at least.
    - 1y ago
nomdep 1y ago
>It kind of feels like this fork is the better-maintained piece of software now. Maybe, but I feel the value of the index is the storage and bandwidth and not the software itself, isn't it? Could an index work by just being a search engine for gems, storing the hashes, but pointing to external resources, like GitHub repos, for the download itself?
- soraminazuki 1y ago
  Trustworthiness is far more important for a package manager. No amount of storage or bandwidth can compensate for an untrustworthy package manager.
  - stanislavb 1y ago
    With this is in place. A ".coop" domain does not signal trustworthiness. It's more like a childish revenge attempt. Don't get me wrong. I think it's a great idea for the original maintainers to begin work on a form. However, they could have chosen a better domain name.
    - mijoharas 1y ago
      I saw someone else saying something about the domain name, but I didn't really give it a second thought when I read it. Can you explain what the issue is?
      - seanw444 1y ago
        I'd only say it's a real issue if this were a "normie-facing" website. But being a developer tool, we all know that there are legitimate domains other than .com, .org, and .net.
      - LexiMax 1y ago
        It's one of those "attractive distractions" that us nerds like to bikeshed over. Honestly, after "tweet" caught on as a verb, I've given up on thinking that we have any sort of crystal ball when it comes to names.
x3n0ph3n3 1y ago
I'm starkly opposed to this ridiculous fragmenting of the community. They can and should all go work out contribution agreements with RubyCentral and get over their egos.
- davidcelis 1y ago
  What makes you think they _haven't_ tried to work things out with Ruby Central? As per a separate article[1], this seems to be a last resort: > “Since Ruby Central has informed us they will never allow us to continue working on the projects they now claim they own, that we successfully maintained and operated for the last ten years, the former RubyGems team is launching gem.coop today.” [1]: https://socket.dev/blog/gem-cooperative-emerges-as-a-community-run-alternative-to-rubygems-org https://socket.dev/blog/gem-cooperative-emerges-as-a-communi...
  - x3n0ph3n3 1y ago
    I suspect many of these maintainers are making absurd ultimatums of RubyCentral.
    - mijoharas 1y ago
      That's a strange suspicion. Why?
      - x3n0ph3n3 1y ago
        Because many mass-resigned unless Andre was re-instated.
        mijoharas 1y ago
        I think many mass resigned when their commit access was taken away from their own project by a company that doesn't have a right to do that. Some people might consider that a dick move.
ljm 1y ago
The main page itself provides little to no info so I’m going to make a few assumptions that, to me, seem logical: 1. It must depend on RubyGems in order to stay in sync, because people publish to RubyGems. 2. It has no UI to search or view gems, so still depends on RubyGems for that. Ignoring any question about technical detail or implementation: there is zero practical reason or motivation to switch unless I am ideologically aligned with the maintainers and their reasoning. As such, there is zero reason to even entertain the idea of switching in a professional context. At best I’d have to care enough to remember it for personal projects. So it is with almost any fork. It’ll either converge with the mainline after achieving its goals, take over as the new status quo, or fade into obscurity. If I don’t have any direct stake in that then I’m going to wait it out. This isn’t to discredit or discount the work or the reasoning, of course. It arguably has a far better standing than forking Rails because of DHH.
- daitangio 1y ago
  True, but this is a new beginning.Give time and credit to build an alternative. I think another repo server will not harm anyone in the long run
  - deleted 1y ago
    [deleted]
bradgessler 1y ago
It's bittersweet. 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 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.
dismalaf 1y ago
> So, ignoring everything that got us here, what do people think about this? It's fine. Keeps all the complainers away from the larger ecosystem. I personally trust Ruby Central, 37signals, Shopify, DHH, Tobi, Matz and others over the guy who was launching a startup to compete with rubygems while being a maintainer for rubygems.
baobun 1y ago
> It kind feels like this fork is the better maintained piece of software now. Which fork of what software..? > We’re excited to introduce gem.coop – a new server for gems in the Ruby ecosystem. This is a new hosting service for gems, not a fork of bundler. Or is there missing context?
joeldrapper 1y ago
I believe the CDN is provided for free by Fastly. Not sure about other funding at the moment.

mijoharas 1y ago

re: funding model, looks like it's TBD[0] [0] https://bsky.app/profile/indirect.io/post/3m2j2pcinz22j https://bsky.app/profile/indirect.io/post/3m2j2pcinz22j

baggy_trough 1y ago

I personally cannot think of a new ruby gems or bundler feature from the past decade that I noticed or cared about. That isn't to say that there aren't any; I just don't know what they are.

frenkel 1y ago
Lockfile checksums are quite new and useful.
mijoharas 1y ago
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/ https://www.bleepingcomputer.com/news/security/60-malicious-... [1] https://blog.rubygems.org/2025/08/08/malicious-gems-removal.html https://blog.rubygems.org/2025/08/08/malicious-gems-removal....
- knowitnone3 1y ago
  Socket.dev states "Since at least March 2023". RubyGems says "Our team first detected this activity on July 20th". This attack has ran for almost 5 months undetected. I wouldn't feel reassured at all.
ilikepi 1y ago
There have been several releases with incremental but still notable performance improvements. The overall cadence has been pretty steady, intentionally targeting roughly one minor release per year since 2019-ish, with handfuls of quality of life improvements in each. Arguably RubyGems and Bundler are infrastructure, so the major feature is stability. What sort of big feature are you imagining is missing from your dependency management system?
- x0x0 1y ago
  André is working on a combination of rbenv/asdf, bundler, and gem that I think is interesting. Not that they're wildly broken, but I'd rather have fewer tools and it always seemed a bit odd that they're separate when they're notionally managing the environment in which your ruby code executes. Given the rise in supply chain attacks, I'd also like a private rubygem instance where I can whitelist gems and even versions for my company in a way that doesn't let anything else install. I'm not sure if they're taking that on or not, but I'd like it. the rv thesis is here: https://andre.arko.net/2025/08/25/rv-a-new-kind-of-ruby-management-tool/ https://andre.arko.net/2025/08/25/rv-a-new-kind-of-ruby-mana...
  - riffraff 1y ago
    > I'd also like a private rubygem instance that was always possible https://guides.rubygems.org/run-your-own-gem-server/ https://guides.rubygems.org/run-your-own-gem-server/ (there's also "gem server")
- baggy_trough 1y ago
  That's basically my point. I'm not missing anything, so I'm happy if it just gets small / stability fixes, which doesn't seem like it needs a six member maintainer group. That team should go off and do a great job with 'rv' or whatever the next brand new idea is, and just let rubygems sit there with minor updates, same as we do for the ruby logger or date class.
  - woodruffw 1y ago
ilvez 1y ago
They made bundler output compact, previously it spammed all installed versions and updates mixed, now you can see just updates if you do those for example.. or quite concise "all OK" if everything is as it should be. Small but really nice quality of life change imo

phoronixrly 1y ago

I don't plan on switching to a rubygems fork that does not offer technical/security benefits over the original. They can win me over with a gem distribution site that requires code signing out of the box and a bundler that enforces it out of the box.

mijoharas 1y ago
For me, having the software be maintained (and have a security engineer working on it) feels like a security benefit. Does the original have many maintainers left?
- phoronixrly 1y ago
  It has allegedly been taken over by Shopify. I expect it to be very well maintained. The issues are of ethical character.
  - mperham 1y ago
    Well maintained? Rubygems has had no commits in the last 10 days and that's not a good sign. I don't think you can find a window with no commits for 10 days in its 15+ year history. History has shown over and over that when a for-profit org takes over public infrastructure, maintenance is cut to the bone.
    - gkbrk 1y ago
      > Rubygems has had no commits in the last 10 days and that's not a good sign. I honestly can't tell if this is satire. You think no commits for 10 days for a piece of software that has existed for around 20 years is a sign that it's dead? What kind of code churn do you think this project requires? Perhaps the old development was too unstable if there wasn't a single 10 day window without a commit in 15 years, for what is essentially a solved problem and a tool that people depend on to be stable.
      - RhythmFox 1y ago

shadowgovt 1y ago

I think right off the bat since they chose .coop as their TLD, a lot of corporate firewalls auto-block them and they have immediately decided to fight an uphill battle to get allow-listed to be a gem repo. This does not bode well for the team having the socio-technical savviness to see this project through.

w0m 1y ago
seems like an easy fix in a month with a new TLD though.
spit2wind 1y ago
Really? Maybe I'm naive, but why would .coop be blocked?
- lbhdc 1y ago
  It is pretty common that "weird" tlds get blocked more or less whole sale in places you might not expect. The reason is spam. Before these can get wide spread "normal" adoption they can be heavily used by spammers. Its hard to say if that is because they have desirable look-a-likes available, or if its because the first year is offered at a deep discount. So, systems will get flooded, and on inspection they will see that they don't have any legit traffic from those tlds and will whole sale block them. .xyz is kind of infamous for being in this situation. https://news.ycombinator.com/item?id=28554400 https://news.ycombinator.com/item?id=28554400 I have no idea if that applies to .coop though.
  - chillfox 1y ago
    Pretty sure it is because they are cheep for the first year. And the blocks are often for domains younger than one year, instead of whole tld.
  - krainboltgreene 1y ago
    coop has around 12 years of age on xyz at least.
  - 1y ago

nomdep 1y ago

>It kind of feels like this fork is the better-maintained piece of software now. Maybe, but I feel the value of the index is the storage and bandwidth and not the software itself, isn't it? Could an index work by just being a search engine for gems, storing the hashes, but pointing to external resources, like GitHub repos, for the download itself?

soraminazuki 1y ago
Trustworthiness is far more important for a package manager. No amount of storage or bandwidth can compensate for an untrustworthy package manager.
- stanislavb 1y ago
  With this is in place. A ".coop" domain does not signal trustworthiness. It's more like a childish revenge attempt. Don't get me wrong. I think it's a great idea for the original maintainers to begin work on a form. However, they could have chosen a better domain name.
  - mijoharas 1y ago
    I saw someone else saying something about the domain name, but I didn't really give it a second thought when I read it. Can you explain what the issue is?
    - seanw444 1y ago
      I'd only say it's a real issue if this were a "normie-facing" website. But being a developer tool, we all know that there are legitimate domains other than .com, .org, and .net.
    - LexiMax 1y ago
      It's one of those "attractive distractions" that us nerds like to bikeshed over. Honestly, after "tweet" caught on as a verb, I've given up on thinking that we have any sort of crystal ball when it comes to names.

x3n0ph3n3 1y ago

I'm starkly opposed to this ridiculous fragmenting of the community. They can and should all go work out contribution agreements with RubyCentral and get over their egos.

davidcelis 1y ago
What makes you think they _haven't_ tried to work things out with Ruby Central? As per a separate article[1], this seems to be a last resort: > “Since Ruby Central has informed us they will never allow us to continue working on the projects they now claim they own, that we successfully maintained and operated for the last ten years, the former RubyGems team is launching gem.coop today.” [1]: https://socket.dev/blog/gem-cooperative-emerges-as-a-community-run-alternative-to-rubygems-org https://socket.dev/blog/gem-cooperative-emerges-as-a-communi...
- x3n0ph3n3 1y ago
  I suspect many of these maintainers are making absurd ultimatums of RubyCentral.
  - mijoharas 1y ago
    That's a strange suspicion. Why?
    - x3n0ph3n3 1y ago
      Because many mass-resigned unless Andre was re-instated.
      - mijoharas 1y ago
        I think many mass resigned when their commit access was taken away from their own project by a company that doesn't have a right to do that. Some people might consider that a dick move.

ljm 1y ago

The main page itself provides little to no info so I’m going to make a few assumptions that, to me, seem logical: 1. It must depend on RubyGems in order to stay in sync, because people publish to RubyGems. 2. It has no UI to search or view gems, so still depends on RubyGems for that. Ignoring any question about technical detail or implementation: there is zero practical reason or motivation to switch unless I am ideologically aligned with the maintainers and their reasoning. As such, there is zero reason to even entertain the idea of switching in a professional context. At best I’d have to care enough to remember it for personal projects. So it is with almost any fork. It’ll either converge with the mainline after achieving its goals, take over as the new status quo, or fade into obscurity. If I don’t have any direct stake in that then I’m going to wait it out. This isn’t to discredit or discount the work or the reasoning, of course. It arguably has a far better standing than forking Rails because of DHH.

daitangio 1y ago
True, but this is a new beginning.Give time and credit to build an alternative. I think another repo server will not harm anyone in the long run
- deleted 1y ago
  [deleted]

bradgessler 1y ago

It's bittersweet. 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 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.

dismalaf 1y ago

> So, ignoring everything that got us here, what do people think about this? It's fine. Keeps all the complainers away from the larger ecosystem. I personally trust Ruby Central, 37signals, Shopify, DHH, Tobi, Matz and others over the guy who was launching a startup to compete with rubygems while being a maintainer for rubygems.

baobun 1y ago

> It kind feels like this fork is the better maintained piece of software now. Which fork of what software..? > We’re excited to introduce gem.coop – a new server for gems in the Ruby ecosystem. This is a new hosting service for gems, not a fork of bundler. Or is there missing context?

joeldrapper 1y ago

I believe the CDN is provided for free by Fastly. Not sure about other funding at the moment.