L’open source est de plus en plus populaire et répandu parmi les développeurs. Grâce à des plate-formes comme GitHub, qui ont standardisé la manière de contribuer à un projet, l’open source est devenu plus accessible, au point de devenir une norme. Mais cette nouvelle configuration n’est pas sans poser certains problèmes.

Dans ce nouveau chapitre de son ouvrage Des Routes et des ponts (traduit chapitre après chapitre par l’équipe Framalang), Nadia Eghbal s’intéresse aux enjeux de la standardisation et de la démocratisation de l’open source – notamment à l’inflation parfois anarchique du nombre de projets et de contributeurs : pour elle, l’enjeu est d’éviter que l’écosystème numérique ne se transforme en un fragile château de cartes.

Pourquoi les problèmes de support des infrastructures numériques sont de plus en plus pressants

Traduction Framalang : goudron, Penguin, serici, goofy, Rozmador, xi, Lumibd, teromene, xi, Opsylac, et 3 anonymes.

L’open source, grâce à ses points forts cités plus tôt dans ce rapport, est rapidement en train de devenir un standard pour les projets d’infrastructure numérique et dans le développement logiciel en général. Black Duck, une entreprise qui aide ses clients à gérer des programmes open source, dirige une enquête annuelle qui interroge les entreprises sur leur utilisation de l’open source. (Cette enquête est l’un des rares projets de banque de données qui existe sur le sujet.) Dans leur étude de 2015, 78% des 1300 entreprises interrogées déclarent que les logiciels qu’elles ont créés pour leurs clients sont construits grâce à l’open source, soit presque le double du chiffre de 2010.

L’open source a vu sa popularité s’accroître de manière impressionnante ces cinq dernières années, pas seulement grâce à ses avantages évidents pour les développeurs et les consommateurs, mais également grâce à de nouveaux outils qui rendent la collaboration plus facile. Pour comprendre pourquoi les infrastructures numériques rencontrent des problèmes de support grandissants, nous devons comprendre la manière dont le développement de logiciels open source prolifère.

Github, un espace standardisé pour collaborer sur du code

On n’insistera jamais trop sur le rôle clé de GitHub dans la diffusion de l’open source auprès d’une audience grand public. L’open source a beau exister depuis près de 30 ans, jusqu’en 2008, contribuer à des projets open source n’était pas si facile. Le développeur motivé devait d’abord découvrir qui était le mainteneur du projet, trouver une manière de le contacter, puis proposer ses changements en utilisant le format choisi par le mainteneur (par exemple une liste courriel ou un forum). GitHub a standardisé ces méthodes de communication : les mainteneurs sont listés de façon transparente sur la page du projet, et les discussions sur les changements proposés ont lieu sur la plate-forme GitHub.

GitHub a aussi créé un vocabulaire qui est désormais standard parmi les contributeurs à l’open source, tels que la « pull request » (où un développeur soumet à l’examen de ses pairs une modification à un projet), et changé le sens du terme « fork » (historiquement, créer une copie d’un projet et le modifier pour le transformer en un nouveau projet) [littéralement « fork » signifie « bifurcation », Ndt.]. Avant GitHub, forker un projet revenait à dire qu’il y avait un différend irréconciliable au sujet de la direction qu’un projet devrait prendre. Forker était considéré comme une action grave : si un groupe de développeurs décidait de forker un projet, cela signifiait qu’il se scindait en deux factions idéologiques. Forker était aussi utilisé pour développer un nouveau projet qui pouvait avoir une utilisation radicalement différente du projet initial.

Ce type de « fork de projet » existe toujours, mais GitHub a décidé d’utiliser le terme « fork » pour encourager à davantage d’activité sur sa plate-forme. Un fork GitHub, contrairement à un fork de projet, est une copie temporaire d’un projet sur laquelle on effectue des modifications, et qui est généralement re-fusionnée au projet. Le fork en tant que pratique quotidienne sur GitHub a ajouté une connotation positive, légère au terme : c’est l’idée de prendre l’idée de quelqu’un et de l’améliorer.

GitHub a aussi aidé à standardiser l’utilisation d’un système de contrôle de version appelé Git. Les systèmes de contrôle de versions sont un outil qui permet de garder une trace de chaque contribution apportée sur un morceau de code précis. Par exemple, si le Développeur 1 et le Développeur 2 corrigent différentes parties du même code en même temps, enregistrer chaque changement dans un système de contrôle de version permet de faire en sorte que leurs changements n’entrent pas en conflit. Il existe plusieurs systèmes de contrôle de versions, par exemple Apache Subversion et Concurrent Versions System (CVS). Avant GitHub, Git était un système de contrôle de version assez méconnu. En 2010, Subversion était utilisé dans 60% des projets logiciels, contre 11%pour Git.

C’est Linus Torvalds, le créateur de Linux, qui a conçu Git en 2005. Son intention était de mettre à disposition un outil à la fois plus efficace et plus rapide, qui permette de gérer de multiples contributions apportées par de nombreux participants. Git était vraiment différent des systèmes de contrôle de version précédents, et donc pas forcément facile à adopter, mais son workflow décentralisé a résolu un vrai problème pour les développeurs.

GitHub a fourni une interface utilisateur intuitive pour les projets open source qui utilisent Git, ce qui rend l’apprentissage plus facile pour les développeurs. Plus les développeurs utilisent GitHub, plus cela les incite à continuer d’utiliser Git. Aujourd’hui, en 2016, Git est utilisé par 38% des projets de logiciels, tandis que la part de Subversion est tombée à 47%. Bien que Subversion soit encore le système de contrôle de version le plus populaire, son usage décline. L’adoption généralisée de Git rend plus facile pour un développeur la démarche de se joindre à un projet sur GitHub, car la méthode pour faire des modifications et pour les communiquer est la même sur tous les projets. Apprendre à contribuer sur un seul des projets vous permet d’acquérir les compétences pour contribuer à des centaines d’autres. Ce n’était pas le cas avant GitHub, où des systèmes de contrôle de versions différents étaient utilisés pour chaque projet.

Enfin, GitHub a créé un espace sociabilité, qui permet de discuter et de tisser des liens au-delà de la stricte collaboration sur du code. La plate-forme est devenue de facto une sorte de communauté pour les développeurs, qui l’utilisent pour communiquer ensemble et exposer leur travail. Ils peuvent y démontrer leur influence et présenter un portfolio de leur travail comme jamais auparavant.

Les usages de GitHub sont un reflet de son ascension vertigineuse. En 2011 il n’y avait que 2 millions de dépôts (« repository »). Aujourd’hui, GitHub a 14 millions d’utilisateurs et plus de 35 millions de dépôts (ce qui inclut aussi les dépôts forkés, le compte des dépôts uniques est plutôt aux environs de 17 millions.) Brian Doll, de chez GitHub, a noté qu’il a fallu 4 ans pour atteindre le million de dépôts, mais que passer de neuf millions à dix millions n’a pris que 48 jours.

En comparaison, SourceForge, la plate-forme qui était la plus populaire pour héberger du code open source avant l’apparition de GitHub, avait 150 000 projets en 2008. Environ 18 000 projets étaient actifs.

Stack Overflow, un espace standard pour s’entraider sur du code

L’une des autres plate-formes importantes de l’open source est Stack Overflow, un site de question/réponse populaire parmi les développeurs, créé en 2008 par Jeff Atwood (développeur déjà mentionné précédemment) et par le blogueur Joel Spolsky. En Avril 2014, Stack Overflow avait plus de 4 millions d’utilisateurs enregistrés et plus de 11 millions de questions résolues (à noter qu’il n’est pas nécessaire de s’enregistrer pour voir les questions ou leurs réponses).

Stack Overflow est devenu de facto une plate-forme d’entraide pour les développeurs, qui peuvent poser des questions de programmation, trouver des réponses à des problèmes de code spécifiques, ou juste échanger des conseils sur la meilleure façon de créer un aspect précis d’un logiciel. On pourrait définir la plate-forme comme un « support client » participatif pour les développeurs à travers le monde. Même si Stack Overflow n’est pas un endroit où l’on écrit directement du code, c’est un outil de collaboration essentiel pour les développeurs individuels, qui facilite grandement la résolution de problèmes et permet de coder plus efficacement. Cela signifie qu’un développeur individuel est capable de produire plus, en moins de temps, ce qui améliore le rendement global. Stack Overflow a également permis à certains utilisateurs d’apprendre de nouveaux concepts de développement (ou même de s’initier au code tout court), et a rendu le codage plus facile et plus accessible à tous.

Tendances macro dans un paysage en mutation constante

La popularité hors-normes de l’open source a amené à des changements significatifs dans la manière dont les développeurs d’aujourd’hui parlent, pensent et collaborent sur des logiciels.

Premièrement, les attentes et exigences en termes de licences ont changé, reflétant un monde qui considère désormais l’open source comme une norme, et pas l’exception : un triomphe sur l’univers propriétaire des années 1980. Les politiques de GitHub et de Stack Overflow reflètent toutes deux cette réalité.

