#rubycentral — Public Fediverse posts

🍒🚀 Ruby Central's latest saga is just a *gem* of boardroom #drama and verbose non-statements 🤐. If you love #legalese and cryptic messages more than actual coding, this one's for you! 🧐🤷‍♂️ #NothingToSeeHere
https://rubycentral.org/news/a-message-from-the-ruby-central-board/ #RubyCentral #BoardroomSaga #TechNews #CodingCommunity #HackerNews #ngated

🍒🚀 Ruby Central's latest saga is just a *gem* of boardroom #drama and verbose non-statements 🤐. If you love #legalese and cryptic messages more than actual coding, this one's for you! 🧐🤷‍♂️ #NothingToSeeHere
https://rubycentral.org/news/a-message-from-the-ruby-central-board/ #RubyCentral #BoardroomSaga #TechNews #CodingCommunity #HackerNews #ngated

🍒🚀 Ruby Central's latest saga is just a *gem* of boardroom #drama and verbose non-statements 🤐. If you love #legalese and cryptic messages more than actual coding, this one's for you! 🧐🤷‍♂️ #NothingToSeeHere
https://rubycentral.org/news/a-message-from-the-ruby-central-board/ #RubyCentral #BoardroomSaga #TechNews #CodingCommunity #HackerNews #ngated

🍒🚀 Ruby Central's latest saga is just a *gem* of boardroom #drama and verbose non-statements 🤐. If you love #legalese and cryptic messages more than actual coding, this one's for you! 🧐🤷‍♂️ #NothingToSeeHere
https://rubycentral.org/news/a-message-from-the-ruby-central-board/ #RubyCentral #BoardroomSaga #TechNews #CodingCommunity #HackerNews #ngated

🍒🚀 Ruby Central's latest saga is just a *gem* of boardroom #drama and verbose non-statements 🤐. If you love #legalese and cryptic messages more than actual coding, this one's for you! 🧐🤷‍♂️ #NothingToSeeHere
https://rubycentral.org/news/a-message-from-the-ruby-central-board/ #RubyCentral #BoardroomSaga #TechNews #CodingCommunity #HackerNews #ngated

A Message from the Ruby Central Board

https://rubycentral.org/news/a-message-from-the-ruby-central-board/

#HackerNews #RubyCentral #RubyProgramming #OpenSource #TechNews #CommunityUpdates

A Message from the Ruby Central Board

https://rubycentral.org/news/a-message-from-the-ruby-central-board/

#HackerNews #RubyCentral #RubyProgramming #OpenSource #TechNews #CommunityUpdates

A Message from the Ruby Central Board

https://rubycentral.org/news/a-message-from-the-ruby-central-board/

#HackerNews #RubyCentral #RubyProgramming #OpenSource #TechNews #CommunityUpdates

A Message from the Ruby Central Board

https://rubycentral.org/news/a-message-from-the-ruby-central-board/

#HackerNews #RubyCentral #RubyProgramming #OpenSource #TechNews #CommunityUpdates

A Message from the Ruby Central Board

https://rubycentral.org/news/a-message-from-the-ruby-central-board/

#HackerNews #RubyCentral #RubyProgramming #OpenSource #TechNews #CommunityUpdates

My thoughts on the RubyGems hostile takeover of September 2025, and what I'm doing about it. #Ruby #RubyGems #RubyCentral #Governance :ruby: :jruby: :truffleruby:
https://dev.to/galtzo/hostile-takeover-of-rubygems-my-thoughts-5hlo

:ruby: #RubyCentral hates this one fact #ruby https://www.reddit.com/r/ruby/comments/1ove9vp/rubycentral_hates_this_one_fact/

"I am concerned that Ruby Central’s board with full knowledge of the consequences and the alternatives voted to take over a collection of open source projects from their maintainers without consent. Especially when these maintainers were acting in good faith at the time. This is the organisation we are meant to trust to host our Ruby gems."

#JoelDrapper, September, 2025

https://joel.drapper.me/p/rubygems-takeover/

If what Joel describes here is true, this is deeply fucked.

#Ruby #RubyCentral #RubyGems #Shopify

"Deprecate bundler is in the pipeline"

Interesting. It seemed they they took offense at Arko working on a bundler alternative, but apparently they were already planning to deprecate bundler? So why is there any concern about people working on alternatives?

#ruby :ruby: #rubycentral

NOTE: This was a very hard watch, and I was mentally exhausted by the end of it.

https://youtu.be/nKpo68g9dEk?si=E9XWI16CI7yeKAgB

With a not-too heavy heart I now cancelled my (financial) support of #RubyCentral.
I'm sure this won't hurt their finances significantly. I firmly believe Shopify's contributions are/were MUCH bigger than mine.

Note that I still very much love #Ruby, the language! 💖 — Rubycentral not so much, though.

