Gem.coop

• gem.coop es un nuevo servidor de gems para el ecosistema de Ruby
• Fue creado por el antiguo equipo operativo de RubyGems.org para la comunidad
• Ofrece todas las gems públicas de RubyGems.org con sincronización en tiempo real
• Prioriza la transparencia y la participación de la comunidad con una gobernanza inspirada en Homebrew
• Su objetivo es ofrecer un hosting de gems sostenible y con seguridad reforzada

---

Introducción a gem.coop

• gem.coop es un nuevo servidor de gems diseñado para el ecosistema de Ruby, creado con el objetivo de ofrecer un entorno de hosting más rápido y simple
• Mantiene compatibilidad total con Bundler, al tiempo que pone énfasis en rendimiento y estabilidad optimizados para entornos de desarrollo de próxima generación
• Este proyecto es desarrollado como un servicio para la comunidad con participación directa de ex administradores y miembros del equipo operativo de RubyGems.org
• Todas las gems públicas se sincronizan en tiempo real desde RubyGems.org y pueden usarse de inmediato también en gem.coop
• Puede usarse simplemente cambiando la dirección de source en el Gemfile existente, por lo que su adopción es muy sencilla

Gobernanza y participación de la comunidad

• Se adopta una estructura transparente y de fácil participación tomando como referencia el modelo de gobernanza del proyecto Homebrew
• Con la colaboración de Mike McQuaid, se está preparando la configuración de la organización y la forma de operación, y se prevé publicar la estructura oficial de gobernanza antes del 10 de octubre
• Se planea operar con una estructura abierta para que cualquier persona de la comunidad Ruby pueda contribuir y participar

Objetivos del servicio y planes futuros

• El objetivo final de gem.coop es ofrecer una plataforma de hosting de gems, propiedad de la comunidad, que sea rápida, transparente, sostenible y con seguridad reforzada
• Al inicio, soportará el bundling y la instalación de todas las gems públicas, y más adelante seguirá mejorando sus funciones y calidad
• Es posible recibir actualizaciones mensuales a través del boletín de gem.coop

Equipo

• El desarrollo y la operación están a cargo de Gem Cooperative, liderado por deivid-rodriguez, duckinator, indirect, martinemde, segiddins y simi

[GN⁺]

Opiniones en Hacker News

