Equipe central do Ruby assume a propriedade do RubyGems e do Bundler

• A propriedade dos repositórios do gerenciador de pacotes RubyGems e do Bundler da linguagem Ruby foi transferida do Ruby Central para a equipe central do Ruby
• A medida foi conduzida por Matz (Yukihiro Matsumoto) para garantir estabilidade de longo prazo e continuidade da comunidade
• RubyGems e Bundler continuarão sob as mesmas licenças open source, e os direitos autorais e o histórico de contribuições dos contribuidores atuais também serão preservados
• A operação passa a um modelo de gestão conjunta entre o Ruby Central e a equipe central do Ruby, mantendo o modelo de desenvolvimento liderado pela comunidade
• Trata-se de uma mudança estrutural para reforçar o desenvolvimento sustentável e a integração do ecossistema Ruby, com importância relevante para a estabilidade de longo prazo

---

Importância do RubyGems e do Bundler

• O RubyGems é a principal ferramenta de gerenciamento de pacotes do ecossistema Ruby, e o Bundler é um componente essencial responsável por gerenciamento de dependências e distribuição
• Ambos os projetos são ferramentas padrão incluídas na distribuição do Ruby e estão profundamente integrados à linguagem Ruby
• No entanto, até agora RubyGems e Bundler eram geridos de forma independente pelo Ruby Central, e não pela organização do Ruby,
  o que gerava falta de consistência estrutural por serem componentes padrão da linguagem Ruby operados em uma organização separada no GitHub
• Diante disso, a equipe central do Ruby decidiu assumir oficialmente a gestão e a manutenção dos repositórios
• O objetivo é garantir a estabilidade de longo prazo do projeto e o alinhamento com o ecossistema Ruby

Principais mudanças

• A propriedade oficial dos repositórios foi transferida para a equipe central do Ruby, passando a um sistema de gestão conjunta com o Ruby Central
• Não há mudanças nas condições das licenças open source existentes, nem na estrutura comercial ou jurídica
• Os direitos de propriedade intelectual e os direitos autorais de todos os contribuidores atuais serão mantidos, sem alteração na propriedade do código
• O modelo de desenvolvimento guiado pela comunidade continuará, com contribuições abertas a qualquer pessoa

Cooperação com a comunidade e próximos planos

• A equipe central do Ruby pretende manter um sistema contínuo de colaboração com o Ruby Central e desenvolvedores do mundo todo
• A medida é vista como a construção de uma base de longo prazo para melhorar a estabilidade e a confiabilidade do ecossistema Ruby
• Em sua declaração, Matz agradeceu a dedicação do Ruby Central e afirmou: “Vamos construir juntos um futuro mais brilhante para o Ruby”

Implicações

• A transferência é um evento simbólico que reorganiza a infraestrutura central da linguagem Ruby para dentro da organização oficial
• Pode ser vista como um ponto de virada para aumentar a sustentabilidade futura do Ruby por meio da integração da manutenção no nível da linguagem e da unificação do ecossistema

[GN⁺]

Comentários no Hacker News

• Acho que esta decisão foi na direção certa; sou grato por Ruby Core e Matz terem se apresentado para dar estabilidade à linguagem e à comunidade como um todo
  • Isso reforça que Matz é o verdadeiro eixo central; acho que aquela frase antiga, “Matz is nice and so we are nice”, deveria ser trocada por “gentil e responsável”