Dès le départ, Stack Overflow a choisi d’utiliser une licence Creative Commons appelée CC-BY-SA pour tous les contenus postés sur son site. La licence était cependant limitante, car elle requérait des utilisateurs qu’ils mentionnent l’auteur de chaque morceau de code qu’ils utilisaient, et qu’ils placent leurs propres contributions sous la même licence.

Beaucoup d’utilisateurs choisissaient d’ignorer la licence ou n’étaient même pas au courant de ses restrictions, mais pour les développeurs travaillant avec des contraintes plus strictes (par exemple dans le cadre d’une entreprise), elle rendait Stack Overflow compliqué à utiliser. S’ils postaient une question demandant de l’aide sur leur code, et qu’une personne extérieure réglait le problème, alors légalement, ils devaient attribuer le code à cette personne.

En conséquence, les dirigeants de Stack Overflow ont annoncé leur volonté de déplacer toutes les nouvelles contributions de code sous la Licence MIT, qui est une licence open source comportant moins de restrictions. En Avril 2016, ils débattent encore activement et sollicitent des retours de leur communauté pour déterminer le meilleur moyen de mettre en œuvre un système plus permissif. Cette démarche est un encouragement à la fois pour la popularité de Stack Overflow et pour la prolifération de l’open source en général. Qu’un développeur travaillant dans une grosse entreprise de logiciel puisse légalement inclure le code d’une personne complètement extérieure dans un produit pour lequel il est rémunéré est en effet un accomplissement pour l’open source.

A l’inverse, GitHub fit initialement le choix de ne pas attribuer de licence par défaut aux projets postés sur sa plateforme, peut-être par crainte que cela ne freine son adoption par les utilisateurs et sa croissance. Ainsi, les projets postés sur GitHub accordent le droit de consulter et de forker le projet, mais sont à part ça sous copyright, sauf si le développeur spécifie qu’il s’agit d’une licence open source.

En 2013, GitHub décida enfin de prendre davantage position sur la question des licences, avec notamment la création et la promotion d’un micro-site, choosealicense.com (« choisissez-une-licence »), pour aider les utilisateurs à choisir une licence pour leur projet. Ils encouragent aussi désormais leurs utilisateurs à choisir une licence parmi une liste d’options au moment de créer un nouveau « repository » (dépôt).

Ce qui est intéressant, cependant, c’est que la plupart des développeurs ne se préoccupaient pas de la question des licences : soit ignoraient que leurs projets « open source » n’étaient pas légalement protégés, soit ils s’en fichaient. Une étude informelle réalisée en 2013 par le Software Freedom Law Center (Centre du Droit de la Liberté des Logiciels) sur un échantillon de 1,6 million de dépôts GitHub révéla que seuls 15% d’entre eux avaient spécifié une licence. Aussi, les entretiens avec des développeurs réalisés pour ce rapport suggèrent que beaucoup se fichent de spécifier une licence, ou se disent que si quelqu’un demande, ils pourront toujours en ajouter une plus tard.

Ce manque d’intérêt pour les licences a amené James Governor, cofondateur de la firme d’analyse de développeurs Red Monk, à constater en 2012 que « les jeunes dévs aujourd’hui font du POSS – Post open source software. Envoie chier les licences et la gestion, contribue juste à GitHub » [en anglais « commit to GitHub » signifie littéralement « s’engager dans GitHub » mais fait également référence à la commande « commit » qui permet de valider les modifications apportées à un projet, NdT.]. En d’autres termes, faire de l’information ouverte par défaut est devenu une telle évidence culturelle aujourd’hui que les développeurs ne s’imaginent plus faire les choses autrement – un contexte bien différent de celui des rebelles politisés du logiciel libre des années 1980. Ce retournement des valeurs, quoi qu’inspirant au niveau global, peut cependant amener à des complications légales pour les individus quand leurs projets gagnent en popularité ou sont utilisés à des fins commerciales.

Mais, en rendant le travail collaboratif sur le code aussi facile et standardisé, l’open source se retrouve aux prises avec une série d’externalités perverses.

L’open source a rendu le codage plus facile et plus accessible au monde. Cette accessibilité accrue, à son tour, a engendré une nouvelle catégorie de développeurs, moins expérimentés, mais qui savent comment utiliser les composants préfabriqués par d’autres pour construire ce dont ils ont besoin.

En 2012, Jeff Atwood, cofondateur de Stack Overflow, rédigea un article de blog intitulé ironiquement « Pitié n’apprenez pas à coder », où il se plaint de la mode des stages et des écoles de code. Tout en se félicitant du désir des personnes non-techniciennes de comprendre le code d’un point de vue conceptuel, Atwood met en garde contre l’idée qu’« introduire parmi la main-d’œuvre ces codeurs naïfs, novices, voire même-pas-vraiment-sûrs-d’aimer-ce-truc-de-programmeur, ait vraiment des effets positifs pour le monde ».

Dans ces circonstances, le modèle de développement de l’open source change de visage. Avant l’ascension de GitHub, il y avait moins de projets open source. Les développeurs étaient donc un groupe plus petit, mais en moyenne plus expérimenté : ceux qui utilisaient du code partagé par d’autres étaient susceptibles d’être également ceux qui contribuent en retour.

Aujourd’hui, l’intense développement de l’éducation au code implique que de nombreux développeurs inexpérimentés inondent le marché. Cette dernière génération de développeurs novices emprunte du code libre pour écrire ce dont elle a besoin, mais elle est rarement capable, en retour, d’apporter des contributions substantielles aux projets. Beaucoup sont également habitués à se considérer comme des « utilisateurs » de projets open source, davantage que comme les membres d’une communauté. Les outils open source étant désormais plus standardisés et faciles à utiliser, il est bien plus simple aujourd’hui pour un néophyte de débarquer sur un forum GitHub et d’y faire un commentaire désobligeant ou une requête exigeante – ce qui épuise et exaspère les mainteneurs.

Cette évolution démographique a aussi conduit à un réseau de logiciels bien plus fragmenté, avec de nombreux développeurs qui publient de nouveaux projets et qui créent un réseau embrouillé d’interdépendances. Se qualifiant lui-même de « développeur-pie en rémission » [« pie » est un surnom pour les développeurs-opportunistes, d’après le nom de l’oiseau, la pie réputée voleuse, NdT], Drew Hamlett a écrit en janvier 2016 un post de blog devenu très populaire intitulé « Le triste état du développement web ». L’article traite de l’évolution du développement web, se référant spécifiquement à l’écosystème Node.js :

« Les gens qui sont restés dans la communauté Node ont sans aucun doute créé l’écosystème le plus techniquement compliqué [sic] qui ait jamais existé. Personne n’arrive à y créer une bibliothèque qui fasse quoi que ce soit. Chaque projet qui émerge est encore plus ambitieux que le précédent… mais personne ne construit rien qui fonctionne concrètement. Je ne comprends vraiment pas. La seule explication que j’ai trouvée, c’est que les gens sont juste continuellement en train d’écrire et de réécrire en boucle des applis Node.js. »

Aujourd’hui, il y a tellement de projets qui s’élaborent et se publient qu’il est tout simplement impossible pour chacun d’eux de développer une communauté suffisamment importante et viable, avec des contributeurs réguliers qui discuteraient avec passion des modifications à apporter lors de débats approfondis sur des listes courriels. Au lieu de cela, beaucoup de projets sont maintenus par une ou deux personnes seulement, alors même que la demande des utilisateurs pour ces projets peut excéder le travail nécessaire à leur simple maintenance.

GitHub a rendu simples la création et la contribution à de nouveaux projets. Cela a été une bénédiction pour l’écosystème open source, car les projets se développent plus rapidement. Mais cela peut aussi parfois tourner à la malédiction pour les mainteneurs de projets, car davantage de personnes peuvent facilement signaler des problèmes ou réclamer de nouvelles fonctionnalités, sans pour autant contribuer elles-mêmes en retour. Ces interactions superficielles ne font qu’alourdir la charge de travail des mainteneurs, dont on attend qu’ils répondent à une quantité croissante de requêtes.

Il ne serait pas déraisonnable d’affirmer qu’un monde « post-open source » implique une réflexion non seulement autour des licences, ainsi que James Governor l’exprimait dans son commentaire originel, mais aussi autour du processus de développement lui-même.

Noah Kantrowitz, développeur Python de longue date et membre de la Python Software Foundation, a résumé ce changement dans un post de blog souvent cité :

« Dans les débuts du mouvement open source, il y avait assez peu de projets, et en général, la plupart des gens qui utilisaient un projet y contribuaient en retour d’une façon ou d’une autre. Ces deux choses ont changé à un point difficilement mesurable.
[…] Alors même que nous allons de plus en plus vers des outils de niche, il devient difficile de justifier l’investissement en temps requis pour devenir contributeur. « Combler son propre besoin » est toujours une excellente motivation, mais il est difficile de construire un écosystème là-dessus.
L’autre problème est le déséquilibre de plus en plus important entre producteurs et consommateurs. Avant, cela s’équilibrait à peu près. Tout le monde investissait du temps et des efforts dans les Communs et tout le monde en récoltait les bénéfices. Ces temps-ci, très peu de personnes font cet effort et la grande majorité ne fait que bénéficier du travail de ceux qui s’impliquent.
Ce déséquilibre s’est tellement enraciné qu’il est presque impensable pour une entreprise de rendre (en temps ou en argent) ne serait-ce qu’une petite fraction de la valeur qu’elle dérive des Communs. »

