Le projet PyPy, une mise en œuvre du langage Python écrite elle-même en Python, a annoncé avoir transféré son dépôt principal et son système de suivi des problèmes sur GitHub. En d'autres termes, PyPy quitte le système de contrôle de version Mercurial et rejoint la communauté open source de GitHub, propriété du géant des logiciels Microsoft. PyPy a déclaré que Mercurial reste "une excellente solution", mais le projet ajoute avoir rejoint GitHub pour une meilleure visibilité et un meilleur engagement de la communauté. L'équipe de PyPy estime que l'open source est devenu synonyme de GitHub et que le projet est trop petit pour lutter contre cela.PyPy est un remplacement direct de l'interpréteur Python standard, CPython. Alors que CPython compile Python en un bytecode intermédiaire qui est ensuite interprété par une machine virtuelle, PyPy utilise la compilation juste à temps (Just-In-Time - JIT) pour traduire le code Python en langage d'assemblage natif de la machine. Ce qui permet de rendre l'interprétation du code Python nettement plus rapide. En fonction de la tâche effectuée, les gains de performance peuvent être spectaculaires. En moyenne (géométrique), PyPy accélère Python d'environ 4,7 fois par rapport à Python 3.7, certaines tâches pouvant être accélérées jusqu'à 50 fois ou plus.
Le projet était jusque-là hébergé sur Mercurial, mais le 29 décembre 2023, l'équipe de PyPy a annoncé la migration de son dépôt canonique et de son système de suivi des problèmes de Heptapod vers la plateforme rivale GitHub. L'équipe a expliqué que la migration de Mercurial vers GitHub est motivée par plusieurs facteurs. Elle dit avoir rencontré des difficultés pour suivre les problèmes et les contributions sur Heptapod. Dans son billet de blogue sur le sujet, Matti Picus, contributeur principal, a déclaré que le projet a besoin d'une visibilité plus large et d'un accès plus facile, deux choses pour lesquelles GitHub est réputé dans la communauté open source.
Dans le même temps, Picus estime que la prédominance de GitHub dans l'hébergement de projets open source offre au projet PyPy la possibilité de s'intégrer dans un écosystème de développeurs plus dynamique et plus actif. La plateforme unifiée de GitHub simplifie également le suivi des problèmes et du code, rationalisant ainsi le processus de développement. Picus a déclaré : « nous pensons toujours que Mercurial est un meilleur système de contrôle de version. Le modèle de branche nommée et l'interface utilisateur sont supérieurs. Mais… ». Dans son billet de blogue, Picus résume les raisons derrière ce changement comme suit :
- le dépôt Heptapod n'était pas bien indexé par les principaux moteurs de recherche ;
- depuis qu'Heptapod a renforcé son contrôle du spam, nous recevons des rapports selon lesquels les utilisateurs créent des problèmes pour ensuite les signaler comme étant du spam ;
- l'open source est devenu synonyme de GitHub, et nous sommes trop petits pour changer cela ;
- une grande partie du développement actuel est une réaction à la résolution de problèmes. Il est plus facile de suivre les problèmes interdépendants si tout le code se trouve sur la même plateforme ;
- la FAQ présente deux arguments contre cette évolution. Les notes Github résolvent en grande partie le point (1) : la difficulté de découvrir la provenance des modifications, mais pas entièrement. Mais le problème principal est le point (2), il s'avère que le fait de ne pas passer à GitHub est un obstacle à la contribution et au signalement des problèmes ;
- GitHub est plus riche en ressources qu'Heptapod. Nous pourrions ajouter des tâches CI pour remplacer une partie de notre infrastructure Buildbot vieillissante.
PyPy a déjà déplacé son référentiel par le passé. En 2010, il a mis le code sur Atlassian Bitbucket. Dix ans plus tard, il est passé à Mercurial, hébergé chez Heptapod. Une entrée de la FAQ, référencée par Picus, remarque que Git n'a pas d'équivalent aux branches nommées de Mercurial ; et que passer à GitHub juste parce que tout le monde le fait est "un argument sur des bases minces". Ce point de vue a maintenant changé. Expliquant un mouvement qui déprimera ceux qui croient que GitHub a déjà trop de domination, Picus a déclaré que le fait d'être hors de la communauté open source de GitHub peut être un obstacle à l'évolution d'un projet.
Selon le billet de blogue de Picus, il sera toujours possible d'utiliser Mercurial pour contribuer au projet PyPy, mais le code devra être transféré sur GitHub en utilisant les mêmes techniques que celles utilisées pour migrer le référentiel. En outre, ce changement modifiera quelque peu le flux de travail normal. Il n'y aura plus de flux de travail "commit directly to main", et les contributeurs utiliseront désormais la technique normale de git en créant une branche dérivée du dépôt et en soumettant une "pull request". De son côté, Heptapod n'autorise pas les forks personnels. Picus s'attend à un meilleur engagement de la communauté vis-à-vis de PyPy.
Dans le contexte plus large du développement de logiciels libres et open source, la migration de PyPy vers GitHub reflète une tendance à la consolidation sur GitHub, propriété de Microsoft. Cela a été reçu pour la plupart avec un sentiment d'inévitabilité et les avis révèlent que beaucoup de développeurs s'attendent à ce que d'autres projets sautent le pas afin d'avoir une meilleure visibilité et plus d'engagements. Certains critiques se sont toutefois demandés pourquoi Picus et son équipe n'ont pas choisi GitLab. « A-t-on pensé à GitLab ? Pourrait-il être envisagé ? Cela devrait être plus facile après le passage à git », indique un commentaire.
En réponse, Picus a déclaré que certains problèmes peuvent survenir lors de l'utilisation de GitLab et que cela pouvait être un point de friction pour les contributeurs du projet. Picus explique : « nous étions sur GitLab : foss.heptapod.net est une version amicale de GitLab. Le problème est la friction de l'interaction avec d'autres logiciels lorsqu'ils sont tous situés sur GitHub ». Un autre critique a écrit : « c'est un peu triste que ce soit vrai. Je suis moi-même coupable, je contribue à des projets sur GitHub plus souvent que sur n'importe quelle autre plateforme. Et lorsque je recherche des projets open source, le premier site que j'utilise est GitHub ».
Les discussions sur la toile font état de sentiments mitigés au sein de la communauté concernant la domination de GitHub. Si certains y voient une évolution positive pour les projets open source, d'autres s'inquiètent de la centralisation du pouvoir et des difficultés rencontrées par les petites plateformes pour attirer et retenir les grands projets. Le déménagement de PyPy pourrait potentiellement influencer d'autres projets open source, en centralisant davantage le développement de logiciels sur GitHub et en façonnant le futur paysage des collaborations open source. D'autres développeurs rejettent la faute sur la plateforme concurrente SourceForge.
« C'est en grande partie la faute de SourceForge. Ils avaient une avance considérable et ont complètement raté leur coup », a écrit un critique. Un autre a ajouté : « ils n'ont pas seulement raté leur coup, ils ont activement saboté la réputation qu'ils avaient acquise en ajoutant des logiciels malveillants aux logiciels. Non seulement c'était un énorme problème, mais cela a ruiné la réputation de nombreux projets FOSS auprès de personnes qui voulaient utiliser certains des logiciels open source les plus populaires auprès des consommateurs, comme Filezilla. Pendant ce temps, GitHub a gagné la confiance et la bonne volonté de beaucoup de développeurs ».
Source : PyPy
Et vous ?
Quel est votre avis sur le sujet ? Que pensez-vous de la décision de PyPy de quitter Mercurial pour GitHub ? Partagez-vous l'avis selon lequel l'open source est devenu synonyme de GitHub ? Comment GitHub a-t-il acquis une telle domination dans la communauté open source ? Que pensez-vous de l'avis des critiques qui rejettent la faute sur SourceForge ? Selon vous, la domination de GitHub va-t-elle continuer à se consolider à l'avenir ? Pourquoi ?Voir aussi
Apache Software Foundation rejoint la communauté open source de GitHub et met fin à son propre service git Un rapport de GitHub démontre la forte dépendance mondiale aux logiciels open source, si ces logiciels continuent de gagner en popularité, les logiciels propriétaires sont toujours bien vivants Le projet Kyoto quitte à son tour GitHub en guise de protestation contre les porteurs de projets qui utilisent l'open source pour aboutir à des solutions logicielles dont ils ferment le code source