• No longo prazo, parece que ter várias fontes, como a gem.coop, seria uma estrutura mais segura e robusta; mas no RubyGems a confiança foi completamente abalada em vários níveis (mantenedores, membros da comunidade, patrocinadores etc.), e questões como financiamento e privacidade de dados ainda precisam ser resolvidas; ainda assim, parece que a maior parte da comunidade Ruby vai apoiar essa mudança
  • Alguém pode resumir o que realmente aconteceu? Não venho acompanhando as notícias de Ruby ultimamente e fiquei curioso
  • Concordo; agora acho que precisamos observar um pouco mais o quanto a gem.coop consegue ganhar força. Eles fizeram promessas para o futuro e imagino que no fim devam entregar resultados. Quando o beta abrir, tenho disposição para reenviar pelo menos alguns dos gems que publiquei antes, especialmente os principais. Há pontos que precisam melhorar, com destaque para a documentação (o que também se relaciona com a documentação do Ruby; o fato de estar separada é um problema). A falta de namespacing também é um problema (em Ruby não existe namespacing oficial, o que é ao mesmo tempo característica e problema; acho que precisamos de um jeito de separar por área de interesse). Acho mais realista reavaliar isso daqui a uns seis meses, no fim de maio de 2026. Se o DHH continuar fazendo comentários ácidos no blog, pessoas que já estavam insatisfeitas com o gem.coop podem acabar entrando de novo e aumentando o número de contribuidores, o que pode trazer benefícios. Do ponto de vista do usuário, seria uma situação de ganho mútuo, com mais liberdade e flexibilidade. Muita gente vai continuar no rubygems.org, mas também deve crescer o número de quem prefere a gem.coop. Também haverá quem use os dois (o que complica um pouco, então talvez a gem.coop precise pensar em permitir configuração de fonte por gem). Ainda há muito trabalho a fazer
  • É inacreditável que um mantenedor sem atividade ainda tivesse acesso root; surpreende que ainda mantivesse qualquer nível de privilégio numa plataforma central. Fiquei chocado ao ver membros recentes da comunidade Ruby se opondo a padrões modernos de segurança (e já amplamente adotados), apesar de isso ser uma plataforma importante da web. Não estamos mais em 2006, na época de instalar só Rails com um comando curl; essa ingenuidade nessa reação me assusta. Também foi chocante ver como uma postura de segurança sem manutenção deixou tudo exposto a ataques à cadeia de suprimentos. Ainda bem que agora alguém finalmente está se preocupando com segurança compatível com os tempos atuais
  • Sobre a ideia de que várias fontes seriam mais seguras: acho que isso pode triplicar a superfície de ataque e aumentar as vulnerabilidades
  • Isso é só uma mudança no tooling de Ruby; o próprio rubygems.org continua, dependendo de como você vê a situação, pertencendo a uma entidade hostil, então duvido de quanto isso realmente ajuda a restaurar a confiança
• A posição da Ruby Central pode ser vista aqui https://rubycentral.org/news/ruby-central-statement-on-rubygems-bundler/
  • Vale a pena ver também o comunicado anterior, de 19 de setembro, que fala em “refletir um compromisso conjunto com a estabilidade e o crescimento de longo prazo do ecossistema Ruby” https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-bundler/
• Sou profundamente grato por Matz ter exercido liderança diretamente numa situação difícil; como desenvolvedor japonês, eu estava muito preocupado com o rumo recente das coisas, e este anúncio me deixou mais tranquilo
  • Fico curioso sobre como exatamente ele exerceu essa liderança. Sempre esteve claro que não era só o Hiroshi Shibata agindo por conta própria. Suspeito que a decisão de assumir gem e bundler já tenha sido tomada internamente há alguns meses. Quanto à opinião de que isso traz tranquilidade para desenvolvedores japoneses, para mim acontece o contrário: fico ainda mais preocupado. Como moro fora dos EUA e do Japão, me incomoda e frustra a sensação de que esses dois países dominam demais o ecossistema Ruby (do lado japonês até entendo, por ser a comunidade local), mas a influência dos EUA também me parece excessiva. Sinto o mesmo em relação ao Python, e isso me desagrada