Cela ne veut pas dire qu’il n’existe plus de grands projets open source avec des communautés de contributeurs fortes (Node.js, dont on parlera plus tard dans ce rapport, est un exemple de projet qui est parvenu à ce statut.) Cela signifie qu’à côté de ces réussites, il y a une nouvelle catégorie de projets qui est défavorisée par les normes et les attentes actuelles de l’open source, et que le comportement qui dérive de ces nouvelles normes affecte même des projets plus gros et plus anciens.

Hynek Schlawack, Fellow de la Python Software Foundation et contributeur sur des projets d’infrastructure Python, exprime ses craintes au sujet d’un futur où il y aurait une demande plus forte, mais seulement une poignée de contributeurs solides :

« Ce qui me frustre le plus, c’est que nous n’avons jamais eu autant de développeurs Python et aussi peu de contributions de haute qualité. […] Dès que des développeurs clefs comme Armin Ronacher ralentissent leur travail, la communauté toute entière le ressent aussitôt. Le jour où Paul Kehrer arrête de travailler sur PyCA, on est très mal. Si Hawkowl arrête son travail de portage, Twisted ne sera jamais sur Python 3 et Git.
La communauté est en train de se faire saigner par des personnes qui créent plus de travail qu’elles n’en fournissent. […] En ce moment, tout le monde bénéficie de ce qui a été construit mais la situation se détériore à cause du manque de financements et de contributions. Ça m’inquiète, parce Python est peut-être très populaire en ce moment mais une fois que les conséquences se feront sentir, les opportunistes partiront aussi vite qu’ils étaient arrivés. »

Pour la plupart des développeurs, il n’y a guère que 5 ans peut-être que l’open source est devenu populaire. La large communauté des concepteurs de logiciel débat rarement de la pérennité à long terme de l’open source, et n’a parfois même pas conscience du problème. Avec l’explosion du nombre de nouveaux développeurs qui utilisent du code partagé sans contribuer en retour, nous construisons des palaces sur une infrastructure en ruines.

Une question épineuse pour les projets libres et open source est leur maintenance à long terme, et bien évidemment les ressources, tant financières qu’humaines, que l’on peut y consacrer. Tel est le sujet qu’aborde ce nouveau chapitre de l’ouvrage de Nadia Eghbal Des routes et des ponts que le groupe Framalang vous traduit semaine après semaine (si vous avez raté les épisodes précédents)

Elle examine ici une série de cas de figures en fonction de l’origine de l’origine projet.

Comment les projets d’infrastructure numérique sont-ils gérés et maintenus ?

TraductionFramalang : Diane, Penguin, Asta, Rozmador, Lumibd, jum-s, goofy, salade, AFS, Théo

Nous avons établi que les infrastructures numériques sont aussi nécessaires à la société moderne que le sont les infrastructures physiques. Bien qu’elles ne soient pas sujettes aux coûts élevés et aux obstacles politiques auxquels sont confrontées ces dernières, leur nature décentralisée les rend cependant plus difficiles à cerner. Sans une autorité centrale, comment les projets open source trouvent-ils les ressources dont ils ont besoin ?

En un mot, la réponse est différente pour chaque projet. Cependant, on peut identifier plusieurs lieux d’où ces projets peuvent  émaner : au sein d’une entreprise, via une startup, de développeurs individuels ou collaborant en communauté.

Au sein d’une entreprise

Parfois, le projet commence au sein d’une entreprise. Voici quelques exemples qui illustrent par quels moyens variés un projet open source peut être soutenu par les ressources d’une entreprise :

Go, le nouveau langage de programmation évoqué précédemment, a été développé au sein de Google en 2007 par les ingénieurs Robert Griesemer, Rob Pike, et Ken Thompson, pour qui la création de Go était une expérimentation. Go est open source et accepte les contributions de la communauté dans son ensemble. Cependant, ses principaux mainteneurs sont employés à plein temps par Google pour travailler sur le langage.

React est une nouvelle bibliothèque JavaScript dont la popularité grandit de jour en jour.
React a été créée par Jordan Walke, ingénieur logiciel chez Facebook, pour un usage interne sur le fil d’actualités Facebook. Un employé d’Instagram (qui est une filiale de Facebook) a également souhaité utiliser React, et finalement, React a été placée en open source, deux ans après son développement initial.
Facebook a dédié une équipe d’ingénieurs à la maintenance du projet, mais React accepte aussi les contributions de la communauté publique des développeurs.

Swift, le langage de programmation utilisé pour iOS, OS X et les autres projets d’Apple, est un exemple de projet qui n’a été placé en open source que récemment. Swift a été développé par Apple en interne pendant quatre ans et publié en tant que langage propriétaire en 2014. Les développeurs pouvaient utiliser Swift pour écrire des programmes pour les appareils d’Apple, mais ne pouvaient pas contribuer au développement du cœur du langage. En 2015, Swift a été rendu open source sous la licence Apache 2.0.

Pour une entreprise, les incitations à maintenir un projet open source sont nombreuses. Ouvrir un projet au public peut signifier moins de travail pour l’entreprise, grâce essentiellement aux améliorations de la collaboration de masse.
Cela stimule la bonne volonté et l’intérêt des développeurs, qui peuvent alors être incités à utiliser d’autres ressources de l’entreprise pour construire leurs projets.

Disposer d’une communauté active de programmeurs crée un vivier de talents à recruter. Et parfois, l’ouverture du code d’un projet aide une entreprise à renforcer sa base d’utilisateurs et sa marque, ou même à l’emporter sur la concurrence. Plus une entreprise peut capter de parts de marché, même à travers des outils qu’elle distribue gratuitement, plus elle devient influente. Ce n’est pas très différent du concept commercial de « produit d’appel ».

Même quand un projet est créé en interne, s’il est open source, alors il peut être librement utilisé ou modifié selon les termes d’une licence libre, et n’est pas considéré comme relevant de la propriété intellectuelle de l’entreprise au sens traditionnel du terme. De nombreux projets d’entreprise utilisent des licences libres standard qui sont considérées comme acceptables par la communauté des développeurs telles que les licences Apache 2.0 ou BSD. Cependant, dans certains cas, les entreprises ajoutent leurs propres clauses. La licence de React, par exemple, comporte une clause additionnelle qui pourrait potentiellement créer des conflits de revendications de brevet avec les utilisateurs de React.

En conséquence, certaines entreprises et individus sont réticents à utiliser React, et cette décision est fréquemment décrite comme un exemple de conflit avec les principes de l’open source.

Via une startup

Certains projets d’infrastructures empruntent la voie traditionnelle de la startup, ce qui inclut des financements en capital-risque. Voici quelques exemples :
Docker, qui est peut-être l’exemple contemporain le plus connu, aide les applications logicielles à fonctionner à l’intérieur d’un conteneur. (Les conteneurs procurent un environnement propre et ordonné pour les applications logicielles, ce qui permet de les faire fonctionner plus facilement partout). Docker est né en tant que projet interne chez dotCloud, une société de Plate-forme en tant que service (ou PaaS, pour  platform as a service en anglais), mais le projet est devenu si populaire que ses fondateurs ont décidé d’en faire la principale activité de l’entreprise. Le projet Docker a été placé en open source en 2013. Docker a collecté 180 millions de dollars, avec une valeur estimée à plus d’1 milliard de dollars.

Leur modèle économique repose sur du support technique, des projets privés et des services. Les revenus de Docker pour l’année 2014 ne dépassaient pas 10 millions de dollars.

Npm est un gestionnaire de paquets sorti en 2010 pour aider les développeurs de Node.js à partager et à gérer leurs projets. Npm a collecté près de 11 millions de dollars de financements depuis 2014 de la part de True Ventures et de Bessemer Ventures, entre autres. Leur modèle économique se concentre sur des fonctionnalités payantes en faveur de la vie privée et de la sécurité.

Meteor est un framework JavaScript publié pour la première fois en 2012. Il a bénéficié d’un programme d’incubation au sein de Y Combinator, un prestigieux accélérateur de startups qui a également été l’incubateur d’entreprises comme AirBnB et Dropbox. À ce jour, Meteor a reçu plus de 30 millions de dollars de financements de la part de firmes comme Andreessen Horowitz ou Matrix Partners. Le modèle économique de Meteor se base sur une plateforme d’entreprise nommée Galaxy, sortie en Octobre 2015, qui permet de faire fonctionner et de gérer les applications Meteor.

L’approche basée sur le capital-risque est relativement nouvelle, et se développe rapidement.
Lightspeed Venture Partners a constaté qu’entre 2010 et 2015, les sociétés de capital-risque ont investi plus de 4 milliards de dollars dans des entreprises open source, soit dix fois plus que sur les cinq années précédentes.

Le recours aux fonds de capital-risque pour soutenir les projets open source a été accueilli avec scepticisme par les développeurs (et même par certains acteurs du capital-risque eux-mêmes), du fait de l’absence de modèles économiques ou de revenus prévisibles pour justifier les estimations. Steve Klabnik, un mainteneur du langage Rust, explique le soudain intérêt des capital-risqueurs pour le financement de l’open source :