• Dejando de lado toda la controversia, la situación actual es que en los RubyGems originales ya se fueron todos los maintainers, y confirmé que en el nuevo proyecto están participando la mayoría de los contribuidores principales de antes. Antes solo deivid tenía una presencia clara, pero ahora parece que la mayoría de las figuras importantes se pasaron para este lado. Ahora da la impresión de que este fork es el software mejor mantenido. Me pregunto si hay información sobre la posibilidad de que la gente empiece a migrar pronto, y también sobre el modelo de financiamiento o la carga de los costos de hosting. Hay más información aquí

  • Puede parecer que este fork está mejor mantenido en este momento, pero creo que lo realmente importante no es tanto el software en sí, sino el almacenamiento y el ancho de banda del servicio de indexación. Me pregunto si no funcionaría bien algo tan simple como hacer que el motor de búsqueda de gems almacene hashes y que las descargas apunten a repos externos, por ejemplo en GitHub

  • Esta situación es un poco amarga. Si este fork tiene éxito, terminaríamos como en el mundo JS, preguntándonos “¿qué package manager conviene usar?”. Se perdería esa hermosa simplicidad de “solo usa bundler y rubygems”. Aun así, quiero reconocer mucho a los antiguos maintainers de RubyGems que, después de plantear públicamente el problema, se pusieron a trabajar en el fork en silencio. Un fork de RubyGems parecía imposible, pero ahora están logrando crear aunque sea una pequeña posibilidad. La mayoría de las grandes empresas probablemente se queden en RC, respaldado por Shopify, y en ese tipo de organizaciones también se reforzarán las auditorías de seguridad, pero supongo que faltará innovación. En cambio, si gems.coop llega a tener éxito, será simplemente porque se establezca como “una mejor herramienta”. Por ejemplo, rv.dev, que hace André, sería una herramienta “rápida y todo en uno” con manejo de versiones de Ruby, dependencias de gems e incluso funciones tipo npx, así que en experiencia de desarrollador (DX) llevaría ventaja. También se están discutiendo namespaces, checksums y enfoques de seguridad técnicamente más agresivos, y si RC sigue como hasta ahora, creo que al final podría ganar el lado técnicamente superior. En cuanto al financiamiento, parece que André piensa que “las organizaciones que realmente pueden cubrir el costo de la infraestructura OSS deberían pagar”, y estoy de acuerdo. Creo que eso permitiría una forma transparente de calcular exactamente los costos y repartirlos según la cantidad de empresas que pagan. Por último, creo que la causa raíz de que RC se haya deteriorado así es que el financiamiento se concentró demasiado en unos pocos patrocinadores, así que espero que Ruby Co-op construya un modelo de financiamiento distribuido con 100, 1000 o más participantes

  • Tengan en cuenta que el modelo de financiamiento todavía no está definido. Enlace relacionado

  • En la página oficial hay demasiado poca información. Así que, haciendo algunas suposiciones lógicas: 1) no tienen más opción que depender de RubyGems para la distribución. 2) como no hay una UI para búsqueda y visualización de gems, también dependen de RubyGems. Dejando de lado los detalles técnicos, en la práctica no tengo ningún motivo para cambiarme salvo que esté ideológicamente de acuerdo con los maintainers del fork. Para fines profesionales no hay razón para migrar, y si me interesa a nivel personal, apenas lo tendría presente. Como la mayoría de los forks, o logran su objetivo y se vuelven a fusionar, o se convierten en un estándar nuevo, o quedan en el olvido. Si no me afecta directamente, yo solo voy a observar. No es por menospreciar sus reclamos ni su trabajo, pero es una situación mucho más convincente que, por ejemplo, hacer un fork de Rails por culpa de DHH

  • En los últimos 10 años no se me ocurre ninguna función nueva en ruby gems o bundler que me haya resultado memorable o necesaria. Seguro hubo funciones nuevas, pero no las noté

• Viendo la reputación de Andre Arko (como se resume recientemente en este texto), me mantengo un poco cauteloso sobre cuál es la motivación de este movimiento

  • Ese texto parece un ataque basado en un rencor personal. Recomiendo no darle demasiado peso al momento de evaluarlo

  • Si uno lo mira desde el escenario más negativo, sería algo así: uv es una herramienta genial, pero Astral claramente planea integraciones con servicios de pago. Ese tipo de cosas se vuelve una barrera de entrada. Y hay una visión según la cual Andre y su equipo tomaron inspiración del ecosistema Python (como el éxito de uv) para intentar hacer lo mismo en Ruby. Al anunciar rv, buscarían que Ruby Gems pase a depender de ellos, y si uno mira casos como Hashicorp, cada vez es más común atraer gente con lo gratuito y poner funciones esenciales detrás de un paywall enterprise. Me parece igual de riesgoso que el ecosistema Ruby quede atado a una persona o a un grupo pequeño, tal como pasa hoy con Ruby Central

• Me sorprende ver a la comunidad open source unirse así para buscar una solución. Quiero agradecer a todos los que pusieron esfuerzo en este proceso

  • Aun así, el tiempo y la experiencia de los maintainers necesitan compensación. Aunque el ancho de banda y el almacenamiento sean baratos, alguien tiene que pagar esos costos, así que creo que es bueno donar al proyecto

