Depuis que j’ai commencé ce blog, je me suis dit que je devais parler des outils que j’utilisais afin de faire connaître les raisons de leur choix et pourquoi pas, vous convaincre de les essayer. Je ne l’avais toujours pas fait ou juste évoqué en passant mais aujourd’hui je passe à l’action avec un outil que j’utilise quasiment au quotidien : Zim.
Avant de l’utiliser, j’avais toujours des fichiers texte à droite à gauche que je créais dans un bête éditeur. Il y avait un peu de tout : des idées, des brouillons d’articles, des listes, des notes, des astuces, ...
Alors à un moment j’ai décidé de chercher un logiciel me permettant de regrouper tout ça. J’ai essayé plusieurs usines à gaz ou trucs trop lourds pour gérer ce genre de choses qui ne m’ont pas convaincu. D’un autre côté, je voulais aussi éviter le systèmes de post-it un peu trop simplistes qui en mettent partout sans être faciles à organiser.
C’est pourquoi j’ai choisi Zim qui est un bon compromis entre les deux : une grande fenêtre centrale permettant de se concentrer sur le texte à taper, une barre d’outil très sobre et une colonne à gauche que l’on peut organiser en pages et sous-pages selon les catégories que l’on veut utiliser. Je l’utilise souvent sur la moitié de l’écran avec de l’autre un navigateur ou un terminal par exemple selon les besoins.
Le but premier de ce logiciel est de créer des wiki avec des renvois entre les pages que l’on crée, je dois dire que je ne l’ai jamais utilisé pour ça mais pour plusieurs autres fonctions proposées comme une todo list avec des cases à cocher par exemple pour les livres que je veux lire et dont je veux garder une trace de lecture (date et appréciation).
La mise en forme du texte est minimale mais largement suffisante pour faire des textes avec des titres de chapitres, des listes et quelques effets de caractère de base. Encore une fois, on est entre le trop lourd et complet traitement de texte et le trop basique éditeur de texte.
Autre gros avantage, la sauvegarde se fait régulièrement au cours de l’ajout du texte. On peut donc laisser l’outil ouvert, y jeter ses idées et liens tout en farfouillant sur le net et tout est sauvegardé au fur et à mesure.
Seul inconvénient à cela, lorsque l’on sélectionne tout ou partie du texte pour faire un copier-coller par exemple, il faut éviter de taper accidentellement sur une touche car la sélection est supprimée et sauvegardée assez rapidement et les retours en arrière sont limités (c’est juste que j’ai eu le coup avec un ordi qui pète parfois les plomb et se met à faire des lignes de œœœœœœœœœœœœœ, ce qui m’a bousillé tout un brouillon de plusieurs pages).
J’utilise donc maintenant cet outil pour toutes mes notes, idées et brouillons de billet (comme celui-ci) et certaines pages sont permanentes (listes de commandes bash, guide de migration perso avec les logiciels et config utilisées, listes de documents à emprunter en médiathèques, ...) et d’autres temporaires avec des idées ou des brouillons de textes que j’ai à écrire. Je l’utilise même pour les premiers jets avant de mettre des écrits en forme dans un traitement de texte pour me consacrer entièrement au fond plutôt qu’à la forme.
L’avantage aussi, c’est que tous ces textes centralisés et accessibles sans avoir à naviguer dans les dossiers sont tous au format texte donc très légers et facilement réutilisables à partir d’un autre logiciel. Je fais des synchronisations régulières du répertoire où ils sont stockés sur un périphérique de stockage (type clé USB) afin de toujours les avoirs au cas où.
Il est aussi possible d’exporter chaque page ou ensemble de pages en html (forcément pour un wiki) mais aussi en markdown ou en LaTeX pour les amateurs ; l’outil ne permet par contre pas de faire de l’impression directe, ce qui peut se comprendre car ce n’est pas son but. N’oublions pas l’outil bien utile de correction d’orthographe pour éliminer les plus grosses fautes. Enfin, il est disponible pour toutes les distributions et même pour ceux qui sont sur des OS non libres. Bien entendu, il est sous licence GPL.
Bon, voilà, il y a sans doute plein d’autres fonctionnalités à découvrir avec ce genre d’outil. J’ai simplement essayé de vous présenter l’utilisation que j’en fait et peut-être aurez-vous l’envie de le tester ou de me dire ce que vous en pensez.
Nous avons régulièrement des mails de lecteurs qui souhaitent installer l’OS d’Apple sur la Raspberry Pi et qui se retrouvent bloqués.
Jusqu’à présent, nous ne pouvions que leur indiquer qu’OS X ne fonctionnait pas sur la Raspberry Pi. En cause, l’architecture ARM 32 bits du processeur de la framboise.
Cependant, nous avons reçus des informations directement des services de communication d’Apple qui viennent changer la donne !
Apple vise la domotique et compte passer par la Raspberry Pi
La semaine dernière, nous avons eu la chance (comme Framboise 314 notamment) d’être contactés par mail par la branche française des services de communication d’Apple « en raison de notre forte implication dans l’environnement technique français autour de la Raspberry Pi ».
Pour faire simple, Apple pense que la Raspberry Pi sera un pierre angulaire de la domotique dans les années à venir, un marché dont la marque à la pomme compte bien s’emparer, comme ils l’ont fait lors des débuts des smartphones (quand on sait combien ça leur a rapporté, on comprend bien pourquoi).
Après Microsoft avec Windows 10, c’est donc au tour d’Apple de rendre son système OS X compatible avec la Raspberry Pi !
Apple suit Microsoft et change sa politique concernant le libre
Le problème, c’est que ces dernières années, Apple ne s’est pas fait une très bonne réputation auprès de la communauté libriste, laquelle fait vivre tout l’écosystème de la Raspberry Pi.
Depuis quelques temps les deux acteurs majeurs des systèmes d’exploitations grand public, Microsoft avec Windows et Apple avec OS X, changent un peu de position concernant le libre en général et notamment Linux.
Le géant de Cupertino cherche donc à se rapprocher de la communauté et veut pour cela passer par les blogueurs spécialisés, lesquels disposent de plus de légitimité auprès du public (et soyons honnête, lesquels seront disponibles pour faire du support de qualité et accompagner les utilisateurs, ce qu’Apple ne semble pas très décidé à faire).
La nouvelle Raspberry Pi 3 permet à Apple de faire tourner OS X
Après discussion avec Apple, nous avons appris que la firme s’intéressait fortement à la Raspberry Pi depuis à peu près 8 mois, mais qu’ils étaient jusqu’à présent limités par l’architecture ARM 32 bits du processeur.
Cependant, avec la nouvelle Raspberry Pi 3, la situation a changé. En effet, le nouveau processeur 64 bits de la Raspberry Pi se rapproche davantage de l’A7 utilisé par Apple pour certains produits mobiles.
Ce changement a permis à Apple de travailler sur une adaptation de Mac OS X sur la Raspberry Pi 3.
Et bonne nouvelle, il ne s’agirait pas d’un simple iOS, mais bien d’une version adaptée à la Raspberry Pi (probablement plus légère donc) de OS X. Nous avons pu obtenir un premier aperçu du produit (encore en plein développement) qui montre ce que devrait donner l’interface (il n’est pas certain que le produit final aura effectivement cette apparence, de notre côté nous pensons qu’Apple la modifiera probablement pour diminuer les ressources graphiques, mais il ne s’agit que d’une simple supposition de notre part).
Une date non officielle mais un système d’exploitation gratuit
Vous l’avez compris, si Apple nous a contacté, c’est évidemment pour être sûr que nous parlerions d’OS X lors de sa sortie sur la Raspberry Pi, mais également pour être certain que nous assurerions une certaine forme de support auprès de la communauté.
Nous n’avons pas pu obtenir de date officielle quant au lancement du produit, celui-ci n’étant pas encore totalement finalisé, mais en insistant sur le fait que nous avions besoin d’au moins une estimation, nous avons tout de même pu obtenir une indication.
Une annonce officielle devrait donc être faite au début du mois de juillet pour présenter au public le produit dans sa forme quasi finie, et une première bêta publique devrait être disponible courant septembre !
En revanche, Apple a été très clair sur un point, ce nouveau système d’exploitation sera gratuit ! Une stratégie qui semble cohérente avec le tournant prix par Apple ces dernières années concernant les mises à niveau gratuites des anciens systèmes vers El Capitain par exemple !
Toute association, quelle que soit sa taille, a besoin de communiquer avec ses membres, produire des documents, diffuser de l’information vers l’extérieur, bref elle a besoin d’un système d’informations structuré et adapté à ses besoins.
Pour autant, toutes les associations ne sont pas logées à la même enseigne lorsqu’il s’agit de choisir et de mettre en place des logiciels adaptés à leurs activités et à leur mode de fonctionnement. Bien souvent, l’achat de matériel informatique et de logiciels est un budget qui pèse lourd et, par manque de compétences sur le sujet, les choix se font par défaut.
Des logiciels libres pour les associations
Combien d’associations restent dépendantes d’outils privateurs ? La plupart du temps sans locaux dédiés, les associations fonctionnent avec les logiciels et les machines possédés par leurs bénévoles. Très peu d’entre eux sont prêts à investir du temps dans la recherche d’outils libres adaptés aux besoins de l’association quand « tout semble si simple » avec les logiciels imposés et vendus avec l’achat d’un ordinateur. Il peut sembler légitime de dédier le plus de temps possible à l’objet de l’association. Pourtant, pour la gestion des adhérents, la comptabilité, les tâches administratives diverses ou encore la communication, choisir des logiciels libres n’est pas qu’une question technique, c’est d’abord une question éminemment stratégique et politique à laquelle il convient de répondre pour renforcer la cohérence avec les valeurs portées par le monde associatif.
Le premier enjeu est de saisir l’importance de s’affranchir des contraintes imposées de par les logiciels privateurs. On peut citer les mises à jour payantes et souvent remises à plus tard (et donc causes de dysfonctionnements dans la gestion de l’asso), les questions liés à la confidentialité des données (en particulier lorsqu’on stocke des données adhérents dans les nuages), les problèmes d’interopérabilité dans la diffusion de fichiers (surtout lorsqu’on cherche à rédiger un document à plusieurs mains), etc.
L’offre de logiciels libres permet non seulement d’effectuer des choix pertinents en identifiant les besoins mais elle permet aussi un très haut niveau d’appropriation des logiciels. Cela est rendu possible par l’exercice des libertés logicielles qui les rendent auditables, partageables et modifiables. Chaque logiciel libre peut se partager : l’utilisation d’un même logiciel chez chaque membre d’une association est facilité. En d’autres termes, utiliser des logiciels libres, pour une association, cela revient à augmenter son niveau de productivité. Et l’utilisation, ici, de termes habituellement adaptés à l’entreprise, est non seulement volontaire mais aussi révélatrice.
Le second enjeu réside dans la spécificité de création des logiciels libres. Ces derniers sont issus de communautés œuvrant pour le bien commun. La plupart de ces communautés sont structurées à la fois par des armées (ou un simple noyau) de contributeurs autour de formes associatives ou apparentées. Autrement dit, avec les logiciels libres, les associations parlent aux associations. On peut s’appuyer sur une communauté pour assurer un support, on peut aussi s’entraider. Le logiciel libre encourage le contact humain et se rapprocher des acteurs de la communauté est souvent un bon moyen d’avancer dans ses choix et ses usages. Dans le cas de structures associatives importantes, il sera sans doute préférable de se tourner vers des entreprises spécialisées dans l’intégration et dans la formation aux logiciels libres. Dans tous les cas, les logiques de collaboration et l’éthique propre aux logiciels libres seront vraisemblablement présentes.
Une nouvelle version du Guide Libre Association
Ce rapport entre logiciel libre et association est le principal thème de travail du groupe de travail Libre Association de l’April dont la volonté est de « créer des ponts entre le logiciel libre et le monde associatif ». Ce groupe a mené deux enquêtes (une première en 2009 et une seconde en 2015) auprès d’associations pour connaître leurs rapports à l’informatique et aux logiciels libres en particulier. Une conclusion de la comparaison de ces deux enquêtes révèle que la question principale en 2009 « que sont les logiciels libres ? » est devenue en 2015 « Comment fait-on pour les adopter ? ». En effet, avec l’extension des accès à Internet et l’évolution positives de l’accès aux logiciels libres, les associations sont devenues non seulement plus réceptives aux libertés logicielles mais sont devenues aussi très attentives aux usages des données informatiques ; en particulier dans une ère post- affaire Snowden. Cela est d’autant plus vrai, qu’un nombre conséquent d’associations attache une importance cruciale à la notion de droits fondamentaux et en particulier à la liberté d’expression.
Forte de ces connaissances, en 2012, l’April a lancé une première version du Guide Libre Association avec le soutien de la fondation du Crédit Coopératif. L’objectif était ambitieux : diffuser des milliers d’exemplaires gratuits d’un guide exposant les enjeux du Libre pour les associations, assorti d’une sélection pertinente de logiciels libres disponibles et constituant une offre mature. En 2014, devant le succès de la première diffusion, c’est au tour de la MACIF de s’associer à cette action pour distribuer à nouveau gratuitement plus de 7000 guides aux associations.
Cliquez sur la couve pour télécharger ou acheter le guide
Cette fois, en 2016, l’April et Framasoft proposent une nouvelle version mise à jour de ce guide. Disponible en couleur ou en noir et blanc, il est possible de le télécharger au format e-pub et PDF, pour une diffusion libre sur tous les supports. Deux versions PDF imprimables sont elles aussi disponibles pour les associations désirant faire imprimer autant d’exemplaires qu’elles le souhaitent.
Nota : Sur le modèle de la collection Framabook, Framasoft propose aussi la vente unitaire du Guide, ou de faire imprimer à tarif intéressant des centaines ou des milliers d’exemplaires.
S’il y a bien un milieu naturel que la Raspberry Pi n’apprécie pas, c’est le milieu aquatique.
Le projet que nous allons vous présenter est donc particulièrement étonnant, puisqu’il s’agit d’utiliser la Raspberry Pi pour suivre des poissons, ou plutôt des baleines.
Un projet scientifique à base de Raspberry Pi
Daniel Pérez Martinez est chercheur et travaille notamment sur l’étude des comportements des baleines.
Dans le cadre de ses recherches, Daniel avait besoin de récolter des données sur les comportements de ces mammifères marins. Seul problème, les appareils qui auraient pu lui permettre de réaliser ces mesures sont absolument hors de prix, environ 20000€ par appareil.
Conséquence de ces difficultés budgétaires, Daniel Pérez était obligé de travailler avec des outils moins efficaces. Une situation a qui duré quelques temps, jusqu’à ce qu’il découvre la Raspberry Pi et qu’il crée le projet Raspiwhale.
Une solution très bon marché et plus efficace
Après la découverte de la Raspberry Pi, Daniel Pérez a finalement décidé de développer sa propre solution pour récolter des données sur ses précieuses baleines.
Après six mois de travail, l’équipe travaillant sur le projet a finalement réussi à développer une balise efficace qu’elle peut placer sur les baleines pour enregistrer les informations qui l’intéressent.
Cette balise est composée de deux parties, le boîtier et le matériel électronique.
La première partie est constituée d’un boîtier étanche venant protéger la Raspberry Pi et les autres composants, et d’une base équipée de ventouses qui viendront se coller à la peau de l’animal.
Du coté de l’électronique, la solution exploite une Raspberry Pi A+ qui est alimentée par deux batteries et fait fonctionner de nombreux capteurs, ainsi qu’une caméra HD (la caméra officielle ?), un transmetteur radio et même un hydrophone pour enregistrer les chants des baleines !
Concrètement, ça fonctionne comment ?
Aujourd’hui, l’équipe travaillant sur le projet a déjà réalisé et utilisé sur le terrain deux boîtiers, prouvant leur capacité à résister à des profondeurs de plusieurs centaines de mètres et aux différents événements attenants au fait de naviguer sur le dos de mammifères de plus de 40 tonnes.
Sur le terrain, les scientifiques approchent les baleines faisant surface et utilisent une longue perche en fibre de carbone pour placer le boîtier sur le dos de l’animal.
Les ventouses adhèrent alors à la peau du mammifère sans le blesser et assurent que le boîtier reste bien en place, permettant ainsi le suivi des mouvements de l’animal et la récolte des données.
Finalement, après quelques temps, le boîtier fini par se détacher de l’animal, remontant alors à la surface pour permettre aux équipe de recherche de le récupérer.
Tout au long de l’opération, l’équipe peut utiliser le transmetteur radio pour contrôler le fonctionnement du boîtier et récupérer les informations en direct !
Un projet sympa qui devrait encore s’améliorer
D’ici un an, l’équipe du projet Raspiwhale compte effectuer plus d’une trentaine de relevés et travailler à améliorer le boîtier pour l’adapter aux dauphins et autres mammifères marins moins imposants.
D’autres équipes travaillant sur le monde marins s’intéressent également au projet, notamment grâce à son faible coût, et il ne fait aucun doute que ce nouveau système permettra d’améliorer nos connaissances sur le sujet.
Un beau projet, plein d’imagination et très 1er avril 😉
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 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.
Windows, qui reste le logiciel privateur par excellence, même si d’autres l’ont depuis rejoint
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
2.1.1 Taux de disponibilité du service
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énis 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.
2.1.2 Blocage de la construction du Logiciel Libre par réaction en chaîne
Aujourd’hui plusieurs outils de gestion des dépendances comme npm dans le monde javascript, Bundler dans le monde Ruby ou même pip pour le monde Python sont capables d’aller chercher le code source d’une application directement depuis Github. Les projets du Logiciel Libre étant de plus en plus intriqués, dépendants les uns des autres, si l’un des composants de la chaîne de construction vient à manquer, c’est toute la chaîne qui s’arrête.
Un excellent exemple de cet état de fait est la récente affaire du npmgate (voir l’article Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre). Github peut très bien demain être mis en demeure par une entreprise de retirer du code source de son dépôt, ce qui pourrait entraîner une réaction en chaîne menant à l’impossibilité de construire de nombreux projets du Logiciel Libre, comme cela vient d’arriver à la communauté Node.js à cause de la société Npm, inc. gérant l’infrastructure de l’installeur automatisé npm.
2.2 Un peu de recul historique : SourceForge
Même si l’ampleur du phénomène n’a pas été la même, il est bon de rappeler que Github n’est pas apparu ex-nihilo et avait un prédécesseur ayant joui en son temps d’un engouement important : SourceForge.
Fortement centralisé, reposant également sur de fortes interactions avec la communauté, SourceForge est un SAAS fortement vieillissant ces dernières années et subit une véritable hémorragie de ses utilisateurs au profit de Github. Ce qui signifie beaucoup d’ennuis pour ceux qui y sont restés. Pour le projet Gimp, il s’agit tout d’abord d’abus publicitaires trompeurs indignes, qui entraînent également le départ du projet VLC , puis l’apparition d’installeurs comprenant des adwares se faisant passer pour l’installeur officiel Windows de Gimp. Et enfin purement et simplement le piratage du compte SourceForge du projet Gimp par… les équipes de SourceForge elle-même.
Nous voyons ici des exemples récents et très concrets des pratiques dont sont capables les sociétés commerciales lorsqu’elles sont sous la pression de leurs actionnaires. D’où la nécessité de bien comprendre l’enjeu représenté par le fait de leur confier une centralisation des données et des échanges ayant de fortes conséquences sur le fonctionnement et les usages de la communauté du Logiciel Libre et opensource.
2.3 Les critiques relatives à utiliser un logiciel privateur
2.3.1 Une communauté, différents rapports au logiciel propriétaire
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 opensource, 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 pendants 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 BSD
2.3.2 Les pertes de données et obstructions liées à l’usage d’un logiciel privateur
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 800000 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.
Issues, le suivi de bug propriétaire de Github
Autre perte si Github disparaît ou devient inaccessible : le travail de revue des « push requests » (abrégées par PRs) en cours. Pour les lecteurs qui ne connaîtraient pas cette fonctionnalité de Github, il s’agit d’adresser de cloner le dépôt Github d’un projet, de modifier ce clone pour l’adapter à vos besoins, puis ensuite de proposer vos modifications au dépôt d’origine. Le propriétaire du dépôt d’origine va alors étudier les modifications qui lui ont été proposées et si elles lui conviennent les fusionner à son propre dépôt. Il s’agit donc d’une fonctionnalité très importante offerte de Github, qui propose de réaliser les différentes opérations graphiquement via son interface.
Toutefois le travail de revue des modifications proposées peut être long et il est courant d’avoir, pour un projet qui marche bien, plusieurs PRs en cours. Et il est également courant d’échanger des commentaires via ces PRs et/ou via le système de suivi de bugs propriétaires de Github dont nous avons parlé plus haut.
Le code en lui-même n’est donc pas perdu si Github devient inaccessible (quoique, voire plus bas un cas spécifique), mais le travail de revue matérialisée par les éventuels demandes et commentaires présents dans les PRs et les suivis de bugs associés l’est bien, lui. Rappelons également que Github permet de cloner des projets via son interface web propriétaire, puis d’y apporter toujours via la même interface des modifications et ensuite de générer des PRs sans télécharger aucunement le code sur son poste. Dans ce cas de figure, si Github devient indisponible, la perte du code et du travail en cours est totale.
Enfin certains utilisateurs se servent de Github entre autre comme d’une application de favoris, afin de suivre l’activité de leurs projets préférés en s’abonnant à ces projets par la fonctionnalité « Watch ». Ce travail de réunion de données pour la veille technologique est perdu en cas d’indisponibilité du service Github.
Debian, l’un des principaux projets du Logiciel Libre avec autour de 1000 contributeurs officiels
2.4 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.
3. 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’alternative et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capable de programmer devrait 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
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.