« Je suis un investisseur en capital-risque. J’ai besoin qu’un grand nombre d’entreprises existent pour gagner de l’argent… J’ai besoin que les coûts soient bas et les profits élevés. Pour cela, il me faut un écosystème de logiciels open source en bonne santé. Donc je fais quoi? … Les investisseurs en capital-risque sont en train de prendre conscience de tout ça, et ils commencent à investir dans les infrastructures. […]
Par bien des aspects, le matériel open source est un produit d’appel, pour que tu deviennes accro…puis tu l’utilises pour tout, même pour ton code propriétaire. C’est une très bonne stratégie commerciale, mais cela place GitHub au centre de ce nouvel univers. Donc pour des raisons similaires, a16z a besoin que GitHub soit génial, pour servir de tremplin à chacun des écosystèmes open source qui existeront à l’avenir… Et a16z a suffisamment d’argent pour en «gaspiller » en finançant un projet sur lequel ils ne récupéreront pas de bénéfices directs, parce qu’ils sont suffisamment intelligents pour investir une partie de leurs fonds dans le développement de l’écosystème. »

GitHub, créé en 2008, est une plateforme de partage/stockage de code, disponible en mode public ou privé, doté d’un environnement ergonomique. Il héberge de nombreux projets open source populaires et, surtout, il est devenu l’épicentre culturel de la croissance explosive de l’open source (dont nous parlerons plus loin dans ce rapport).
GitHub n’a reçu aucun capital-risque avant 2012, quatre ans après sa création. Avant cette date, GitHub était une entreprise rentable. Depuis 2012, GitHub a reçu au total 350 millions de dollars de financements en capital-risque.

Andreessen Horowitz (alias a16z), la firme d’investissement aux 4 millards de dollars qui a fourni l’essentiel du capital de leur première levée de fonds de 100 millions de dollars, a déclaré qu’il s’agissait là de l’investissement le plus important qu’elle ait jamais fait jusqu’alors.
En d’autres termes, la théorie de Steve Klabnik est que les sociétés de capital-risque qui investissent dans les infrastructures open source promeuvent ces plateformes en tant que « produit d’appel », même quand il n’y a pas de modèle économique viable ou de rentabilité à en tirer, parce que cela permet de faire croître l’ensemble de l’écosystème. Plus GitHub a de ressources, plus l’open source est florissant. Plus l’open source est florissant, et mieux se portent les startups. À lui seul, l’intérêt que portent les sociétés d’investissement à l’open source, particulièrement quand on considère l’absence de véritable retour financier, est une preuve du rôle-clé que joue l’open source dans l’écosystème plus large des startups.
Par ailleurs, il est important de noter que la plateforme GitHub en elle-même n’est pas un projet open source, et n’est donc pas un exemple de capital-risque finançant directement l’open source. GitHub est une plateforme à code propriétaire qui héberge des projets open source. C’est un sujet controversé pour certains contributeurs open source.

Par des personnes ou un groupe de personnes

Enfin, de nombreux projets d’infrastructures numériques sont intégralement développés et maintenus par des développeurs indépendants ou des communautés de développeurs. Voici quelques exemples :

Python, un langage de programmation, a été développé et publié par un informaticien, Guido van Rossum, en 1991.
Van Rossum déclarait qu’il « était à la recherche d’un projet de programmation « passe-temps », qui [le] tiendrait occupé pendant la semaine de Noël. »
Le projet a décollé, et Python est désormais considéré comme l’un des langages de programmation les plus populaires de nos jours.