• Es una idea mía, pero me pregunto por qué no migran a git como nuevo estándar. ¿No parece una alternativa mucho mejor, con firmas de commits, firmas de tags y una estructura distribuida?

  • El protocolo de git tiene mucha complejidad y poca escalabilidad. Sobre todo si en CI tienes que volver a descargar todos los paquetes cada vez, sería ineficiente. Un archivo único es mucho más fácil de distribuir. Los digests y los algoritmos de firma no son exclusivos de git, y la parte más difícil es la gestión de claves e identidad, cosa que git tampoco resuelve por completo (es decir, no hay que confundir git con GitHub)

  • Alguien tendría que operar un servidor de git, y para cada gem habría que encontrar ese servidor y hacer pull desde ahí. Tampoco todos los servidores de git tendrían siempre la versión más reciente, así que cada uno tendría que escalar por separado. La ventaja de la centralización es que todo está en un solo lugar, la escala se resuelve una vez y las actualizaciones se aplican al mismo tiempo. Antes usábamos proxies como artifactory para NPM, package managers y contenedores Docker, y podíamos desplegar sin problemas incluso si el servicio intermedio se caía. Pero para desarrolladores o equipos pequeños, ese tipo de administración parece una sobrecarga innecesaria

  • En realidad, rubygems (el software) ya puede traer paquetes desde cualquier repo git. Hasta cierto punto, eso ya está soportado

  • Go ya adoptó un enfoque así

  • Viendo el ecosistema de empaquetado de Go, dudo que cambiarse a git sea una buena idea

• Lo más importante es que al menos podrían haber puesto un enlace al repo git para que desde afuera se vea cómo se mantiene el proyecto, pero ahora no hay nada. Hay una lista de maintainers, pero no un enlace al repo git, así que me dio la impresión de que es un proyecto más centrado en personas que en código

  • Si es un repositorio de paquetes, no creo que haga falta poner un enlace tipo repo de Ansible en el anuncio principal. Lo más importante en un repositorio de paquetes es la confianza. La toma hostil de RubyGems que ocurrió en Ruby Central rompió esa confianza, así que una alternativa operada directamente por los maintainers originales que quedaron fuera de línea me parece más bien un buen cambio. Más bien parece que ya decidiste tu conclusión y solo le estás agregando excusas. Como referencia, en la portada de rubygems.org tampoco se ve claramente un enlace al repo git

  • El código fuente está aquí

• Dejando de lado la controversia reciente, me hace pensar si tener una fuente o manager alternativo de paquetes compatible, o un version manager, es algo neutral, positivo o negativo para el ecosistema open source

  • Yo diría que en su mayoría es positivo. Los monopolios llevan al estancamiento y la competencia impulsa la innovación. En open source pasa lo mismo

• Entiendo que a veces hace falta un fork, pero me deja un sabor amargo que no hayan podido coordinarse. Si todos comparten el objetivo de hacer crecer el ecosistema Ruby, ¿no podrían colaborar aunque haya trasfondos políticos o diferencias de opinión personal? En el pasado Merb y Rails, Bundler y RubyGems, RubyTogether y RubyCentral terminaron uniéndose, así que espero que algún día esto también se resuelva

• Creo que si se rediseñara la forma en que se publican y descargan los gems, este tipo de problema podría resolverse. Pero el problema es que quienes podrían impulsar ese cambio son justamente quienes controlan hoy el software y la infraestructura, y no tienen demasiados incentivos para mejorar. Toda esta situación me parece absurda, y tampoco entiendo el rechazo hacia DHH. Da pena porque este tipo de drama y forks es la manera más fácil de dañar un proyecto open source. Ruby es un lenguaje viejo y aun así su base de usuarios no es tan grande, así que esta controversia está perjudicando a todo el ecosistema, y como exdesarrollador Ruby me pone triste

• Me parece una gran movida para responder de forma efectiva a la toma hostil del repo de GitHub y de la organización de RubyGems por parte de Ruby Central. Ojalá consigan apoyo financiero para cubrir los costos de hosting

  • Tengo entendido que los costos de hosting ya están cubiertos