Gem.coop

• gem.coop é um novo servidor de gems para o ecossistema Ruby
• Foi criado pela antiga equipe de operação do RubyGems.org para a comunidade
• Oferece todos os gems públicos do RubyGems.org com sincronização em tempo real
• Valoriza transparência e participação da comunidade com uma governança inspirada no Homebrew
• Tem como objetivo uma hospedagem de gems sustentável e com segurança reforçada

---

Apresentando o gem.coop

• gem.coop é um novo servidor de gems projetado para o ecossistema Ruby, criado com o objetivo de oferecer um ambiente de hospedagem mais rápido e simples
• Mantendo compatibilidade total com o Bundler, destaca desempenho e estabilidade otimizados para ambientes de desenvolvimento de próxima geração
• O projeto conta com participação direta de ex-administradores e da equipe de operação do RubyGems.org, sendo desenvolvido como um serviço para a comunidade
• Todos os gems públicos são sincronizados em tempo real a partir do RubyGems.org e podem ser usados imediatamente também no gem.coop
• Basta alterar o endereço da source no Gemfile atual para começar a usar, o que torna a adoção muito simples

Governança e participação da comunidade

• Adota uma estrutura transparente e fácil de participar, tomando como referência o modelo de governança do projeto Homebrew
• Com a colaboração de Mike McQuaid, a configuração da organização e o modelo de operação estão sendo preparados, e a forma oficial de governança deve ser divulgada antes de 10 de outubro
• O plano é operar com uma estrutura aberta para que qualquer pessoa da comunidade Ruby possa contribuir e participar

Objetivos do serviço e próximos planos

• O objetivo final do gem.coop é oferecer uma plataforma de hospedagem de gems de propriedade da comunidade, rápida, transparente, sustentável e com segurança reforçada
• No início, dará suporte ao bundling e à instalação de todos os gems públicos, com melhorias contínuas de funcionalidades e qualidade no futuro
• É possível receber atualizações mensais por meio da newsletter do gem.coop

Equipe

• O desenvolvimento e a operação ficam a cargo da Gem Cooperative, liderada por deivid-rodriguez, duckinator, indirect, martinemde, segiddins e simi

[GN⁺]

Comentários no Hacker News

