- gem.coop est un nouveau serveur de gem pour l’écosystème Ruby
- Construit par d’anciens responsables de RubyGems.org pour la communauté
- Propose tous les gems publics de RubyGems.org avec une synchronisation en temps réel
- Met l’accent sur la transparence et la participation de la communauté avec une gouvernance inspirée de Homebrew
- Vise un hébergement de gems durable et renforcé en matière de sécurité
Présentation de gem.coop
- gem.coop est un nouveau serveur de gem conçu pour l’écosystème Ruby, avec pour objectif d’offrir un environnement d’hébergement plus rapide et plus simple
- Tout en conservant une compatibilité totale avec Bundler, il met en avant des performances et une stabilité optimisées pour les environnements de développement de nouvelle génération
- Ce projet est développé comme un service pour la communauté, avec la participation directe d’anciens administrateurs et membres de l’équipe opérationnelle de RubyGems.org
- Tous les gems publics sont synchronisés en temps réel depuis RubyGems.org et peuvent être utilisés immédiatement sur gem.coop
- Il suffit de modifier l’adresse source dans un Gemfile existant pour l’utiliser, ce qui rend l’adoption très simple
Gouvernance et participation de la communauté
- En s’appuyant sur le modèle de gouvernance du projet Homebrew, le service adopte une structure transparente et facile à rejoindre
- Avec la coopération de Mike McQuaid, l’organisation et le mode de fonctionnement sont en cours de préparation, et une forme officielle de gouvernance devrait être publiée avant le 10 octobre
- Le service prévoit un fonctionnement ouvert afin que toute la communauté Ruby puisse contribuer et participer
Objectifs du service et feuille de route
- L’objectif ultime de gem.coop est de fournir une plateforme d’hébergement de gems appartenant à la communauté, rapide, transparente, durable et renforcée sur le plan de la sécurité
- Dans un premier temps, le service prend en charge le bundling et l’installation de tous les gems publics, avec des améliorations continues prévues pour les fonctionnalités et la qualité
- Il est possible de recevoir des mises à jour mensuelles via la newsletter de gem.coop
Équipe
- Le développement et l’exploitation relèvent de Gem Cooperative, avec deivid-rodriguez, duckinator, indirect, martinemde, segiddins et simi comme principaux contributeurs
1 commentaires
Avis Hacker News
En laissant de côté toutes les polémiques, je constate qu’à l’heure actuelle, RubyGems d’origine se retrouve sans mainteneurs, alors que le nouveau projet rassemble la plupart des contributeurs historiques. Avant, seul deivid semblait vraiment visible, mais maintenant on dirait que la plupart des figures importantes ont rejoint ce camp. J’ai désormais l’impression que ce fork est un logiciel mieux maintenu. Je me demande s’il y a des informations sur la probabilité que les gens migrent bientôt vers celui-ci, ainsi que sur le modèle de financement ou la charge des coûts d’hébergement. Il y a aussi des infos supplémentaires ici
On peut avoir l’impression que ce fork est aujourd’hui le logiciel le mieux maintenu, mais j’ai le sentiment qu’en pratique, l’essentiel n’est pas tant le logiciel lui-même que le stockage et la bande passante du service d’indexation. Je me dis qu’un simple moteur de recherche de gems stockant les hashes et redirigeant les téléchargements vers des dépôts externes, par exemple GitHub, pourrait peut-être très bien fonctionner
Cette situation est un peu amère. Si ce fork réussit, on risque de se retrouver comme dans l’univers JS à se demander « quel gestionnaire de paquets utiliser ? ». La belle simplicité du « il suffit d’utiliser bundler et rubygems » disparaîtra. Cela dit, je veux vraiment saluer les anciens mainteneurs de RubyGems qui, après avoir soulevé publiquement le problème, se sont discrètement mis au travail sur le fork. Un fork de RubyGems paraissait impossible, et pourtant ils sont en train d’en faire émerger au moins une petite possibilité. Les grandes entreprises resteront sans doute majoritairement sur RC, soutenu par Shopify, et dans ce type d’organisation, les audits de sécurité seront probablement renforcés, mais l’innovation manquera. En revanche, si gems.coop réussit, ce sera simplement parce qu’il s’imposera comme « le meilleur outil ». Par exemple, rv.dev, que développe André, serait en avance sur l’expérience développeur (DX) en tant qu’outil « rapide et tout-en-un » gérant aussi bien les versions de Ruby, les dépendances de gems que des fonctionnalités à la npx. On parle aussi d’espaces de noms, de checksums et d’approches de sécurité plus agressives sur le plan technique, et si RC continue sur sa trajectoire actuelle, il est possible qu’au final la solution techniquement supérieure l’emporte. Côté financement, André semble considérer que « les organisations capables d’assumer les coûts d’une infrastructure OSS doivent réellement payer », et je suis d’accord. Ce serait une méthode transparente permettant de prévoir précisément les coûts et de les répartir selon le nombre d’entreprises qui paient. Enfin, je pense que la cause profonde de l’effondrement actuel de RC est une concentration excessive du financement entre les mains d’un petit nombre de sponsors, et j’espère que Ruby Co-op mettra en place un modèle de financement distribué avec 100, 1000 contributeurs ou plus
À noter que le modèle de financement n’est pas encore défini. Lien connexe
Il y a trop peu d’informations sur la page officielle. Donc, en partant de quelques hypothèses logiques : 1) la distribution ne peut que dépendre de RubyGems ; 2) il n’y a pas d’interface pour la recherche et la consultation des gems, donc cela dépend aussi de RubyGems. Au-delà des détails techniques, il n’existe pour moi absolument aucun déclencheur concret de bascule, sauf à être idéologiquement d’accord avec les mainteneurs du fork. Pour un usage professionnel, je n’ai aucune raison de migrer, et si cela m’intéresse à titre personnel, je le garde simplement en tête. Comme la plupart des forks, soit ils atteignent leur but puis fusionnent, soit ils deviennent un nouveau standard, soit on les oublie. Si je ne suis pas directement concerné, je me contenterai d’observer. Ce n’est pas pour minimiser leurs critiques ni leur travail, mais la situation me paraît nettement plus convaincante que dans le cas d’un fork de Rails à cause de DHH
Au cours des dix dernières années, je n’arrive pas à citer de nouvelle fonctionnalité de ruby gems ou de bundler qui m’ait marqué ou semblé nécessaire. Il y en a sûrement eu, mais je ne m’en suis pas rendu compte
Quand on regarde la réputation d’Andre Arko (comme le résume récemment ce billet), je reste un peu méfiant quant aux motivations de cette initiative
Ce billet ressemble à une attaque fondée sur une rancune personnelle. Je recommande de ne pas lui accorder trop de poids dans l’évaluation
Dans le scénario le plus négatif, cela ressemblerait à ceci : uv est un outil élégant, mais Astral prévoit clairement une intégration avec des services payants. C’est une forme de verrouillage à l’entrée. Certains pensent qu’Andre et son équipe ont observé le monde Python (avec le succès de uv) pour reproduire la même chose côté Ruby. En annonçant rv, ils chercheraient à rendre Ruby Gems dépendant d’eux, et au vu des cas comme Hashicorp, il devient de plus en plus fréquent d’attirer les utilisateurs avec du gratuit puis de placer les fonctions essentielles derrière un paywall entreprise. Je pense qu’il est tout aussi risqué que l’écosystème Ruby soit dépendant d’une personne en particulier ou d’un petit groupe, exactement comme avec Ruby Central aujourd’hui
Il est impressionnant de voir la communauté open source se rassembler ainsi pour chercher une solution. Je tiens à remercier toutes les personnes qui ont contribué à ce processus
Je me demande pourquoi, selon moi, on ne passerait pas à git comme nouveau standard. Avec les signatures de commit, les signatures de tag et la structure distribuée, cela ne semble-t-il pas être une bien meilleure alternative ?
Le protocole git est plus complexe et passe moins bien à l’échelle. C’est particulièrement inefficace si l’on retélécharge tous les paquets à chaque exécution CI. Une archive en fichier unique est bien plus facile à distribuer. Les digests et les algorithmes de signature ne sont pas propres à git, et la gestion des clés et de l’identité est la partie la plus difficile ; git ne résout pas totalement cela non plus (autrement dit, il ne faut pas confondre git et GitHub)
Quelqu’un doit faire tourner des serveurs git, et il faut aller tirer chaque gem depuis ce serveur git spécifique. Tous les serveurs git n’auront pas forcément la dernière version, donc chacun devra monter en charge séparément. L’avantage de la centralisation, c’est que tout se trouve au même endroit, que la mise à l’échelle se fait d’un seul coup et que les mises à jour s’appliquent en même temps. Autrefois, on utilisait des proxys comme artifactory pour NPM, les gestionnaires de paquets et les conteneurs docker, ce qui permettait de déployer sans problème même si le service intermédiaire tombait. Mais pour de petits développeurs ou de petites équipes, cette gestion semble être une surcharge inutile
En réalité, rubygems (le logiciel) sait déjà récupérer des paquets depuis n’importe quel dépôt git. C’est donc dans une certaine mesure déjà pris en charge
Go utilise déjà ce type d’approche
Après avoir vu l’écosystème de packaging de Go, j’ai du mal à penser qu’un basculement vers git soit une bonne idée
Le point le plus important, c’est qu’ils auraient au moins pu publier un lien vers un dépôt git permettant de voir de l’extérieur comment le projet est maintenu, mais ce n’est pas le cas actuellement. Il y a bien une liste de mainteneurs, mais pas de lien vers un dépôt git, ce qui m’a donné l’impression d’un projet centré sur les personnes plus que sur le code
S’il s’agit d’un dépôt de paquets, je ne pense pas qu’un lien de type dépôt Ansible doive absolument figurer dans la toute première annonce. Pour un registre de paquets, l’élément le plus important est la confiance. L’OPA hostile menée sur RubyGems par RubyGems a brisé cette confiance, et voir les mainteneurs historiques écartés revenir eux-mêmes avec une alternative est plutôt un changement positif. J’ai plutôt l’impression que tu as déjà tiré ta conclusion et que tu cherches seulement des justifications. D’ailleurs, on ne voit pas non plus clairement de lien vers un dépôt git sur la page principale de rubygems.org
Le code source est ici
Même en mettant de côté la polémique récente, je me demande si l’existence d’une source de paquets ou d’un gestionnaire alternatif compatible, ainsi que d’un gestionnaire de versions alternatif, est neutre, positive ou négative pour un écosystème open source
Je comprends qu’un fork soit parfois nécessaire, mais je trouve un peu amer qu’ils n’aient pas réussi à se coordonner. Si tout le monde partage le même objectif de faire progresser l’écosystème Ruby, ne pourrait-on pas coopérer malgré des arrière-plans politiques ou des opinions personnelles différentes ? Par le passé, Merb et Rails, Bundler et RubyGems, RubyTogether et RubyCentral ont fini par fusionner, donc j’espère qu’une solution émergera un jour
Je pense qu’une refonte du mode de publication et de téléchargement des gems pourrait résoudre ce genre de problème. Mais le souci, c’est que les seuls acteurs capables d’imposer ce changement sont précisément ceux qui contrôlent aujourd’hui le logiciel et l’infrastructure, et ils n’ont guère de motivation pour l’améliorer. Je trouve cette situation absurde, et je ne comprends pas non plus l’hostilité envers DHH. Ce genre de drame et de fork est la manière la plus simple de faire sombrer un projet open source, ce qui est regrettable. Ruby est un langage ancien mais qui n’a déjà pas une base d’utilisateurs immense, et ce type de controverse nuit à l’ensemble de l’écosystème, ce qui m’attriste en tant qu’ancien développeur Ruby
Je pense que c’est une excellente initiative qui répond efficacement à la prise de contrôle hostile du dépôt GitHub et de l’organisation RubyGems par Ruby Central. J’espère qu’un soutien financier sera mis en place pour couvrir les coûts d’hébergement