Van Rossum reste le principal auteur de Python (aussi connu parmi les développeurs sous le nom de « dictateur bienveillant à vie » et il est actuellement employé par Dropbox, dont les logiciels reposent fortement sur Python.

Python est en partie géré par la Python Software Foundation (NdT: Fondation du logiciel Python), créée en 2001, qui bénéficie de nombreux sponsors commerciaux, parmi lesquel Intel, HP et Google.

RubyGems est un gestionnaire de paquets qui facilite la distribution de programmes et de bibliothèques associés au langage de programmation Ruby.
C’est une pièce essentielle de l’infrastructure pour tout développeur Ruby. Parmi les sites web utilisant Ruby, on peut citer par exemple Hulu, AirBnB et Bloomberg. RubyGems a été créé en 2003 et est géré par une communauté de développeurs. Certains travaux de développement sont financés par Ruby Together, une fondation qui accepte les dons d’entreprises et de particuliers.

Twisted, une bibliothèque Python, fut créée en 2002 par un programmeur nommé Glyph Lefkowitz. Depuis lors,  son usage s’est largement répandu auprès d’individus et d’organisations, parmi lesquelles Lucasfilm et la NASA.
Twisted continue d’être géré par un groupe de volontaires. Le projet est soutenu par des dons corporatifs/commerciaux et individuels ; Lefkowitz en reste l’architecte principal et gagne sa vie en proposant ses services de consultant.

Comme le montrent tous ces exemples, les projets open source peuvent provenir de pratiquement n’importe où. Ce qui est en général considéré comme une bonne chose. Cela signifie que les projets utiles ont le plus de chances de réussir, car ils évitent d’une part les effets de mode futiles inhérents aux startups, et d’autre part la bureaucratie propre aux gouvernements. La nature décentralisée de l’infrastructure numérique renforce également les valeurs de démocratie et d’ouverture d’Internet, qui permet en principe à chacun de créer le prochain super projet, qu’il soit une entreprise ou un individu.
D’un autre côté, un grand nombre de projets utiles proviendront de développeurs indépendants qui se trouveront tout à coup à la tête d’un projet à succès, et qui devront prendre des décisions cruciales pour son avenir. Une étude de 2015 menée par l’Université fédérale de Minas Gerai au Brésil a examiné 133 des projets les plus activement utilisés sur Github, parmi les langages de programmation, et a découvert que 64 % d’entre eux, presque les deux tiers, dépendaient pour leur survie d’un ou deux développeurs seulement.

Bien qu’il puisse y avoir une longue traîne de contributeurs occasionnels ou ponctuels pour de nombreux projets, les responsabilités principales de la gestion du projet ne reposent que sur un très petit nombre d’individus.

Coordonner des communautés internationales de contributeurs aux avis arrêtés, tout en gérant les attentes d’entreprises classées au Fortune 500 qui utilisent votre projet, voilà des tâches qui seraient des défis pour n’importe qui. Il est impressionnant de constater combien de projets ont déjà été accomplis de cette manière. Ces tâches sont particulièrement difficiles dans un contexte où les développeurs manquent de modèles clairement établis, mais aussi de soutien institutionnel pour mener ce travail à bien. Au cours d’interviews menées pour ce rapport, beaucoup de développeurs se sont plaints en privé qu’ils n’avaient aucune idée de qui ils pouvaient solliciter pour avoir de l’aide, et qu’ils préféreraient « juste coder ».

Pourquoi continuent-ils à le faire ? La suite de ce rapport se concentrera sur pourquoi et comment les contributeurs de l’open source maintiennent des projets à grande échelle, et sur les raisons pour lesquelles c’est important pour nous tous.

Le kit du semeur d’idées est le site d’une communicante française qui propose des conseils et des ressources sous licence libre, avec en plus une démarche éco-responsable. Le tout pour pas un radis.

Salut Nadine ! Nous avons découvert ton initiative pour permettre à toutes et tous de « cultiver l’éco-communication ». Ça veut dire quoi ?

Salut ! Alors éco-communiquer signifie « communiquer efficacement tout en réduisant son impact sur l’environnement ». Il s’agit de faire de l’éco-conception : prendre en compte l’environnement dès la conception de sa stratégie. Pour le terme de « cultiver », il y a une petit histoire ! Avant de lancer Cultive ta com’ et son kit du semeur d’idées, j’étais graphiste sous logiciels libres et je faisais de l’éco-conception de documents sous le nom de « Graine de pixel ». J’ai voulu faire évoluer mon projet vers la sensibilisation tout en gardant une partie de cette identité.

C’est vraiment important de concevoir sa comm’ en pensant aux économies d’encre ? Que penses-tu des extensions comme print-edit qui permettent d’économiser du papier et de l’encre en éliminant le superflu ?

Je trouve que cette extension est une très bonne initiative. Il est tout de même important de se demander au préalable s’il est possible d’éviter l’impression depuis le web. La meilleure façon d’économiser de l’encre c’est de ne pas en utiliser, non ?

Elles sont chouettes et claires tes fiches, mais on n’y trouve pas de liens vers des ressources ou exemples ou prolongements, c’est délibéré ?

Merci beaucoup, c’est très important pour moi qu’elles soient claires. Non ce n’est pas du tout délibéré, je dois ajouter les sources et des liens externes sur les mises à jour du Kit. Il est en mutation perpétuelle, rien n’est jamais définitif et je tiens à approfondir les fiches avec le temps.

Et tu fais tout ça avec des logiciels libres ? Sous licence libre ?

Oui, je ne travaille que sous logiciels libres (et sous OS libre). il était évident pour moi de proposer le kit sous licence libre… même si je n’ai pas encore choisi lesquelles. Il m’arrive de me perdre dans le méandre des licences. Les images et les exercices de PAO sont sous licence ArtLibre 1.3. Je vais probablement mettre les textes sous licence Creative Commons 4.0 – partage dans les mêmes conditions.

Hum, j’ai corrigé quelques bricoles mineures sur une fiche dans ton github. Tu es sûre de ne pas vouloir passer sur (frama-)gitlab ?

J’avoue ne pas y avoir pensé (mea culpa). Dans mon esprit, Github s’adressait surtout à un public de développeurs en informatique. Je me suis créée un compte il y a quelques mois pour tester l’hébergement de site statique et j’ai commencé peu à peu à comprendre son fonctionnement… En découvrant l’utilisation faite par David Revoy pour la traduction de ses bandes dessinées Pepper&Carrot, je me suis dit que je pourrai en faire autant avec le contenu du kit sur mon compte vide. Étant tout neuf, je peux le migrer aisément sur Framagit. Je vais m’en occuper. 🙂

Ça n’a pas été trop difficile de convaincre les internautes, pour le financement ?

J’ai répondu à l’appel à projet UP ! d’Auvergne Nouveau Monde en partenariat avec Ulule. J’ai pu profiter, comme une dizaine d’autres auvergnats, d’une formation au crowdfunding et d’une visibilité dans la presse régionale durant ma campagne. J’ai également communiqué sur les réseaux sociaux et notamment sur ma page Diaspora où j’ai trouvé une communauté prête à me soutenir dans cette aventure ! Merci encore à tous !

J’ai vu que ton site est hébergé par une société locale, on l’entendrait presque miauler ! C’est important, pour toi ?

Oui c’est très important. Je tâtonne sur les questions du numérique responsable. Je ne m’attendais pas à trouver un hébergeur local ! Et j’espère pouvoir entendre miauler prochainement vers chez moi !

D’ailleurs, tu revendiques ta localisation en province. C’est pas trop compliqué de faire de la comm depuis Clermont-Ferrand ? Les Parigots ne te regardent pas de haut ?
Je ne revendique pas ma localisation, mon projet est simplement basé là où je vis. Je pense qu’aujourd’hui il est possible d’implanter un projet numérique depuis n’importe où.

Tu vas sortir des infos régulièrement, sur ce site ?
J’espère pouvoir faire des mises à jours mensuelles avec de nouveaux contenus sur les fiches, de nouveaux thèmes et exercices.

Et alors, comment vois-tu la suite ? Tu prépares un nouveau financement participatif ou tu as d’autres idées pour faire vivre le projet ? Autrement dit, est-ce que tu as réfléchi au modèle économique ?
Le kit me tient à cœur et je souhaite le compléter et continuer à le faire évoluer. Je ne prépare pas de nouvelle campagne de financement, les mises à jour du kit seront faites sur mon temps libre. Mon modèle économique est basé sur le site de cultive-ta.com où je propose un accompagnement personnalisé en stratégie de communication responsable.

Il paraît que Pouhiou t’a fait du gringue pour que tu viennes nous donner un coup de main. On va se revoir, alors ? Tu peux en dire plus aux lecteurices du blog ?
Oui j’espère bien ! Pouhiou n’a pas eu besoin d’insister longtemps, haha ! Je propose un coup de patte de graphiste sous logiciels libres. Maintenant que mon kit est en ligne, j’espère avoir plus de temps pour pouvoir me rendre utile. Je vais aider Framabook dans la création des couvertures des futurs ouvrages aussi. Il y a de la place pour tous ceux qui souhaitent donner un coup de main et selon les compétences de chacun… et ça c’est chouette !

Et ton mot de la fin ?
Miaou ! Merci infiniment à Framasoft pour cet échange autour du kit !

Lorsqu’une personnalité notoire du Libre comme Carl Chenet s’attaque avec pertinence à la tendance massive du « tous sur GitHub » et égratigne la communauté du Libre pour son immobilisme (et même sa paresse !), Framasoft trouve que c’est une bonne occasion de lui donner un peu plus de voix encore.

S’adressant principalement aux développeurs, il pointe les dangers d’un service centralisateur, privateur, qui uniformise les pratiques en étouffant les alternatives. Ça ne vous rappelle rien ? Oui, les mêmes écueils contre lesquels nous vous mettons en garde dans notre campagne degooglisons ! Ajoutons que nous avons déjà basculé sur GitLab, comme le recommande Carl, dès 2014 et mis à la disposition de tous depuis le mois de mars 2015 notre GitLab qui héberge à ce jour 3017 projets, 2071 utilisateurs inscrits, 242 groupes.

Nous reprenons ici avec son autorisation le récent billet de Carl qui a déjà suscité d’intéressants commentaires et en provoquera probablement d’autres ici même.

Le danger GitHub

Un article de Carl Chenet d’abord publié sur son blog

Alors que le projet CPython (implémentation historique du projet Python) a annoncé son passage chez GitHub (avec quelques restrictions, nous reviendrons là-dessus), il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre.

Des voix critiques s’élèvent régulièrement contre les risques encourus par l’utilisation de GitHub par les projets du Logiciel Libre. Et pourtant l’engouement autour de la forge collaborative de la startup Californienne à l’octocat continue de grandir.

L’octocat, mascotte de GitHub

Ressentis à tort ou à raison comme simples à utiliser, efficaces à l’utilisation quotidienne, proposant des fonctionnalités pertinentes pour le travail collaboratif en entreprise ou dans le cadre d’un projet de Logiciel Libre, s’interconnectant aujourd’hui à de très nombreux services d’intégration continue, les services offerts par GitHub ont pris une place considérable dans l’ingénierie logicielle ces dernières années.

Quelles sont ces critiques et sont-elles justifiées ? Nous proposons de les exposer dans un premier temps dans la suite de cet article avant de peser le pour ou contre de leur validité.

1. Points critiques

1.1 La centralisation

L’application GitHub appartient et est gérée par une entité unique, à savoir GitHub, inc, société américaine. On comprend donc rapidement qu’une seule société commerciale de droit américain gère l’accessibilité à la majorité des codes sources des applications du Logiciel Libre, ce qui représente un problème pour les groupes utilisant un code source qui devient indisponible, pour une raison politique ou technique.

De plus cette centralisation pose un problème supplémentaire : de par sa taille, ayant atteint une masse critique, elle s’auto-alimente. Les personnes n’utilisant pas GitHub, volontairement ou non, s’isolent de celles qui l’utilisent, repoussées peu à peu dans une minorité silencieuse. Avec l’effet de mode, on n’est pas « dans le coup » quand on n’utilise pas GitHub, phénomène que l’on rencontre également et même devenu typique des réseaux sociaux propriétaires (Facebook, Twitter, Instagram).

1.2 Un logiciel privateur

Lorsque vous interagissez avec GitHub, vous utilisez un logiciel privateur, dont le code source n’est pas accessible et qui ne fonctionne peut-être pas comme vous le pensez. Cela peut apparaître gênant à plusieurs points de vue. Idéologique tout d’abord, mais peut-être et avant tout pratique. Dans le cas de GitHub on y pousse du code que nous contrôlons hors de leur interface. On y communique également des informations personnelles (profil, interactions avec GitHub). Et surtout un outil crucial propriétaire fourni par GitHub qui s’impose aux projets qui décident de passer chez la société américaine : le gestionnaire de suivi de bugs.

1.3 L’uniformisation

Travailler via l’interface GitHub est considéré par beaucoup comme simple et intuitif. De très nombreuses sociétés utilisent maintenant GitHub comme dépôt de sources et il est courant qu’un développeur quittant une société retrouve le cadre de travail des outils GitHub en travaillant pour une autre société. Cette fréquence de l’utilisation de GitHub dans l’activité de développeur du Libre aujourd’hui participe à l’uniformisation du cadre de travail dudit développeur.

L’uniforme évoque l’armée, ici l’armée des clones

2. Validité des points critiques

2.1 Les critiques de la centralisation

Comme dit précédemment, GitHub est aujourd’hui la plus grande concentration de code source du Logiciel Libre. Cela fait de lui une cible privilégiée.  Des attaques massives par déni de service ont eu lieu en mars et août 2015. De même, une panne le 15 décembre 2015 a entraîné l’indisponibilité de 5% des dépôts. Idem le 15 novembre. Et il s’agit des incidents récents déclarés par les équipes de GitHub elles-mêmes. On peut imaginer un taux d’indisponibilité moyen des services bien supérieur.

L’excuse n°1 des programmeurs pour se lâcher sans scrupules : « GitHub est en panne »

— Hé, au boulot les gars ! — Github est en panne !

— Ah bon, continuez alors.

2.2 Les critiques relatives à l’usage d’un logiciel privateur

Cette critique, avant tout idéologique, se heurte à la conception même que chacun des membres de la communauté se fait du Logiciel Libre, et en particulier d’un critère : contaminant ou non, qu’on résume en général par GPL versus MIT/BSD.

Les défenseurs du Logiciel Libre contaminant vont être gênés d’utiliser un logiciel propriétaire car ce dernier ne devrait pas exister. Il doit être assimilé, pour citer Star Trek,  car il est une boîte noire communicante, qui met en danger la vie privée, détourne nos usages à des fins commerciales, gêne ou contraint la liberté de jouir entièrement de ce qu’on a acquis, etc.

Les tenants d’une totale liberté sont moins complexés dans leur utilisation des logiciels privateurs puisqu’ils acceptent l’existence desdits logiciels privateurs au nom d’une liberté sans restriction. Ils acceptent même que le code qu’ils développent aboutissent dans ces logiciels, ce qui arrive bien plus souvent qu’on ne le croit, voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD. On peut donc voir dans cette aile de la communauté du Logiciel Libre une totale sérénité à utiliser GitHub. Et ce qui est cohérent vis-à-vis de l’idéologie soutenue. Si vous êtes déjà allé au Fosdem, un coup d’œil dans l’amphithéâtre Janson permet de se rendre compte de la présence massive de portables Apple tournant sous MacOSX.

FreeBSD, principal projet des BSD sous licence MIT

Mais au-delà de cet aspect idéologique pur et pour recentrer sur l’infrastructure de GitHub elle-même, l’utilisation du gestionnaire de suivi de bugs de GitHub pose un problème incontournable. Les rapports de bugs sont la mémoire des projets du Logiciel Libre. Il constitue le point d’entrée des nouveaux contributeurs, des demandes de fonctionnalités, des rapports de bugs et donc la mémoire, l’histoire du projet qui ne peut se limiter au code seul. Il est courant de tomber sur des rapports de bugs lorsque vous copiez/collez votre message d’erreur dans un moteur de recherche. Mémoire précieuse non seulement pour le projet lui-même, mais aussi pour ses utilisateurs actuels et à venir.

GitHub propose d’extraire les rapports de bugs via son API, certes, mais combien de projets anticiperont une éventuelle défaillance de GitHub  ou un retournement de situation arrêtant brusquement le service ? Très peu à mon avis. Et comment migrer vers un nouveau système de suivi de bugs les données fournies par GitHub ?

L’exemple de l’utilitaire de gestion de listes de choses à faire (TODO list) Astrid, racheté par Yahoo! il y a quelques années reste un très bon exemple de service ayant grandi rapidement, largement utilisé et qui a fermé du jour au lendemain, proposant pendant quelques semaines seulement d’extraire ses données. Et il s’agissait là d’un simple gestionnaire de tâches à faire. Le même problème chez GitHub serait dramatiquement plus difficile à gérer pour de très nombreux projets, si on leur laisse la possibilité de le gérer. Certes le code reste disponible et pourra continuer de vivre ailleurs, mais la mémoire du projet sera perdue, alors qu’un projet comme Debian approche aujourd’hui les 800 000 rapports de bugs. Une vraie mine d’or d’informations sur les problèmes rencontrés, les demandes de fonctionnalités et le suivi de ces demandes. Les développeurs du projet CPython passant chez GitHub ont anticipé ce problème et ne vont pas utiliser le système de suivi de bugs de GitHub.

Debian, l’un des principaux projets du Logiciel Libre

avec autour de 1000 contributeurs officiels

2.3 L’uniformisation

La communauté du Logiciel Libre oscille sans cesse entre un besoin de normes afin de réduire le travail nécessaire pour l’interopérabilité et l’attrait de la nouveauté, caractérisée par l’intrinsèque besoin de différence vis-à-vis de l’existant.

GitHub a popularisé l’utilisation de Git, magnifique outil qui aujourd’hui touche des métiers bien différents des programmeurs auxquels il était initialement lié. Peu à peu, tel un rouleau compresseur, Git a pris une place si centrale que considérer l’usage d’un autre gestionnaire de sources est quasiment impossible aujourd’hui, particulièrement en entreprise, malgré l’existence de belles alternatives qui n’ont malheureusement pas le vent en poupe, comme Mercurial.

Un projet de Logiciel Libre qui naît aujourd’hui, c’est un dépôt Git sur GitHub avec un README.md pour sommairement le décrire. Les autres voies sont totalement ostracisées. Et quelle est la punition pour celui qui désobéit ? Peu ou pas de contributeurs potentiels. Il semble très difficile de pousser aujourd’hui le contributeur potentiel à se lancer dans l’apprentissage d’un nouveau gestionnaire de sources ET une nouvelle forge pour chaque projet auquel on veut contribuer. Un effort que fournissait pourtant tout un chacun il y a quelques années.

Et c’est bien dommage car GitHub, en proposant une expérience unique et originale à ses utilisateurs, taille à grands coups de machette dans les champs des possibles. Alors oui, sûrement que Git est aujourd’hui le meilleur des système de gestion de versions. Mais ça n’est pas grâce à cette domination sans partage qu’un autre pourra émerger. Et cela permet à GitHub d’initier à Git les nouveaux arrivants dans le développement  à un ensemble de fonctionnalités très restreint, sans commune mesure avec la puissance de l’outil Git lui-même.

Centralisation, uniformisation, logiciels privateurs et bientôt… fainéantise ?

Le combat contre la centralisation est une part importante de l’idéologie du Logiciel Libre car elle accroît le pouvoir de ceux qui sont chargés de cette centralisation et qui la contrôlent sur ceux qui la subissent. L’aversion à l’uniformisation née du combat contre les grandes firmes du logiciel souhaitant imposer leur vision fermée et commerciale du monde du logiciel a longtemps nourri la recherche réelle d’innovation et le développement d’alternatives brillantes. Comme nous l’avons décrit, une partie de la communauté du Libre s’est construit en opposition aux logiciels privateurs, les considérant comme dangereux. L’autre partie, sans vouloir leur disparition, a quand même choisi un modèle de développement à l’opposé de celui des logiciels privateurs, en tout cas à l’époque car les deux mondes sont devenus de plus en plus poreux au cours des dernières années.

L’effet GitHub est donc délétère au point de vue des effets qu’il entraîne : la centralisation,  l’uniformisation, l’utilisation de logiciels privateurs comme leur système de gestion de version, au minimum. Mais la récente affaire de la lettre « Cher GitHub… » met en avant un dernier effet, totalement inattendu de mon point de vue : la fainéantise. Pour les personnes passées à côté de cette affaire, il s’agit d’une lettre de réclamations d’un nombre très important de représentants de différents projets du Logiciel Libre qui réclament à l’équipe de GitHub d’entendre leurs doléances, apparemment ignorées depuis des années, et d’implémenter de nouvelles fonctionnalités demandées.

Mais depuis quand des projets du Logiciel Libre qui se heurtent depuis des années à un mur tentent-ils de faire pleurer le mur et n’implémentent pas la solution qui leur manquent ? Lorsque Torvald a subi l’affaire Bitkeeper et que l’équipe de développement du noyau Linux n’a plus eu l’autorisation d’utiliser leur gestionnaire de versions, Linus a mis au point Git. Doit-on rappeler que l’impossibilité d’utiliser un outil ou le manque de fonctionnalités d’un programme est le moteur principal de la recherche d’alternatives et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capables de programmer devraient avoir ce réflexe. Vous n’aimez pas ce qu’offre GitHub ? Optez pour Gitlab. Vous n’aimez pas Gitlab ? Améliorez-le ou recodez-le.

Logo de Gitlab, une alternative possible à GitHub

en choisissant la version Communauté

Que l’on soit bien d’accord, je ne dis pas que tout programmeur du Libre qui fait face à un mur doit coder une alternative. En restant réaliste, nous avons tous nos priorités et certains de nous aiment dormir la nuit (moi le premier). Mais lorsqu’on voit 1340 signataires de cette lettre à GitHub et parmi lesquels des représentants de très grands projets du Logiciel Libre, il me paraît évident que les volontés et l’énergie pour coder une alternative existe. Peut-être d’ailleurs apparaîtra-t-elle suite à cette lettre, ce serait le meilleur dénouement possible à cette affaire.

Finalement, l’utilisation de GitHub suit cette tendance de massification de l’utilisation d’Internet. Comme aujourd’hui les utilisateurs d’Internet sont aspirés dans des réseaux sociaux massivement centralisés comme Facebook et Twitter, le monde des développeurs suit logiquement cette tendance avec GitHub. Même si une frange importante des développeurs a été sensibilisée aux dangers de ce type d’organisation privée et centralisée, la communauté entière a été absorbée dans un mouvement de centralisation et d’uniformisation. Le service offert est utile, gratuit ou à un coût correct selon les fonctionnalités désirées, confortable à utiliser et fonctionne la plupart du temps. Pourquoi chercherions-nous plus loin ? Peut-être parce que d’autres en profitent et profitent de nous pendant que nous sommes distraits et installés dans notre confort ? La communauté du Logiciel Libre semble pour le moment bien assoupie.

Le « lion » du Libre assoupi devant la cheminée (allégorie)

Liens :

• Source de l’article : blog de Carl Chenet
• Notre GitLab ouvert à tous (pour sortir de Github)

C’est officiel : Google Code, qui permettait aux développeurs de déposer, partager, et collaborer sur du code logiciel (libre ou pas), va bientôt fermer ses portes.

Il va donc rejoindre le mémorial des projets sabordés par Google.

La raison la plus probable, c’est que GitHub (une plateforme concurrente) attire bien plus de développeurs, et donc de code, que Google Code. Non seulement grâce à une interface plus intuitive, mais aussi par une facilité bien plus grande pour les développeurs à collaborer ensemble (plus on est de fous, plus il y a de code produit).

D’ailleurs, Google ne s’en cache pas et propose, dans le courrier annonçant la clôture prochaine du service, un outil permettant de transférer votre projet logiciel de Google Code à GitHub.

Quelles réflexions cela devrait-il nous inspirer ?

D’abord, que malgré sa puissance financière massive, Google n’est pas systématiquement le meilleur dans son domaine. Et qu’une « petite » entreprise (267 salariés, tout de même) comme GitHub, Inc, peut amener le géant de Mountain View à fermer un service qui hébergeait malgré tout plus de 250 000 projets logiciels.

Cela pourrait paraître pour une bonne nouvelle : la diversité et l’innovation resteraient possibles ! L’argent n’achèterait pas tout ! Skynet (pardon, Googleternet) n’aurait pas encore un pouvoir absolu !

Ensuite, que Google continue à être une entreprise qui ne s’entête pas. Si un projet fonctionne, tant mieux (et autant devenir le meilleur au monde dessus). Sinon, tant pis, c’est que le marché n’est pas mûr, que les technologies utilisées n’étaient pas les bonnes, que les équipes n’étaient pas les meilleures, ou que les utilisateurs n’étaient pas prêts. Google Plus étant pour l’instant l’exception à la règle.

Cependant, peut-on considérer cela comme un fait positif ?

Pas vraiment. Car cela concentre encore un peu plus les utilisateurs sur GitHub.

Alors certes, il est toujours possible de quitter GitHub, de reprendre son code et d’aller le déposer ailleurs. Mais si tous les développeurs sont sur GitHub, il y aura une forme de pression sociale à continuer d’utiliser cette plateforme.

Donc, cela soulève deux questions.

1. Les développeurs de logiciels libres ont-il intérêt à utiliser GitHub ?

La plateforme est extrêmement pratique, confortable et performante, il faut le reconnaître.

Mais le code de GitHub n’est pas libre.

Ce manque de transparence peut avoir des conséquences importantes.

D’abord, GitHub pourrait peu à peu se garnir de publicités, tel un sapin de Noël. Cela serait désagréable, mais pas bloquant.

Ensuite, GitHub pourrait modifier les données hébergées sans les accords des auteurs. Par exemple, intégrer des fichiers (publicitaires, malveillants, etc.) dans les .zip téléchargés par millions quotidiennement sur la plateforme. Ca serait peut-être se tirer une balle dans le pied pour la société, mais cela n’a pas empêché Sourceforge, alors plus importante forge logicielle mondiale, de le faire. Et rien que le fait que GitHub puisse le faire est inquiétant et devrait interroger tout développeur de logiciel libre.

Enfin, nous, utilisateurs, n’avons pas le pouvoir sur les choix technologiques ou ergonomiques de GitHub. Si, demain, GitHub décide de modifier l’interface de telle ou telle façon, les développeurs seront tels des consommateurs dans un supermarché qui changerait ses produits d’allées, ou qui supprimerait tel ou tel produit : pris au piège de la volonté d’un tiers.

2. Quel est le modèle économique de GitHub ?

Certes, GitHub est une boite « sympa » (comme l’était Google à ses débuts). L’entreprise est toujours en mode start-up : largement financée par des fonds levés auprès de sociétés de capital-risque. Sans cet argent, GitHub serait déficitaire. Or, si des entreprises comme Andreessen Horowitz (fondées par des anciens de<span lang="en" Netscape) investissent 100 millions de dollars dans GitHub, elles espèrent probablement un retour sur investissement.

Or, la valeur de GitHub (en dehors de l’argent gagné sur les comptes privés), repose essentiellement sur le nombre de comptes utilisateurs (plus de 9 millions) et la quantité de code hébergé (plus de 20 millions de projets). Un peu comme la valeur de Facebook est largement déterminée par leur milliard d’utilisateurs.

GitHub étant en forte croissance, l’entreprise n’est pas à vendre. Cependant, rien ne permet d’affirmer qu’une fois une masse critique atteinte (et l’argent frais épuisé), GitHub ne se déclarera pas ouverte à un rachat. Et là, nul doute que Google pourrait être intéressé.

Alors, que faire ?

S’autohéberger.

Participer à la résistance à ce mouvement centripète de « centralisation du web » ou les plus gros services deviennent toujours plus gros, mettant ainsi en péril — sous prétexte de confort — l’équilibre d’un Internet qui pourrait bien finir aux mains de quelques entreprises.

Mais autohéberger son code, ce n’est pas toujours simple, notamment lorsqu’il faut interagir avec de nombreux développeurs.

De nombreuses forges logicielles, aux codes sources libres, existent déjà. Citons par exemple (liste non exhaustive) :

• Savannah (maintenu par la Free Software Foundation)
• Gna! (fork de Savannah, mais qui ne propose pas git)
• les amis de TuxFamilly
• la forge de l’Adullact, dédiée aux projets des collectivités
• Gitlab.com (dont on va vous reparler plus bas 😉 )
• Gitorious (qui vient de se faire racheter par… Gitlab, fait plutôt rare dans le milieu du logiciel libre)

Et Framasoft, dans tout ça ?

Comme vous le savez (ou non), Framasoft s’est fixé comme objectif – en toute modestie ! – de « Dégoogliser Internet ». Oui, rien que ça.

Il s’agit d’un programme sur 3 ans, visant à :

• sensibiliser le grand public sur les questions de centralisation du Web, de concentration/exploitation des données, et de vie privée ;
• démontrer que notre meilleure chance de résistance se trouve dans le logiciel libre, en mettant en place une trentaine d’alternatives à des services fermés (Google Docs, Skype, Doodle, etc.), suivant une charte de services Libres, Éthiques, Décentralisés et Solidaires ;
• essaimer, en encourageant et en accompagnant les structures qui, après avoir testé les services Frama*, souhaiteraient les mettre en place pour elles-mêmes (en clair, nous ne souhaitons pas recentraliser le Web « chez » Framasoft, mais bien aider les gens qui le souhaitent à s’auto-héberger).

Google Code, et plus largement GitHub, rentrent bien dans les critères de services au code source fermé, qui cherchent à attirer un maximum d’utilisateurs.

Dans notre démarche « Quitter Google », nous annoncions en mai 2014 que nous avions mis en place notre propre forge, basée sur le projet libre Gitlab.

Announcing : git.framasoft.org

Aujourd’hui, nous sommes heureux de pouvoir vous annoncer que la forge git.framasoft.org est désormais ouverte à tous.

Comme pour nos autres services (Framapad, Framadate, etc), nous vous encourageons à tester le service, sur lequel nous prenons les engagements de notre charte L.E.D.S.

Et, si ce dernier vous plaît, nous vous encourageons à… le quitter ! Par exemple en installant gitlab (nous proposerons dans les jours qui viennent une documentation en français, comme pour nos autres services).

https://git.framasoft.org permet la création de 42 dépôts maximum par compte (encore une fois, si vous avez besoin de plus, songez sérieusement à vous auto-héberger). En revanche, petits plus par rapport à GitHub, vous pouvez parfaitement créer des dépôts privés.

Par ailleurs, il est possible de « mirrorer » automatiquement vos dépôts sur GitHub : vous continuez à « engraisser la bête », mais vous êtes déjà moins dépendant, et vous conservez une visibilité auprès des presque 10 millions d’inscrits sur GitHub. Votre dépôt sur notre Gitlab est automatiquement poussé sur votre dépôt Github. C’est d’ailleurs la solution retenue par Framasoft, qui dispose toujours d’un compte GitHub, alors que les développements sont réalisés sur notre forge.

Pour mettre en place ce « mirroring », il suffit de nous écrire un petit mail sur http://contact.framasoft.org/, nous vous expliquerons la marche à suivre et nous nous occuperons du reste.

Comme on dit chez nous : « La route est longue, mais la voie est libre… »

• Accédez à la forge logicielle de Framasoft

EDIT : notre administrateur système vient de réparer la page d’import des dépôts Github sur notre Gitlab (accessible depuis l’interface de création de projet). Il n’a jamais été aussi facile de passer sur une solution libre !

Le titre de ce billet vient de l’expression « Eating your own dog food » signifiant qu’il est bon de suivre ses propres recommandations.

Crédit photo : Birhanb – CC by-sa
Crédit illustration : Framasoft Campagne 2013 – Simon Gee Giraudot – CC by-sa

Lors de notre campagne de dons 2013, nous avions proclamé « Moins de Google et plus de Libre ». En effet, cela fait un bout de temps que l’actualité tourne autour du géant du Web pour son côté « Don’t be Evil [mais un peu (beaucoup ?) quand même] » et que nous vous encourageons à vous méfier de lui et de ses semblables… sans que nous suivions pour autant nos propres recommandations !

Google Analytics pour nos statistiques, Google Groups pour nos listes de diffusion, Google Mail pour nos adresses mail associatives, etc. La liste est longue et nous accable chaque jour un peu plus. Nous ne comptons d’ailleurs plus le nombre de fois où l’on nous reproche — avec raison — d’utiliser les services Google.
Le cas de Google Groups est particulièrement parlant : si on peut s’abonner librement à une liste de diffusion de ce service, le faire sans disposer d’un compte Google relève du parcours du combattant.

Google nous a séduit à l’époque par sa facilité d’emploi, ses nombreux outils disponibles et son slogan que nous aimions croire. Notre croissance a été peut-être un peu rapide et nous avons choisi des solutions de facilité.
Il faut cependant noter, à notre décharge, que ces solutions présentaient au moins le mérite d’être gratuites, et ne nécessitaient aucune maintenance particulière si ce n’était un peu d’organisation. Pouvoir “compter” sur les serveurs de la Firme était clairement une question de confort et de disponibilité de main d’œuvre. Il faut aussi se souvenir qu’il y a peu de techniciens purs et durs dans nos rangs.

Google devient chaque jour de plus en plus omniprésent, intrusif et laissant de moins en moins de choix à ses utilisateurs, comme l’obligation récente d’avoir un compte Google+ pour commenter des vidéos Youtube. Sans parler de sa soumission à la NSA (#Prism, #Snowden), Voilà qui n’est vraiment pas dans l’esprit de Framasoft 🙁

Mais en 2014, nous nous libérons de nos chaînes ! Tel le fils prodigue, nous revenons à la maison. Nous quittons cette cathédrale si confortable pour rajouter de nouvelles pièces à notre auberge espagnole, ce joyeux bazar.

Au menu de cette grande campagne de migration, nous remplacerons :

• Google Mail par Bluemind ;
• Google Groups par Sympa ;
• Google Docs par un mélange d’Etherpad, d’Owncloud et peut-être aussi de WebODF ;
• Google Analytics par Piwik ;
• Github par GitLab (parce qu’il n’y a pas que Google qui n’est pas libre)^[1].

Le calendrier de cette migration, s’il n’est pas gravé dans le marbre est tout de même plus ou moins déjà écrit.
Ainsi, le 1er février, nous aurons effectué la migration de nos boîtes mail vers notre propre infrastructure.

Chacune des étapes de notre libération fera l’objet d’un billet dédié pour vous tenir au courant de nos avancées et — pourquoi pas ? — vous donner envie de suivre notre exemple.

Cette année sera aussi celle du grand ménage dans nos serveurs. Un grand bric-à-brac monté au fil des années, pas forcément maintenu comme il faudrait, mélangeant les applications critiques et moins critiques. Nous allons nous doter d’outils nous permettant une plus grande souplesse d’utilisation, comme Ganeti^[2] pour monter une infrastructure virtualisée.
Cette souplesse nous permettra par exemple d’expérimenter facilement de nouveaux services à vous proposer (Sneak preview) tout en réduisant le temps — relativement conséquent aujourd’hui — à consacrer à la maintenance de notre infrastructure.

Nous tenions à vous l’annoncer non seulement dans un souci de transparence, mais aussi pour vous permettre de suivre et vous montrer — au fil de nos avancées — comment nous répondons à notre défi « Quitter Google ». Peut-être cela pourra-t-il inspirer votre entreprise, votre administration, votre association… à se lancer ce même défi.

C’est en grande partie grâce à vos dons que nous pouvons dégager le temps et trouver les talents pour atteindre cet objectif. Si vous trouvez la démarche intéressante, n’hésitez pas à nous soutenir afin de nous permettre de continuer notre action.

L’équipe Framasoft

« Oui, nous venons de rendre open source la dernière année de notre vie : tout le code, le graphisme, et la musique de CodeCombat ! » Ainsi s’exprime NIck sur le blog de ce jeu particulier puisqu’on y fait l’apprentissage sérieux mais ludique du JavaScript.

Une libération exemplaire dans la mesure où, comme cela arrive trop souvent, ça n’est pas qu’un effet d’annonce. Tout a en effet été minutieusement préparé sur GitHub pour faciliter la tâche des futurs contributeurs.

Longue vie à CodeCombat…

Nous avons tout mis en open source

We’ve Open-Sourced Everything

Nick – 6 janvier 2014 – CodeCombat Blog
(Traduction : Monsieur Tino, Théotix, goofy, audionuma, baba, Sphinx, Asta, moedium, vvision + anonymes)

CodeCombat est un jeu de programmation pour apprendre à coder ; un concours de codage multijoueurs dans une arène pour affûter vos compétences ; une startup lancée avec un financement par Y-combinator ; et depuis le week-end dernier, le plus important projet open source utilisant Coffeescript et une porte d’entrée géniale pour l’open source et le développement de jeux. Que vous soyez un programmeur novice désireux de vous faire une idée de ce qu’est ce Github ou un gourou de l’open source qui cherche dans quoi mordre à belles dents, regardez notre Github et rejoignez plus de deux cents Grands Mages de CodeCombat dans la construction du meilleur jeu de programmation qui soit.

Oui, nous venons de rendre open source, sous les licences MIT et Creative Commons CC By-SA, la dernière année de notre vie : tout le code, le graphisme, et la musique de CodeCombat !

« Attendez un peu, vous êtes une startup à but lucratif, et vous venez de libérer tout votre code ? Mais vous êtes fou ? »

Nan ! Fermer son code source est peut être le choix fait par pratiquement toutes les startups et studios de jeux vidéo, mais nous pensons que c’est une convention qui doit être repensée. CodeCombat est déjà un projet communautaire, avec des centaines de joueurs se portant volontaires pour créer des niveaux, écrire de la documentation, aider les débutants, faire des tests et même traduire le jeu en dix-sept langues ! Maintenant les programmeurs peuvent se joindre à la fête eux aussi.

Notre noble mission est de vous apprendre à coder. Nous avons plus de 9000 niveaux de difficulté qui vous feront gravir tous les échelons, de simple novice à sorcier du code comme Fabrice Bellard, alors pourquoi ne pas vous lancer dans un projet open source accessible aux débutants pour continuer à apprendre ? Nous ne nous contentons pas de balancer du code en vrac — nous avons travaillé dur pour qu’il soit simple de contribuer. Vous n’avez pas besoin de connaître git, vous n’avez pas besoin d’avoir quoi que ce soit d’installé, et vous n’avez même pas besoin de savoir coder pour aider à résoudre certains problèmes sur notre Github.

Ou alors, si vous êtes intéressés par les compilateurs, les langages de programmation, les simulations physiques, la géométrie, le design, l’expérience utilisateur, l’intelligence artificielle, l’optimisation des performances, le traitement audio, les jeux de stratégie en temps réel, les jeux de rôle, l’internationalisation et la localisation, la sécurité, le dessin vectoriel 2.5D, le développement piloté par les tests, les bases de données, les discussions en visioconférence, les environnements de développement intégrés, ou les débogueurs, vous adorerez hacker ce projet. Avec des technologies sympas, des problèmes détaillés, une documentation complète pour les développeurs, un script convivial pour mettre en place l’environnement de développement et l’équipe de CodeCombat prête à vous aider à mettre en place vos idées, c’est le jeu open source parfait pour débuter. Ne soyez pas timide !

Nous avons besoin de votre aide. Il y a tout juste deux mois, nous avons lancé notre bêta. Il y a deux semaines, nous avons écrit un billet sur les 180 000 enfants qui avaient joué avec CodeCombat cette semaine-là. Il y a une semaine, nous avons essayé un niveau difficile, un défi pour développeur, et presque 10 000 programmeurs chevronnés y ont joué — nous n’avons pas encore fini de répondre à tous ceux qui ont battu notre propre algorithme à plate couture et voulaient qu’on les aide à trouver un boulot de programmeur. CodeCombat devient un phénomène qui dépasse largement le domaine d’un simple jeu. Si vous souhaitez écrire du code qui montrera à des millions de joueurs à quel point ça peut être sympa de programmer, alors cliquez sur ce lien et devenez un Grand Mage. Nous avons vraiment hâte de voir ce que vous avez réalisé.

Vous voulez aider d’une autre façon ? Rejoignez nous en tant qu’Artisan créateur de niveaux, Aventurier bêta-testeur, Scribe de documentation, Diplomate traducteur, Ambassadeur serviable ou Conseiller expert.

Y aurait-il moins de 5000 développeurs libres sur tout le continent africain (4527 pour être plus précis) ?

C’est ce qu’on peut lire sur cette intéressante carte interactive intitulée GitHub Africa Users. Leur auteurs (non africains) ont en effet collecté, en mars dernier, les données des utilisateurs de la plateforme qui avaient renseigné leur localisation (et uniquement ceux-ci) en nous présentant cela à l’aide de MapBox.

A partir de là un certain nombre de questions se posent pour nuancer ce chiffre :

• Est-ce les utilisateurs africains de GitHub se localisent moins que les autres ?
• Est-ce qu’un utilisateur de GitHub est nécessairement un développeur qui fait du libre ?
• Est-ce que les développeurs libres africains utilisent GitHub ?
• Est-ce que les développeurs libres africains voudraient utiliser GitHub mais en sont empêchés à cause de la faiblesse de leur connexion à Internet ?
• Combien y a-t-il de développeurs non libres en Afrique ?

Il n’empêche que cela reste tout de même inquiétant.

Qu’en pensez-vous ?