• Deixando toda a controvérsia de lado, confirmei que, no momento, todos os mantenedores originais do RubyGems saíram, e a maior parte dos antigos contribuidores principais está participando do novo projeto. Antes, só o deivid parecia ter presença marcante, mas agora parece que a maioria das pessoas importantes veio para este lado. Isso me dá a impressão de que este fork agora é um software mais bem mantido. Fico curioso se há alguma informação sobre a possibilidade de as pessoas migrarem em breve para cá, e sobre o modelo de financiamento ou o peso dos custos de hospedagem. Há mais informações aqui

  • Neste momento, este fork pode até parecer um software mais bem mantido, mas penso que o realmente importante não é tanto o software em si, e sim o armazenamento e a largura de banda do serviço de indexação. Talvez funcionasse bem simplesmente fazer o mecanismo de busca de gems armazenar os hashes e deixar os downloads apontarem para um repositório externo, por exemplo no GitHub

  • Essa situação é um pouco amarga. Se esse fork der certo, vamos acabar numa estrutura como a do mundo JS, em que se fica pensando “qual gerenciador de pacotes devo usar?”. Vai desaparecer aquela bela simplicidade de “é só usar bundler e rubygems”. Ainda assim, quero elogiar muito o fato de a antiga equipe de mantenedores do RubyGems, que foi prejudicada, ter levantado publicamente o problema e depois começado silenciosamente o trabalho no fork. Um fork do RubyGems parecia algo impossível, mas agora eles estão criando ao menos uma pequena possibilidade. As grandes empresas provavelmente continuarão no RC, que tem o respaldo da Shopify, e nessas organizações as auditorias de segurança talvez até se intensifiquem, mas imagino que faltará inovação. Já se o gems.coop tiver sucesso, será porque se consolidará simplesmente como “a ferramenta melhor”. Por exemplo, o rv.dev, feito pelo André, deve levar vantagem em experiência do desenvolvedor (DX) por ser uma ferramenta “rápida e tudo em um” que cobre gerenciamento de versões do Ruby, dependências de gems e até funções parecidas com npx. Também estão discutindo namespaces, checksums e uma abordagem de segurança tecnicamente mais agressiva; se o RC continuar como está, no fim talvez o lado tecnicamente superior acabe vencendo. Em termos de financiamento, parece que o André defende que “organizações capazes de arcar com os custos de infraestrutura OSS realmente precisam pagar”, e eu concordo. Assim, daria para prever com exatidão os custos e dividi-los de forma transparente entre as empresas pagantes. Por fim, acho que a causa fundamental de o RC ter se degradado assim foi a concentração excessiva de recursos em poucos patrocinadores, então espero que a Ruby Co-op consiga construir um modelo de financiamento distribuído, com 100, 1000 ou mais participantes

  • Vale notar que o modelo de financiamento ainda não foi definido. Link relacionado

  • Há informação demais faltando na página oficial. Então, fazendo algumas suposições lógicas: 1) a distribuição inevitavelmente depende do RubyGems. 2) não há UI para busca e visualização de gems, então também depende do RubyGems. Deixando os detalhes técnicos de lado, não existe absolutamente nenhum gatilho prático para eu migrar, a menos que eu concorde ideologicamente com os mantenedores do fork. Para fins profissionais, não há motivo para mudar; se eu tiver interesse pessoal, no máximo vou guardar isso na memória. Como a maioria dos forks, ou eles atingem o objetivo e se fundem de novo, ou viram um novo padrão, ou são esquecidos. Se isso não me afetar diretamente, eu só vou observar. Não estou menosprezando as críticas nem o trabalho deles; é uma situação muito mais convincente do que, por exemplo, fazer um fork do Rails por causa do DHH

  • Nos últimos 10 anos, não consigo lembrar de nenhuma funcionalidade nova em ruby gems ou bundler que tenha ficado na memória ou que eu tenha sentido como necessária. Certamente houve novidades, mas eu nem percebi

• Pelo histórico de reputação do Andre Arko (como resumido recentemente neste texto), fico um pouco cauteloso quanto à motivação desse movimento

  • Esse texto parece um ataque baseado em ressentimento pessoal. Recomendo não dar peso demais a ele ao formar uma avaliação

  • No cenário mais negativo, seria algo assim: uv é uma ferramenta excelente, mas a Astral claramente planeja integração com serviços pagos. Isso funciona como uma espécie de barreira de entrada. E há quem veja o Andre e sua equipe como tendo se inspirado no mundo Python (como no sucesso do uv) para fazer a mesma coisa no Ruby. Ao anunciar o rv, eles estariam tentando fazer o Ruby Gems depender deles, e, olhando para casos como o da Hashicorp, é cada vez mais comum atrair usuários com a parte gratuita e colocar funções essenciais atrás de um paywall enterprise. Acho tão arriscado quanto a situação atual do Ruby Central deixar o ecossistema Ruby dependente de uma pessoa específica ou de um pequeno grupo

• É impressionante ver a comunidade de open source se unir assim para encontrar uma solução. Quero agradecer a todos que se empenharam nesse processo

  • Ainda assim, o tempo e a especialização dos mantenedores precisam ser recompensados. Mesmo que banda e armazenamento sejam baratos, alguém precisa pagar essa conta, então acho bom doar para o projeto