#Ruby

Considering everything with #rubycentral, interesting timing

https://react.dev/blog/2025/10/07/introducing-the-react-foundation

#javascript

Like... did the probable person responsible take over the account to use as leverage (the subtext #RubyCentral is implying), or did they act prudently to maintain control of an account they otherwise were stewards of?

If I presume the probable person is as reasonable as they appear to be, then malice seems totally out of character. So why paint them as a villain? Why mention Joel's blog post at all if not to sling shit at Joel?

We're better than this sort of thing, come on.

🎭 Oh, look! It's Ruby Central's riveting recount of a 2025 slip-up where someone forgot to revoke #AWS access, giving a former maintainer the keys to the kingdom. 🎉 But fear not, they've published a post-incident #review that's about as exciting as watching paint dry, with a thrilling promise to maybe, just maybe, not let it happen again. 🔒🔑
https://rubycentral.org/news/rubygems-org-aws-root-access-event-september-2025/ #RubyCentral #Incident #SecuritySlipUp #TechNews #HackerNews #ngated

Between #rubycentral, #rubyonrails dramas and #cocapods closing it's must be quite the time to be a #ruby dev

The prospect of fashy RubyGems.org/Ruby Central getting displaced by a literal coop with a .coop domain name ( https://gem.coop ) is beyond entertaining for me. I am so excited. LFG

#ruby #RubyGems #RubyCentral #GemCoop

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.

#Ruby #RubyGems #bundler #RubyCentral #RubyOnRails

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.

#Ruby #RubyGems #bundler #RubyCentral #RubyOnRails

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.

#Ruby #RubyGems #bundler #RubyCentral #RubyOnRails

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.

#Ruby #RubyGems #bundler #RubyCentral #RubyOnRails

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.

#Ruby #RubyGems #bundler #RubyCentral #RubyOnRails

@ShadSterling @quintasan Find the new invite link in this PR!!
https://github.com/rubygems/bundler-site/pull/1568/files
:ruby: 💎 We're discussing ideas on the future of the RubyGems.org alternative. #Ruby #RubyCentral

The bullshit-o-meter is going off the charts!

It certainly looks like #RubyCentral is absolutely in full damage control mode now, since this post:

- Reads like corporate bullshit;
- Tries hard as fuck to avoid the elephant in the room that is the loss of trust they caused;
- Tries to gaslight us by stating "this is not a takeover" as fact, while everyone can see it is a takeover.

https://rubycentral.org/news/our-stewardship-where-we-are-whats-changing-and-how-well-engage/

#ruby #rubygems #foss

@rubycentral
Continuing with #SFRuby meeting for September 2025.

... and here we are with André Arko (Spinel Coop) @indirect who will be taking about rv, a New Kind of Ruby Management Tool

- rv is made with #rust
- is based on portable-ruby, from Homebrew

Note: André was book for this meeting way before the #rubycentral fiasco in the #ruby community

#SFRuby #sfba

Continuing with #SFRuby meeting for September 2025

A note from Irina about the elephant in the room

> We're amist a major conflict... @rubycentral

#SFRuby #ruby #sfba #rubycentral

Our Stewardship: Where We Are, What's Changing and How We'll Engage

https://rubycentral.org/news/our-stewardship-where-we-are-whats-changing-and-how-well-engage/

#HackerNews #OurStewardship #CommunityEngagement #Change #Leadership #RubyCentral

I don't know how this is going to play out.

It seems like maybe control of the #ruby ecosystem rests predominantly in the hands of Shopify though the proxy of Ruby Central.

Is this the case? I can't tell. Would that be bad? Probably in the long run. Is it bad optics that this is even a question? Yes.

I understand the motivation to protect the supply chain, but events of the last few weeks do not instill confidence.

#programming #rubygems #bundler #rubycentral

I subscribed to #404media (the free plan, but now I'm on the list) just so I could read their article about the #Ruby #Bundler #RubyCentral drama at https://www.404media.co/how-ruby-went-off-the-rails/

This bit made me raise an eyebrow:
----
“Thanks for the invitation, but not my place to weigh in a lot on this while they're working through these changes,” DHH told me in an email when reached for comment.
----
It's not like DHH is known for his patient reserve. He weighs in, a lot. It's kind of his thing.

#programming

I need some help. It’s about… well, a lot, but it’s also about the Ruby community.

A few days ago Drew DeVault created an issue on Omarchy requesting adding a Code of Conduct. Unsurprisingly, it was heavily downvoted and closed as not planned. Of course, Dave twitted (twat? It seems like it should be an irregular verb) about it: https://xcancel.com/dhh/status/1971454220726566998

His point is that principle-based short community guidelines are better than detailed CoC like the Contributor Covenant. He specifically highlights “the beautiful replacement that Matz put in place for Ruby when they came for him with this bullshit”: https://rubyonrails.org/conduct

BTW, while the guidelines are on the Ruby website (https://www.ruby-lang.org/en/conduct/) I don't see them linked anywhere. I could only get to the page through search.

Anyway… Shortly after Eric S. Raymond expressed an opinion that ‘”Codes of Conduct” have been a disaster’ and called for removing them: https://xcancel.com/esrtweet/status/1971768345188844003 And if legally required replacing them with basically a single sentence: “If you are more annoying to work with than your contributions justify, you’ll be ejected.”

Now, here’s where I need some help. My Japanese is really bad. I might’ve misunderstood something. I’d love some input from people who speak Japanese.

So right after that Shuji Sado wrote a post about how CoCs are bad actually. His twitter bio states these credentials: Open Source guy, Chairman of Open Source Group Japan (http://opensource.jp), former CEO of OSDN KK (to 2020), ex-VA Linux, Open Source and Galapagos People, Internet Youth Group (partially translated from Japanese). Seems like he’s not a total rando.

In his post (https://shujisado.com/2025/09/30/why_codes_of_conduct_are_unnecessary/) he tries to convince the reader that CoCs are unnecessary. But he goes about it in a rather peculiar way. First he gives a historic background to CoCs raise in popularity. Particularly citing Debian/Ubuntu and Python where it fixed some real issues and rather effectively. But then he cites two cases where—in his opinion—CoCs were detrimental.

First is when the whole Rust moderation team resigned because it couldn’t enforce CoC agains members of the Core team. The reason was how the governance was structured. Very simplified, the moderation team was subordinate to the Core team. The lack of independence highlighted conflict of interest and unbalanced power dynamic.

The second is Ruby Central takeover of rubygems/bundler. This is where I have the most trouble. He seem to agree that the pretext was security concerns but he lumps it in with CoCs arguing that strict, powerful CoCs require complex enforcement bodies and those create same kind of power centres as governance. And that they’re susceptible to political manipulation and hijacking.

Now, I’m sure Eric Raymond hasn’t had much trouble being a white moustached ESR dude. And Dave is Dave. I’m not sure what Sado’s deal is. He shows how CoC were good actually and his counterexamples are extremely tangential to CoCs themselves but rather highlight governance issues. He talks about effectiveness of Ruby's CoC that lies in its simplicity. But I have to call that into question. Is it really that effective? How come we still have Dave around? Let's look at Ruby's community guidelines.

> * Participants will be tolerant of opposing views.

I mean… That's a nice sounding general principle and is probably a good approach when it comes to some inconsequential personal preference (e.g. coffee vs tea, tabs vs spaces) but when the “opposing view” is that a whole group of people should not exist? Are we supposed to tolerate every possible “opposing view”?

> * Participants must ensure that their language and actions are free of personal attacks and disparaging personal remarks.

What is “personal”? Is it specifically by name or direct address? Does naming a large group by an unambiguous defining attribute count?

> * When interpreting the words and actions of others, participants should always assume good intentions.

Good for whom? Noone sees themselves as a villain.

> * Behaviour which can be reasonably considered harassment will not be tolerated.

By whom? In both cases. I see quite a few people consider some community memeber’s actions as harassment. Reasonably, in my view. But also will not be tolerated by whom? Who’s gonna make the final decision and enforce it?

Sado argues that Ruby CoC relies heavily on community consensus for determining violations, depending on existing project leadership without bureaucratic processes. I see a few glaring shortcoming here. First, what to do when there’s no consensus. Say, in Dave's case there’s a bad split. There are quite a lot of people utterly dissatisfied with his conduct, as there are a lot of supporters of him personally and his ideas (the ones that irk the first group), and also there are a lot of people who’s trying to stay out of it and a large portion of this group do so because they can not afford to lose a job right now. So no formal consensus, not even a simple majority opinion. But also there’s no enforcement to any of this. See, Dave is the leadership in his community. Is there a reasonable expectation that he’s gonna act against himself? I think not.

But those are also Ruby guidelines. Can we appeal to, say, Matz on the matter?

Well, this is why this wall of text is here. Matz retwitted Dave (see image). I take it, Matz’s in agreement with Dave. But I’m not sure on what point. Is it just about the beauty of Ruby’s community guidelines? Or is it on the whole package? Some subset of all of the above?

@matz could you please more explicitly weigh in on Ruby community guidelines? How is it enforced? What is your stance on Dave specifically? Do you think any of the concerns voiced by quite a few community members need to be addressed in any way?

And while you’re at it, your thoughts on the Ruby Central situation would be interesting to hear, too.

Update: Sado published an english version of his post: https://shujisado.org/2025/09/30/why-heavy-codes-of-conduct-are-unnecessary-for-most-open-source-projects/

In the Ruby Central section he says: the ongoing RubyGems incident–the very trigger for this debate–may illustrate how the discourse of governance, including CoC, can be abused as a “tool for seizing power.”

So basically, you can't have a strong CoC because it can be weaponised against the community. TBH, I don't buy it. For one, neither Rails’, nor Ruby’s simple principle-based CoCs, not even Ruby Central’s more detailed CoC had absolutely any effect on certain Dave's standing. You can't have it both ways. Yes, there's no perfect solution, but Rails/Ruby clearly shows that simpler CoC is not inherently superior to Contributor Covenant. I mean, no matter what CoC you have you have to enforce it. And good if you exercise some judgment while you do.

#Ruby #RubyCentral #CodeOfConduct #CoC

If you are confused because I am boosting conflicting viewpoints on the #rubycentral kerfuffle it is because the thing is confusing, and until I have a clear take I want everyone to have as much info as possible, so that we can all have an informed position

What's happening in the Japanese Ruby community?

Do they have a RubyGems.org/Ruby Central alternative? Is there some kind of discussion going on there about the whole Shopify/sponsor influence?

#ruby #rubygems #rubycentral

A great summary of the current #Ruby situation.

https://joel.drapper.me/p/rubygems-takeover/

#rubygems #rails #rubycentral #dhh

#Opensource to closed doors: #RubyGems control fight erupts
#RubyCentral is accused of ousting #maintainers from core gems under pressure from #Shopify.
Allegations were detailed by #JoelDrapper, Ruby dev/opensource maintainer who previously worked at Shopify. Drapper's exposé asserts Shopify, a major corporate user and #Ruby sponsor, applied financial and governance pressure to force Ruby Central's hand – effectively turning #nonprofit into proxy for #corporate interests
https://www.theregister.com/2025/09/25/open_source_to_closed_doors/

Bundler belongs to the Ruby community: Response to the hostile takeover of core Ruby infrastructure
https://andre.arko.net/2025/09/25/bundler-belongs-to-the-ruby-community/
#rubycentral #bundler #andre #ruby #+

Oh no, another developer storming off in a huff 🤦‍♂️ because Ruby Central didn't bow to their every whim. 🚪💨 It's like watching someone rage-quit a chess game because the pieces won't move themselves. 🎭🕺
https://gist.github.com/simi/349d881d16d3d86947945615a47c60ca #developerdrama #RubyCentral #ragequit #chessmetaphor #techhumor #HackerNews #ngated

Shopify, pulling strings at Ruby Central, forces Bundler and RubyGems takeover

https://joel.drapper.me/p/rubygems-takeover/

#HackerNews #Shopify #RubyCentral #Bundler #RubyGems #TechNews

Get awesome #Railsconf with shirts, mugs, and stickers! 👕🔖 Visit our @rubycentralorg #swag store and grab some new (or old!) gear. Don't miss out on showcasing your love for #RailsConf! https://store.rubyconf.com

#RubyCentral #DevSwag #TechGear #railsconf2023

Get awesome #Railsconf with shirts, mugs, and stickers! 👕🔖 Visit our @rubycentralorg #swag store and grab some new (or old!) gear. Don't miss out on showcasing your love for #RailsConf! https://store.rubyconf.com

#RubyCentral #DevSwag #TechGear #railsconf2023

Get awesome #Railsconf with shirts, mugs, and stickers! 👕🔖 Visit our @rubycentralorg #swag store and grab some new (or old!) gear. Don't miss out on showcasing your love for #RailsConf! https://store.rubyconf.com

#RubyCentral #DevSwag #TechGear #railsconf2023

Get awesome #Railsconf with shirts, mugs, and stickers! 👕🔖 Visit our @rubycentralorg #swag store and grab some new (or old!) gear. Don't miss out on showcasing your love for #RailsConf! https://store.rubyconf.com

#RubyCentral #DevSwag #TechGear #railsconf2023

Get awesome #Railsconf with shirts, mugs, and stickers! 👕🔖 Visit our @rubycentralorg #swag store and grab some new (or old!) gear. Don't miss out on showcasing your love for #RailsConf! https://store.rubyconf.com

#RubyCentral #DevSwag #TechGear #railsconf2023

It's the last day of #RailsConf2023! 🎉 Time flew by! Join the Closing Snack Social at 4PM for community & fun! Closing Keynote will reveal 2024 location, stay tuned... 🕵️ 🤐 👀

#RailsConf #RubyOnRails #RubyCentral

Ruby Central is growing and moving towards exciting new goals! 🚀 Let's take a look at the role of the board, its evolution, and future plans. Check it out: https://rubycentral.org/news/ruby-central-board/

#RubyCentral #Growth #TechGoals #FuturePlans #ruby #rubyonrails #rails https://rubycentral.org/news/ruby-central-board/