• Acho que qualquer pessoa que já tenha mexido minimamente com Ruby vai considerar este desfecho algo de que ninguém pode reclamar
  • Acho que quem saiu ganhando foi só a Ruby Central. Ela não cedeu em nada e ainda recebeu o apoio oficial da Ruby Core para ser reconhecida como mantenedora do Rubygems. A propriedade do repositório foi transferida, mas a Ruby Central continua responsável pela operação e governança, em estreita colaboração com a Ruby Core. O Andre tem os direitos sobre a marca Bundler e já disse que pretende usá-los contra a Ruby Central https://andre.arko.net/2025/09/25/bundler-belongs-to-the-ruby-community/, a Ruby Central transfere a propriedade do Bundler para a Ruby Core e continua cuidando da manutenção, enquanto a Ruby Core fica exposta ao risco jurídico. Se o Andre processar, vai enfrentar a Ruby Core do Japão, e a imagem vai piorar ainda mais
  • As pessoas só não reclamam porque o Matz ainda não se manifestou sobre questões sociais como lei de imigração
  • Quero questionar se realmente ninguém tem reclamações
  • Fico me perguntando por que supostamente ninguém tem reclamações; ainda acho que restam muitas perguntas. O ponto-chave daqui para frente talvez seja o quanto a gem.coop vai ganhar popularidade (se vai realmente crescer). Talvez tivesse sido melhor criar uma nova forma de instalar projetos Ruby (como no caso de Rust + cargo), mas sou da opinião de que é melhor separar o provedor de serviço das discussões reais de desenvolvimento. O fato de existirem tanto o binário gem quanto o bundle não me parece ideal. Acho que a API deveria ser unificada (ou então a Ruby Core poderia manter uma API simples, e recursos extras ficariam livres para cada um desenvolver). No fim, existe o risco de muitos projetos virarem algo como a tirinha do xkcd. Eu gostava da simplicidade do bin/gem, e o Bundler acrescentava algumas conveniências. Seria bom se o comando gem facilitasse especificar várias fontes, incluindo a gem.coop
• Concordo que a Ruby Core é uma escolha melhor do que a Ruby Central, mas ainda quero entender exatamente o que foi esse episódio, e a imagem de todo o ecossistema Ruby ficou um pouco nebulosa
  • Normalmente desenvolvo mais em Go e outras linguagens, e sinto que a natureza distribuída do ecossistema de pacotes de Go é uma grande vantagem (embora também tenha desvantagens). Mesmo com a crise recorrente de cadeia de suprimentos em ecossistemas públicos de pacotes como o NPM, acho curioso que não existam mais tentativas de descentralização ou experimentos liderados pela comunidade
• Eu estava esperando por isso, porque me parecia a opção mais simples e capaz de restaurar a confiança; ainda acredito que líderes de boa-fé salvam comunidades
• Acompanhei esse drama recente como quem vê uma série; lamento por quem foi prejudicado dentro da comunidade Ruby. No fim das contas, acho que o Matz é sensacional
  • Fico me perguntando se tudo isso começou por antipatia ao DHH. Talvez não desse para aplicar, em um fork independente, as melhorias necessárias de segurança e governança no rubygems.org? Em casos assim, do ponto de vista de open source, não seria o fork a forma padrão de resolver conflitos?
• A atitude do Matz e a forma como ele fez o anúncio foram realmente impressionantes e inspiraram respeito; isso me lembrou o que é grandeza
  • Não gosto do fato de só a Ruby Central, que foi o lado agressivo, ter sido contemplada, sem nem haver agradecimento aos antigos mantenedores que contribuíram por anos
  • O fato de não mencionar como o projeto foi parar do lado da RC (Ruby Central) faz parecer que todo o processo foi embelezado
• Alguém de fora consegue explicar rapidamente o que aconteceu desta vez?
  • Vale consultar esta thread https://news.ycombinator.com/item?id=45299170#45300774, especialmente o resumo do Mike McQuaid, que ajuda bastante. Ele teve um papel importante de mediação e comunicação, e também vale ver as postagens sociais mais recentes dele https://bsky.app/profile/mikemcquaid.com
  • Os donos mudaram algumas vezes, e os detalhes desse processo nunca foram transparentes. Isso aumentou a tensão dentro da comunidade, e uma das figuras mais barulhentas e representativas tem um estilo de emitir opiniões fortes, impopulares, o que ampliou ainda mais o conflito
  • Tenho a impressão de que ninguém consegue explicar isso com clareza; é uma situação confusa e sem resposta clara