• É só um pensamento meu, mas fico me perguntando por que não migrar o novo padrão para git. Não parece uma alternativa muito melhor, com assinatura de commits, assinatura de tags e estrutura distribuída?

  • O protocolo git tem alta complexidade e pouca escalabilidade. Especialmente se todos os pacotes tiverem de ser baixados de novo no CI a cada vez, isso seria ineficiente. Arquivos compactados únicos são muito mais fáceis de distribuir. Algoritmos de digest e assinatura não são exclusivos do git, e a parte mais difícil é a gestão de chaves e identidade, algo que o git também não resolve completamente (ou seja, não confunda git com GitHub)

  • Alguém teria de operar um servidor git, e seria preciso encontrar e fazer pull desse servidor para cada gem. Nem todos os servidores git teriam a versão mais recente, então cada um precisaria escalar separadamente. A vantagem da centralização é que tudo fica num só lugar, a escala é tratada de uma vez, e as atualizações também são aplicadas ao mesmo tempo. Antigamente usávamos artifactory etc. como proxy para NPM, gerenciadores de pacotes e contêineres Docker, e mesmo que o serviço intermediário caísse ainda era possível distribuir sem problemas. Mas, para desenvolvedores ou equipes pequenas, isso parece overhead de gestão desnecessário

  • Na verdade, o rubygems (software) já consegue buscar pacotes de qualquer repositório git. Até certo ponto, isso já é suportado

  • A linguagem Go já adota esse tipo de abordagem

  • Depois de ver o ecossistema de empacotamento do Go, fico em dúvida se migrar para git ainda parece uma boa ideia

• O mais importante é que pelo menos poderiam ter colocado um link para o repositório git, para que desse para ver de fora como o projeto está sendo mantido, mas isso não existe agora. Há uma lista de mantenedores, mas sem link para o repositório git, fiquei com a impressão de que é um projeto mais centrado nas pessoas do que no código

  • Se for um repositório de pacotes, não acho que um link como o do repositório do Ansible precise necessariamente estar no primeiro anúncio. O mais importante num repositório de pacotes é a confiança. A aquisição hostil ocorrida no RubyGems destruiu essa confiança, e uma alternativa operada diretamente pelos mantenedores originais que foram afastados me parece, ao contrário, uma boa mudança. Na verdade, parece que você já decidiu a conclusão e só está acrescentando justificativas. E, só para constar, na página principal do rubygems.org também não há um link de repositório git em destaque

  • O código-fonte está aqui

• Deixando a controvérsia recente de lado, fico pensando se uma fonte alternativa de pacotes compatível, ou um gerenciador compatível, ou um gerenciador de versões compatível, é algo neutro, positivo ou negativo para um ecossistema open source

  • Na maior parte, vejo isso como positivo. Monopólio leva à estagnação, e concorrência gera inovação. Em open source vale o mesmo

• Entendo que às vezes um fork é necessário, mas é um pouco amargo pensar que eles não conseguiram se coordenar. Se todos têm o objetivo comum de fazer o ecossistema Ruby avançar, não daria para colaborar apesar do contexto político ou das diferenças de opinião pessoal? No passado, Merb e Rails, Bundler e RubyGems, RubyTogether e RubyCentral acabaram se unindo, então espero que isso também se resolva algum dia

• Acho que esse problema poderia ser resolvido reformulando a forma de publicar e baixar gems. Só que quem poderia promover essa mudança é justamente o lado que hoje controla o software e a infraestrutura, e parece não ter muito incentivo para melhorar. Considero toda essa situação absurda, e nem entendo de onde vem tanta antipatia pelo DHH. É triste porque o jeito mais fácil de destruir um projeto open source é justamente com esse tipo de drama e forks. Ruby é uma linguagem antiga, mas não tem uma base de usuários tão grande, e essa controvérsia está prejudicando todo o ecossistema, o que me entristece como ex-desenvolvedor Ruby

• Acho que foi uma excelente reação à aquisição hostil do repositório e da organização do RubyGems no GitHub pelo Ruby Central. Espero que consigam apoio financeiro para os custos de hospedagem

  • Pelo que sei, os custos de hospedagem já estão cobertos