Le Microsoft de 2018 n’a aucun intérêt à corrompre GitHub (Thierry Carrez, OpenStack Foundation)

Il y a quelques jours, le monde de l'open source découvrait avec stupéfaction le rachat de GitHub par Microsoft. La plateforme GitHub a été lancée en février 2008, permettant l'hébergement de dépôts de code Git et la collaboration autour de ceux-ci, gratuitement pour les dépôts publics. Dix ans plus tard, elle était devenue la plaque tournante du développement en open source avec plus de 28 millions de dépôts publics.

Pour toute une génération de développeurs, open source et GitHub sont intimement liés. Ils considèrent leur profil GitHub comme un CV, n'envisageraient pas de gérer leurs projets sur une autre plateforme. Ils ne pensent le développement qu'en termes de forks et de pull requests, et mesurent le succès d'un projet au nombre de "GitHub stars" que celui-ci a collecté. Certains croient même que "git" est l'interface ligne de commande de GitHub ! De nombreux cris se sont ainsi élevés à l'annonce du rachat par Microsoft: l'archétype du développement centralisé et propriétaire, la Némésis du logiciel libre. Certains ont même appelé à #movingtogitlab: un boycott immédiat avec transfert sur la plateforme concurrente GitLab, qui a ainsi vu plus de 100.000 dépôts migrés par jour depuis l'annonce... Est-ce bien raisonnable ?

Le Microsoft des années 2000 n'est pas le Microsoft de 2018

La crainte affichée serait que Microsoft va corrompre GitHub (ou abuser de son contrôle de la plateforme) afin d'affaiblir le logiciel libre. Mais le Microsoft des années 2000 n'est pas le Microsoft de 2018. Sous la houlette de Satya Nadella, Microsoft a entrepris une transformation profonde, avec le cloud public Azure comme nouveau fer de lance. Loin de décrire Linux comme un ennemi, le Microsoft de 2018 a adopté le logiciel libre. Plus d'un tiers des serveurs Azure sont sous Linux. Microsoft contribue à de nombreux projets open source: c'est par exemple le 4e plus gros contributeur à Kubernetes. En avril, Microsoft publiait Azure Sphere, des composants hardware combinés à une distribution Linux maison. Et saviez-vous que le projet avec le plus grand nombre de contributeurs sur GitHub était VSCode de Microsoft ? Le Microsoft de 2018 n'a aucun intérêt à corrompre GitHub. Il a de nombreuses cartes intéressantes à jouer, comme une intégration poussée avec Azure, mais la simple acquisition d'une plateforme populaire de développement a déjà une grande valeur en soi. Pour le business model de GitHub, c'est l'acquéreur idéal, capable de pousser le développement moderne sous Git dans les entreprises qui y résistaient encore.

Non, le vrai problème avec cette acquisition, c'est qu'elle rappelle à cette génération de développeurs que le choix d'une plateforme propriétaire n'est pas sans risque: ils deviennent soumis aux désirs du propriétaire. C'était déjà le cas avec un GitHub appartenant au capital-risque. Mais l'acquisition par Microsoft est une douloureuse piqûre de rappel de leur absence de contrôle. L'ironie est que Git lui-même est né d'une telle leçon.

En 2002, avec une activité débordante, le kernel Linux atteint les limites de son outil de gestion de sources d'alors, CVS. Linus cherche alors une solution plus moderne, décentralisée, autorisant la création et la fusion de branches multiples. Il trouve la solution en Bitkeeper, un système propriétaire mais très avancé de gestion de sources, dont la licence est offerte gratuitement aux développeurs de Linux. Cela vous rappelle quelque chose ? Tout se passe très bien jusqu'en 2005, quand Bitmover, propriétaire de Bitkeeper, décide de révoquer cette licence. Panique dans le développement de Linux, car il n'existe alors aucun logiciel libre capable de soutenir le modèle de développement que le kernel a adopté, grâce à Bitkeeper. Cela force Linus Torvalds à passer plusieurs mois à écrire son propre système de gestion de source décentralisé: Git était  né. La communauté jure qu'on ne l'y reprendra pas, mais 13 ans plus tard l'histoire ne fait que se répéter, avec GitHub dans le rôle de Bitkeeper, ironiquement basé sur Git.

A travers cette anecdote, le mois dernier à Vancouver lors de la conférence OpenDev, Benjamin Mako Hill, bien connu du monde du logiciel libre, nous a ainsi rappelé l'importance de s'appuyer sur des logiciels libres pour construire des logiciels libres: « Votre logiciel ne peut être vraiment libre s'il dépend de logiciels non libres pour sa création ». La plateforme propriétaire, bien que simple et confortable, fait planer une épée de Damoclès au-dessus de votre projet. C'est cela qui, en réalité, gène les utilisateurs de GitHub dans l'acquisition par Microsoft: le rappel de leur vulnérabilité.

GitLab : une solution idéale ?

La migration vers GitLab n'est pas vraiment une solution à ce problème. GitLab est présenté comme l'alternative idéale: proche en fonctionnalité de GitHub, son code est open source. Mais à y regarder de plus près, GitLab est "open core": si la version de base est libre, la version avancée, elle, est propriétaire. Le service GitLab est construit sur cette version propriétaire... plaçant ses utilisateurs sous exactement le même risque que GitHub ou Microsoft GitHub. Les conditions d'utilisation de GitLab (comme celles de GitHub) prévoient que son propriétaire (qui peut changer du jour au lendemain) peut révoquer l'accès de quiconque sans raison particulière ni préavis. En dessous d'une certaine taille ou d'un certain niveau d'activité, on peut certainement vivre avec le risque. Mais au-delà, la disruption en cas d'arrêt du service est significative. La migration vers une autre plateforme est elle aussi très coûteuse, d'autant plus qu'on développe une dépendance envers certaines fonctionnalités "avancées" de la plateforme.

Du Libre avec du Libre

Pour les grands projets open source, la vraie solution consiste à s'appuyer sur une plateforme entièrement basée sur des logiciels libres. Un certain nombre de projets disposent ainsi de leur propre plateforme. C'est le cas d'OpenStack, pour lequel un groupe de contributeurs opère ouvertement une infrastructure de projet complète autour de Gerrit. Dans sa propre plateforme, il est également recommandé d'éviter les solutions "open core": la tension entre les fonctions de la version "communauté" et les fonctions avancées réservées à la version propriétaire est généralement insoluble. Que se passe-t-il quand quelqu'un veut contribuer une amélioration réservée dans son business plan à la version propriétaire ?

Au final, cette histoire montre qu'entre le propriétaire et le libre il y a trois modèles, et non deux : Le logiciel propriétaire qui, par son contrôle, fait peser un risque sur ses utilisateurs, et ce même quand il est "gratuit" et accessible par Internet ; Le logiciel open source mono-vendeur, qu'il soit open core ou juste contrôlé agressivement qui, sous vernis de logiciel libre, n'est pas très différent de son grand frère propriétaire ; et le logiciel open source développé en collaboration ouverte, où tous les contributeurs et utilisateurs participent en égaux. Ce dernier est le seul sur lequel on peut bâtir une infrastructure durable. C'est tout l'enjeu du mouvement vers l'infrastructure ouverte, et la bataille ne fait que commencer.