Funkwhale : Eliot franchit le pas

Quand un développeur choisit de se consacrer à plein temps au logiciel libre qu’il a créé, ça nous intéresse. Quand en plus il s’agit d’un logiciel fédéré qui fait appel au protocole activityPub…

Lecteurs et lectrices de ce blog, vous connaissez sans doute le papa de Funkwhale, Eliot Berriot, déjà longuement interviewé par Narf. Dans l’article qu’il vient de faire paraître sur le nouveau blog consacré au projet, il fait le bilan de ce qui s’est passé, évoque le succès présent de Funkwhale et surtout envisage l’avenir. Son projet a commencé à  rallier une communauté de contributeurs et contributrices et suscite un intérêt grandissant, mais qu’en sera-t-il sur le long terme, pourra-t-il s’appuyer sur des contributions solides et nombreuses, et avec quelles ressources financières peut se poursuivre le développement ?

N’hésitez pas à contribuer de toutes les façons possibles (code, documentation, traduction, bêta-tests, signalement de bugs, communication, don financier, messages de soutien et de remerciement…) au succès de Funkwhale !

 

Funkwhale : passé, présent… et avenir ?

Par Eliot Berriot
billet original en anglais sur le nouveau blog de Funkwhale

Funkwhale a débuté comme un projet personnel il y a trois ans, en réponse à la fermeture de Grooveshark. À partir d’aujourd’hui, de nouvelles instances apparaissent chaque semaine, le projet prend de l’ampleur et attire des contributions extérieures. Que peut-on attendre de l’avenir du projet ?

Passé

Au début, en 2015, il n’y avait que moi, Eliot, qui travaillais sur mon temps libre sur ce « truc », en réaction à la disparition de Grooveshark. À cette époque, Funkwhale n’avait pas de logo, pas de documentation, pas de site web, l’interface utilisateur était malcommode, buguée, et le seul déploiement était… le mien.
Ça fonctionnait, et c’était satisfaisant d’être indépendant des grandes plateformes de streaming, mais l’effort n’en valait vraiment pas la peine, d’autant plus que l’interface n’était pas fameuse.
Cependant, en 2017 (ou était-ce 2016 ?), j’ai découvert une nouvelle super technologie, appelée VueJS, que j’ai utilisée pour reconstruire le front-end du projet, à partir de zéro. Soudain, tout est devenu à la fois plus facile et plus satisfaisant du point de vue de l’utilisateur et du développeur, et je me sentais assez confiant pour montrer le projet à des amis proches et à la famille.
En utilisant leurs commentaires, j’ai pu améliorer le projet et ajouter progressivement de nouvelles fonctionnalités. La première fois que j’en ai parlé publiquement, c’était probablement ici, en juillet 2017. Mais le vrai coup d’envoi du projet a été avec ce pouet, où j’ai invité des gens sur ma propre instance pour une bêta fermée, fin février 2018.

Cela a attiré quelques dizaines de nouveaux venus, désireux d’essayer (et de casser) l’application. Là encore, leurs commentaires m’ont beaucoup aidé, et le projet doit beaucoup à leurs contributions. Dans l’ensemble, je dirais que le feedback a été très positif, et pour moi, c’était un de ces moments de la vie où l’énergie et les idées sont au rendez-vous !

De mars à aujourd’hui, les choses se sont accélérées. Beaucoup de choses :
Sean Tilley a écrit un excellent article sur le projet, attirant plus de gens.
• D’autres personnes ont commencé à héberger des instances de Funkwhale. Gled, en particulier, a commencé la première instance publique : https://funkwhale.mastodon.host/
• Les contributions externes ont été ajoutées à la base de données et à la documentation par pas moins de 20 personnes.
• Les gens ont commencé à donner de l’argent au projet sur Liberapay et Duniter.
• J’ai ouvert un compte Mastodon dédié au projet : https://mastodon.eliotberriot.com/@funkwhale.
• J’ai ouvert des canaux de discussion avec Matrix pour rassembler les membres de la communauté, discuter du développement, accueillir les nouveaux arrivants et s’amuser ensemble.
• La fédération de base des bibliothèques musicales a été mise en place.
• J’ai été interviewé par Narf, de Framasoft, et Guénaël Pépin, de NextINpact sur le projet.
• J’ai présenté ActivityPub et l’implémentation de Funkwhale aux RMLL à Strasbourg, en juillet.
• Funkwhale a été internationalisé et de chouettes contributeurs l’ont traduit dans plus de 10 langues.
• Jibec a créé et maintenu un paquet YunoHost pour le projet.
• J’ai passé une semaine en juillet avec d’autres développeurs, designers et contributeurs à des projets fédérés lors du « fédérathon », organisé par Nathanaël. Les utilisateurs et utilisatrices ont testé l’interface de Funkwhale, et de nombreux commentaires ont été recueillis.
• Nous sommes passés de la version 0.6 à la version 0.16, avec littéralement des dizaines de corrections de bogues, de nouvelles fonctionnalités, des améliorations, etc.
Curator a lancé Open.audio, une instance ouverte pour les créateurs et créatrices qui souhaitent partager leur contenu sur Funkwhale.
• Toutes les autres choses que j’ai oubliées…

 

Je ne dis pas ça pour être prétentieux ou en obtenir les lauriers. En fait, beaucoup de ces réalisations et jalons ont impliqué d’autres personnes que moi, et même si je suis toujours le principal développeur et contributeur du code, le projet dans son état actuel va bien au-delà de ce que je pourrais faire par moi-même.
Merci donc à toutes les personnes qui ont aidé, apporté du plaisir, des idées, des commentaires, de la conception, du design, des traductions, qui ont parlé du projet et l’ont amélioré.

Funkwhale semble plus réel maintenant qu’il y a un an, et c’est grâce à vous !

capture de l’interface démo de Funkwhale
Capture de l’interface de Funkwhale

Présent

Donc, nous voilà, l’été est terminé, et nous devons parler de ce qui se passera ensuite. Parce que toutes les bonnes choses qui se sont passées avaient aussi un prix et, malheureusement, les choses ne peuvent pas continuer comme ça pour toujours.

En tant que responsable de projet et contributeur principal, j’ai encore beaucoup de choses à faire :

• Recueillir les commentaires
• Aider les propriétaires d’utilisateurs et d’instances à résoudre les problèmes d’installation ou d’utilisation.
• Maintenir la documentation à jour et l’améliorer.
• Accueillir de nouvelles personnes dans la communauté et répondre aux questions sur le projet.
• Répondre aux questions sur le projet, sa feuille de route, ses caractéristiques, etc.
• Gérer l’outil de suivi des problèmes : répondre aux nouveaux problèmes, commentaires, les classer par ordre de priorité d’une version à l’autre.
• Revoir les contributions aux codes : vérifier que les changements suggérés fonctionnent et respectent les lignes directrices, aider leur auteur à les finaliser.
• Discuter des nouvelles fonctionnalités avec les utilisateurs
• Implémenter de nouvelles fonctionnalités / corriger des bogues
• Etc.

 

Comme vous l’avez probablement deviné, cela prend beaucoup de temps, et tout cela doit se faire pendant mon temps libre, puisque je travaille à plein temps. A ce stade, vous ne voulez probablement pas savoir combien de week-ends et de soirées j’ai passé à travailler sur Funkwhale 😉
Je n’insinue pas que je suis épuisé : ce n’est pas le cas. Cependant, à long terme, persister de cette façon est la voie vers le désastre. Vous avez peut-être remarqué que le développement du Funkwhale a ralenti pendant l’été, eh bien, c’est en partie à cause de cela : J’ai dû prendre du recul et profiter d’un peu de temps libre.

Maintenant, que puis-je faire à long terme ?

Avenir

Aujourd’hui, je peux l’annoncer, puisque les négociations avec mon employeur sont terminées :

je quitte mon emploi chez PeopleDoc pour travailler sur Funkwhale. À partir du 1er décembre, je pourrai travailler à plein temps sur le projet et lui accorder l’attention qu’il mérite.

J’aimerais remercier mon employeur et mes collègues, car ils me soutiennent beaucoup et ont accepté de me laisser partir !

Je suis très enthousiaste à l’idée de commencer ce nouveau chapitre de la vie du projet et je suis persuadé que cela m’aidera à trouver de nombreuses solutions aux défis actuels auxquels nous sommes confrontés :
• rendre le projet plus accessible aux utilisateurs et aux contributeurs
• simplifier les processus d’installation, de maintenance et de mise à niveau
• permettre un soutien financier et non financier aux créateurs de contenu qui publient leurs travaux sur Funkwhale.
• mettre en place une structure adéquate autour du Funkwhale pour recevoir les dons, payer les contributeurs (comme moi), gérer les espaces communautaires, etc.
• travailler sur des fonctionnalités plus importantes

logo de funkwhale, couleur verte
Feu vert pour Funkwhale !

Merci d’avoir lu, on va faire des choses géniales ensemble !

 

PS : vous avez peut-être remarqué qu’il s’agit d’un nouveau blog. Nous n’allons pas arrêter de publier sur Mastodon, mais un blog est mieux adapté pour les longs messages et les annonces, et apportera aussi plus de visibilité au projet.
Vous pouvez suivre ce blog en utilisant RSS / Atom, mais aussi sur la Fediverse, en suivant @funkwhale@blog.funkwhale.audio, grâce au travail incroyable de Baptiste et d’autres contributeurs de Plume !

Liens utiles




PeerTube : vers la version 1, et au-delà !

PeerTube est un logiciel libre permettant d’héberger et de partager des vidéos.

Ses principales différences avec YouTube, Dailymotion, Vimeo & co ?

  • PeerTube est libre : son code est un « commun » numérique, partagé avec tous et toutes, et non une recette secrète appartenant à Google (pour YouTube) ou à Vivendi/Bolloré (pour Dailymotion).
  • PeerTube est décentralisé : toute personne en ayant les compétences peut l’installer sur son propre serveur et mettre en place « sa » version de PeerTube (qu’on appelle une « instance »).
  • PeerTube n’impose pas de gouvernance : contrairement à YouTube, toute structure (individu, entreprise, association, communauté, etc.) ayant installé son instance PeerTube peut choisir sa thématique, les vidéos qu’elle héberge, qui peut s’y enregistrer pour disposer d’un compte, etc.
  • PeerTube est fédéré : contrairement à YouTube qui est un seul énorme silo contenant des milliards de vidéos, une instance PeerTube peut se connecter à d’autres instances de son choix et afficher leurs vidéos, sans avoir besoin de changer de site. Ainsi, avec PeerTube, vos vidéos ne sont plus isolées sur une seule machine : elles peuvent être cherchées et regardées depuis des centaines d’autres instances PeerTube.
  • PeerTube permet du streaming en pair-à-pair : contrairement à YouTube, qui est le seul « émetteur » de la vidéo, si 100 personnes regardent une même vidéo avec PeerTube, elles s’envoient de petits morceaux de la vidéo les unes aux autres, diminuant ainsi les coûts de diffusion pour la structure hébergeant l’instance.

[Vidéo de présentation de PeerTube, en anglais, avec les sous-titres français, sur Framatube. Pour la vidéo avec les sous-titres en anglais, cliquez ici. Réalisation : Association LILA (CC by-sa)]

 

Rappel des épisodes précédents : en novembre dernier, nous vous annoncions que Framasoft avait recruté Chocobozzz, le développeur du logiciel PeerTube (alors en version alpha), afin de lui donner les moyens de produire une version bêta du logiciel.
Nous vous avions alors sollicités pour nous aider à financer ce contrat de quelques mois (octobre 2017 à mars 2018). Grâce à l’aide précieuse de centaines de donatrices et donateurs, nous avons pu tenir notre engagement et publier la version bêta de PeerTube en mars 2018 (en respectant les délais, en plus !).

Depuis, les instances PeerTube ont fleuri. On compte aujourd’hui plus d’une centaines d’instances publiques déclarées (et sans doute bien plus non publiquement déclarées), hébergeant plusieurs milliers de vidéos !
Nous avons aussi pu éprouver sa robustesse lorsque nos amis de Datagueule ont publié leur film « Démocratie(s) » simultanément sur YouTube et PeerTube. Malgré des milliers de connexions, le logiciel a parfaitement tenu la charge. 🙂

Vers la version 1, et au-delà !

Cependant, force est de constater que PeerTube reste un logiciel encore non finalisé.
Par exemple la recherche n’est pas encore très fonctionnelle (si vous cherchez « Iinternet own boy » sur Framatube, aucun résultat n’est retourné, alors que si vous cherchez « internet’s own boy« , vous pourrez accéder à cet excellent documentaire sur la vie de l’hacktiviste Aaron Swartz).
PeerTube ne permet pas non plus encore d’intégrer un fichier de sous-titres à une vidéo, ou d’afficher son interface dans une autre langue que l’anglais, etc.
Bref, PeerTube fonctionne (bien), mais il reste encore de nombreuses améliorations à y apporter pour pouvoir le considérer comme une alternative sérieuse à YouTube.

Framasoft a donc fait le pari de prolonger le contrat de Chocobozzz jusqu’à la fin de l’année 2018, afin là encore de se donner les moyens d’atteindre son objectif, fournir une version 1 de PeerTube.

Mais là encore, se posait la question du financement de ce poste.

Comme nous avions déjà sollicité la communauté francophone (qui connaît plutôt bien l’association Framasoft et nous fait confiance depuis des années), nous ne souhaitions pas demander à cette communauté de mettre à nouveau la main au portefeuille.

Représentation d’instances PeerTube (CC by-sa – Association LILA)

 

Framasoft Need You!

Nous avons donc fait le choix de lancer une « classique » campagne de financement participatif. Mais de nous adresser avant tout au public non-francophone lors de son lancement.

En effet, les actions de Framasoft sont relativement inconnues à l’étranger. Évidemment parce que l’essentiel de nos travaux (maison d’édition Framabook, annuaire Framalibre, et bien entendu nos différents services libres de la campagne « Dégooglisons Internet ») sont publiés en français, mais aussi parce que nous communiquons et intervenons rarement à l’étranger (à quelques exceptions près).
Nous souhaitons donc, avec cette campagne, sensibiliser le public non-francophone, en l’informant de l’existence de PeerTube (qui n’est pas un vaporware  puisque déjà largement fonctionnel).

Par ailleurs, et de façon pas du tout anecdotique, nous souhaitons remercier l’association LILA qui, en parallèle de la réalisation de ZeMarmot (long métrage d’animation réalisé avec Gimp), a réalisé la magnifique animation que vous pouvez découvrir au début de cet article ou, bien entendu, sur la page de campagne. Cette vidéo a été réalisée uniquement avec des logiciels libres (Gimp, ça va de soi, mais aussi Synfig et Blender). Merci à Jehan et Aryeom pour leur colossal travail en un temps record ! N’hésitez pas à les remercier et à les encourager financièrement pour leurs travaux.

Notez que la vidéo est disponible sur Framatube (évidemment) afin de pouvoir la partager. Elle est naturellement sous licence libre (CC by-sa), ainsi que la musique (par Ken Bushima – CC by).

La page de la campagne en anglais est accessible ici : https://www.kisskissbankbank.com/en/projects/peertube-a-free-and-federated-video-platform/ (et en français ici : https://www.kisskissbankbank.com/fr/projects/peertube-a-free-and-federated-video-platform/ )

Le premier des trois paliers de la campagne de financement PeerTube (CC by-sa – Association LILA)

Comment nous aider ?

Vous pouvez bien évidemment participer financièrement à la campagne de financement participatif, mais si vous l’avez déjà fait fin 2017, vous aurez compris qu’on ne vous met pas la pression (d’autant que cette fois, il n’y aura probablement pas de défiscalisation possible).

Vous pouvez aussi nous aider à traduire certaines parties de la campagne, qu’il s’agisse de la page de campagne, de la FAQ, des sous-titres de la vidéo, ou du site joinpeertube.org, en vous signalant comme volontaire sur notre forum.

Nous sollicitons surtout votre aide pour partager l’information sur les médias sociaux (libres ou non), en utilisant si possible le hashtag #joinpeertube !

Si vous avez un oncle d’Amérique, une tante en Australie, une cousine au Chili, ou un frère en Allemagne, lui signaler l’existence de PeerTube nous serait d’une grande aide pour faire découvrir ce projet qui nous semble essentiel pour l’émancipation de toutes et tous.

 

Joinpeertube – Cliquez pour accéder à la page de campagne




Ce qui nous pousse au Libre

Si certains logiciels libres sont réputés à la fois pour leur efficacité et leur esthétique fonctionnelle (qu’on nommera design, parce que c’est ainsi), il faut reconnaître qu’ils ne font pas la majorité.

Certains designers aimeraient apporter leur pierre à l’édifice libriste, et rendre plus attractifs et fonctionnels les logiciels libres, mais la route semble encore bien longue comme l’a récemment constaté Maiwann. Le dialogue entre développeurs de logiciels libre et designers semble cependant s’amorcer sous les meilleurs augures, d’abord en identifiant clairement les besoins mais aussi en proposant des solutions d’interactions. Dans ce billet, Marien Fressinaud apporte une réponse de développeur et identifie, à son tour, un espace de convergence. Cet article a été initialement publié sur son blog sous licence « CC BY ».

Marien, développeur et membre de Framasoft.

Il y a quelques jours, Maiwann proposait dans un article de réconcilier designers et logiciels libres. L’article ne manque pas d’intérêt, ne serait-ce que parce qu’il identifie les freins à la collaboration des designers au libre et suggère des actions concrètes pour y remédier.

Bien que je partage bon nombre des constats, je souhaitais le « compléter », cette fois en adoptant le point de vue du développeur que je suis. En effet, il est un sujet que Maiwann n’aborde quasiment pas : pourquoi faire du logiciel libre ? Pour ma part, j’aurais en effet aimé mieux comprendre ce qui motive des designers à vouloir contribuer au Libre. En guise d’effet miroir, j’essaie donc dans cet article d’envisager les raisons qui peuvent inciter un développeur à le faire, sans prétendre être exhaustif. Cette mise en perspective repose sur mes expériences personnelles concernant FreshRSS, Lessy, les actions menées au nom de Framasoft ou encore à travers les écrits que j’ai pu lire à droite à gauche.

Apprentissage

Dans l’article de Maiwann, la seule référence à une potentielle motivation se trouve au détour d’un paragraphe :

Lors de nos études, […] alors que nous cherchons à nous entraîner, sur notre temps libre ou pour des projets de fin d’année, nous nous plaignons de ne connaître aucun développeur avec qui co-créer des sites ou logiciels.

Voilà une raison qui devrait parler à bon nombre d’étudiants et d’étudiantes ! Appliquer ce que l’on a pu apprendre en cours et donc, par extension, apprendre par la pratique est souvent moteur chez les développeurs. J’ai moi-même développé un certain nombre de programmes avec cette simple motivation. Par exemple, Minz fut ma tentative de comprendre le fonctionnement interne des frameworks web. FreshRSS a été l’occasion de travailler véritablement en communauté, et donc en équipe collaborant à distance et de façon asynchrone. Sur Lessy, j’ai pu consolider tout un paquet de connaissances que j’ai ensuite pu proposer et appliquer au boulot. Le logiciel libre est une formidable source d’apprentissage que je recommande fortement à toutes et tous.

Cela étant dit, considérer l’apprentissage comme seul moteur dans le développement d’un logiciel libre est bien entendu extrêmement réducteur et j’aurais tendance à dire que ce n’est pas la raison majeure (bien qu’il s’agisse probablement de la porte d’entrée principale pour bon nombre d’entre nous). Cherchons donc ailleurs d’autres raisons qui nous poussent, nous développeurs et développeuses, à produire du logiciel libre.

Plaisir, apprentissage et logiciel libre : le Serious Gaming (et Framinetest) en sont un bon exemple.

Plaisir

Dans le prologue du bouquin L’Éthique hacker, Linus Torvalds explique les motivations des hackers derrière le système d’exploitation Linux :

La raison pour laquelle les hackers derrière Linux se lancent dans quelque chose, c’est qu’ils trouvent ça très intéressant et qu’ils veulent le partager avec d’autres. Tout d’un coup, vous avez le plaisir parce que vous faites quelque chose d’intéressant et vous avez aussi le pendant social.

Il nous dit plusieurs choses ici. Tout d’abord, le développement d’un tel système relève avant tout du plaisir. Et il est vrai qu’on peut se demander ce qui pousse des milliers de développeurs à partager leurs savoirs et leur temps, généralement de façon gratuite, si ce n’est le plaisir de le faire ? D’ailleurs Pekka Himanen (l’auteur du bouquin) cite un peu plus loin Éric Raymond, à l’origine de la popularisation du terme « open source » (j’aurai l’occasion de revenir sur ce terme plus tard) :

La conception de logiciel et sa mise en œuvre devraient être un art jubilatoire, et une sorte de jeu haut de gamme. Si cette attitude te paraît absurde ou quelque peu embarrassante, arrête et réfléchis un peu. Demande-toi ce que tu as pu oublier. Pourquoi développes-tu un logiciel au lieu de faire autre chose pour gagner de l’argent ou passer le temps ?

On y retrouve la notion de plaisir à travers le « jeu haut de gamme ». Je prends souvent l’exemple du Sudoku ou de la grille de mots-croisés : il n’y a, à priori, aucune raison de remplir ces cases de chiffres ou de lettres, si ce n’est le plaisir de résoudre un problème, parfois complexe. Je trouve personnellement que le développement de logiciel peut amener à un état de satisfaction similaire lorsqu’on se trouve face à un problème et qu’on arrive finalement à le résoudre après plusieurs heures jours semaines de recherche.

D’un point de vue personnel, j’ai toujours été attiré par les domaines de « création ». J’ai immédiatement accroché au développement lorsque j’ai découvert que créer un site web était aussi simple que créer un fichier texte avec quelques mots dedans. Les balises HTML ? – Un simple jeu de Lego®. Les CSS ? – Quelques directives de base à connaître et on arrive rapidement à quelque chose de totalement différent. Un serveur web ? – Un ordinateur avec un logiciel spécifique qui tourne dessus. Un bug ? – Une « chasse » durant laquelle on déroule le programme qui nous semblait si logique au moment de l’écrire (mais qui l’est maintenant beaucoup moins !). Pour moi, la beauté de l’informatique réside dans sa simplicité et sa logique : il y a un véritable plaisir à comprendre comment toutes ces petites boîtes s’agencent entre elles et que tout devient plus clair.

L’espace Logiciels Libres, Hackers, Fablab de la fête de l’Huma 2016.

Partage

Si l’on s’en tient aux notions d’apprentissage et de plaisir, il n’y a rien qui distingue le logiciel libre du logiciel propriétaire. Vous pouvez très bien apprendre et éprouver du plaisir en développant du code fermé. Il nous faut revenir à la citation de Torvalds pour commencer à percevoir ce qui les différencie :

[…] ils veulent le partager avec d’autres.

Le partage : on a là une valeur fondamentale du logiciel libre qui ne trouve pas véritablement son pendant du côté du logiciel propriétaire. Bien que j’aie plus de mal à identifier clairement ce qui peut motiver l’être humain à partager ses savoirs, c’est quelque chose que je ressens effectivement. Cet aspect coopératif — Torvalds parle d’un « pendant social » — peut créer ou renforcer des liens avec d’autres personnes ce qui rend cette activité profondément humaine.

Partager, c’est donc transmettre. Transmettre à une communauté, donner les clés pour que celle-ci soit indépendante. Partager ses savoirs qui permettront peut-être à d’autres de bâtir autre chose par-dessus. Cela permet aussi de créer du lien humain, rencontrer des personnes et ouvrir ses perspectives en créant son propre réseau. C’est aussi s’offrir un coin de canapé quand on voyage. Je me suis rendu compte assez récemment de ce que m’offrait aujourd’hui cette décision en IUT de partager les petits programmes que je pouvais développer sur mon temps libre. La liberté n’est pas que celle du code.

Il y a certainement une forme de fierté à avoir exploré un domaine le premier, ou développé une application que d’autres vont utiliser (« Quoi ? Ce que j’ai fabriqué de mes propres mains t’est aussi utile ? »). Si cette fierté est par essence un peu narcissique (je suis toujours un peu pénible lorsque je suis cité chez NextInpact ou chez Korben 😇), elle est aussi bénéfique car elle encourage à rendre son travail public et donc… partager encore.

Loin du cliché des hackers à capuche, l’édition 2018 du Toulouse HackerSpace Factory utilise Langue des Signes et police Open-Dyslexie dans son imagerie.

Éthique

On retrouve aussi cette notion de partage dans les écrits de Richard Stallman lorsqu’il nous parle des quatre libertés du logiciel :

Elles sont essentielles, pas uniquement pour les enjeux individuels des utilisateurs, mais parce qu’elles favorisent le partage et la coopération qui fondent la solidarité sociale.

Ces mots, pris du point de vue de Stallman, sont bien évidemment à interpréter sous la dimension éthique (et donc politique) du logiciel libre, ce qui n’est pas forcément le cas de Torvalds (je ne saurais néanmoins l’affirmer). Puisque Stallman est à l’origine du mouvement du logiciel libre, on ne peut évidemment pas enlever l’éthique de son équation ou alors vous obtenez de l’open source (comme il l’explique dans l’article cité plus haut). On peut toutefois raisonnablement penser que les partisans du logiciel libre sont moins nombreux que ceux de l’open source, ce que j’explique par une peur ou un désintérêt envers cet objet politisé.

Je trouve toutefois dommage de ne pas plus s’y intéresser. En effet, la dimension éthique aide à répondre à une question que beaucoup de personnes peuvent se poser : « ce que je fais au quotidien a-t-il du sens ? ». Stallman y répond par la défense et le respect des utilisateurs et utilisatrices :

Le mouvement du logiciel libre fait campagne pour la liberté des utilisateurs de l’informatique depuis 1983.

Ou encore :

Pour qu’on puisse dire d’un logiciel qu’il sert ses utilisateurs, il doit respecter leur liberté. Que dire s’il est conçu pour les enchaîner ?

Si je souhaitais conclure par cet argument, c’est parce qu’il aide à boucler la boucle avec l’article de Maiwann. En effet, en tant qu’UX designer, elle va avoir à cœur de répondre aux besoins de ses utilisateurs et donc d’imaginer des mécanismes pour rendre l’outil le plus utilisable et accessible possible. Aujourd’hui il me semble percevoir dans cette communauté un mouvement de prise de conscience que ces mécanismes doivent respecter (on y revient !) les personnes utilisant le logiciel. Cela est superbement bien illustré par la vidéo « Temps de cerveau disponible » (de la série « (Tr)oppressé » que je recommande vivement) dans laquelle un ancien employé de Google, expert en éthique, témoigne :

Le but est de capter et d’exploiter au maximum l’attention.

Il l’illustre ensuite par le lancement automatique de l’épisode suivant sur Netflix et par le défilement infini sur Facebook ou Twitter (incitant de ce fait à parcourir son fil d’actualité dans son ensemble) ; ces petits riens qui font que nous revenons sans cesse à ces applications et que nous en devenons dépendant⋅e⋅s alors qu’elles n’ont d’intérêt que de nous divertir.

L’un des problèmes que j’identifie aujourd’hui est que le logiciel libre copie beaucoup (trop) ce qui se fait dans le propriétaire, et en particulier chez GAFAM et consorts… jusque dans leurs mécanismes nocifs. On peut ici reprendre l’exemple du mécanisme de défilement infini que l’on retrouve chez Mastodon ou Diaspora (et même sur FreshRSS !). Une certaine forme de dépendance peut donc s’installer au sein même de logiciels libres.

Convergence des buts ?

Les designers peuvent aujourd’hui nous aider, développeurs et développeuses, à repenser l’éthique de nos logiciels en replaçant les usages au centre de nos préoccupations et en imaginant et proposant des mécanismes permettant « d’endiguer » ce flux permanent d’informations qu’il nous faut ingurgiter.

Elles et ils peuvent aussi nous aider à atteindre véritablement nos utilisateurs et utilisatrices en rendant nos outils utilisables et… utilisés. Car un logiciel non utilisable peut-il véritablement être considéré comme Libre ? Je ne peux m’empêcher de faire ici le parallèle avec l’association Liberté 0 qui a pour objet de « sensibiliser et de promouvoir le numérique libre et accessible à toutes et tous ». Dans leur charte, il est explicité :

Les membres du groupe « Liberté 0 » considèrent que la liberté d’exécuter un programme n’a de sens que si celui-ci est utilisable effectivement.

L’association est donc dans cette même démarche de promouvoir l’« utilisabilité » des logiciels, au même titre que les UX designers (mais sous le prisme de l’accessibilité).

N’y aurait-il pas ici une convergence des buts ? N’existe-t-il pas un lieu où nous pourrions nous regrouper tous ensemble pour imaginer des outils autres que ceux issus du « capitalisme de surveillance » ?


Merci à Maiwann pour sa relecture attentive !




Merci du signalement, ton bug peut attendre…

Magnus Manske est un développeur inconnu du grand public, on lui doit pourtant des contributions nombreuses et décisives pour le développement initial de Wikipédia, sa maintenance continue et son ingénierie, au point que les wikipédiens célèbrent chaque 25 janvier le Magnus Manske Day.

On imagine aisément à quel point ses journées sont bien remplies, d’autant qu’il donne son temps et son énergie pour le Libre sur son temps… libre !

Dans l’article dont nous vous proposons la traduction, il explique avec un brin de malice pourquoi les bugs apparemment les plus simples à traiter peuvent s’avérer les plus longs à régler… Deux minutes de lecture pour un petit article qui parlera à nos amis développeurs (ces indispensables travailleurs de l’ombre) comme il a parlé à Luc, notre tech warrior tout-terrain…

 

Non, je n’ai pas corrigé ton bogue, voici pourquoi

par Magnus Manske – article original : Why I didn’t fix your bug

Photo par Jason Krüger [CC BY-SA 4.0], via Wikimedia Commons
Beaucoup d’entre vous m’ont envoyé des rapports de bogue, des demandes de nouvelles fonctionnalités et signalé d’autres problèmes liés à mes outils dans le WikiVerse. Vous m’avez contacté via le BitBucket Issue tracker (et apparemment je suis aussi sur Phabricator maintenant), par Twitter, divers emails, des pages de discussion (les miennes, celles d’autres utilisateurs, via Wikitech, etc.), avec des applications de messagerie, et même en chair et en os.

Et je n’ai rien fait. Je n’ai même pas répondu.

Rien n’indique que j’ai vu le problème.

C’est frustrant, je sais. Tu veux juste que ce petit truc soit réparé. En tout cas, tu te figures que c’est un tout petit changement à opérer.

Voyons maintenant les ressources disponibles, ce qui, en l’occurrence, est mon temps. En commençant par les gros travaux (estimations générales, des variations saisonnières sont inévitables) :

Il y 24 h dans une journée

– 9 h de travail (y compris le trajet en voiture)

– 7 h de sommeil (j’espère en tout cas)

– 2 h de vie privée (manger, faire de l’exercice, prendre une douche, lire, passer du temps avec ma copine, etc.)

= il reste 6h

On ne peut pas discuter avec ça, n’est-ce pas ? Maintenant, 6h qui restent, c’est une estimation haute, évidemment ; le travail et la vie privée peuvent (et ça arrive) prendre bien plus de temps, sur une base quotidienne et très variable, comme c’est le cas pour chacun de nous.

Alors je peux régler ton problème, c’est ça ?

Voyons voir :

6h

– 1h de maintenance (redémarrage des outils, mise à jour des pages GLAM, ajout et correction des catalogues mix“n”match, etc.)

– 3h de développement/réécriture (parce que c’est de là que viennent les outils)

= il reste 2h

Deux heures par jour, ça fait beaucoup, non ? En réalité, c’est beaucoup moins, mais restons-en là pour l’instant. Quelques-uns de mes outils n’ont pas de problèmes, mais beaucoup en ont plusieurs en cours, donc supposons que chaque outil en a un :

2h = 120 min

/130 outils (estimation basse)1

= une moyenne de 55 secondes par outil

C’est assez de temps pour trouver et aborder le problème, ouvrir le(s) fichier(s) de code source, et… zut le temps s’est écoulé ! Désolé, problème suivant !

Donc, au lieu de tous les traiter, je m’occupe de l’un d’entre eux. Jusqu’à ce que ce soit réglé ou que j’abandonne. L’un ou l’autre peut prendre des minutes, des heures, voire des jours. Et pendant ce temps, je ne me penche pas sur les centaines d’autres problèmes. Parce que je ne peux rien faire pour eux à ce moment-là.

Alors, comment puis-je choisir un problème sur lequel travailler ? C’est une heuristique complexe calculée à partir des facteurs suivants :

  • Nombre d’utilisateurs concernés
  • Gravité (« problème de sécurité » vs « faute d’orthographe »)
  • Opportunité (ce qui signifie que je l’ai remarqué lorsqu’il a été déposé)
  • Disponibilité (est-ce que je me concentre sur autre chose lorsque je remarque le problème ?)
  • Plaisir possible et humeur du moment (eh oui, car je suis bénévole, ça vous dérange ?).

 

Aucun événement particulier n’a été à l’origine de la publication de ce billet. Je le garderai en référence pour en donner le lien, quand l’occasion se présentera.




Créateurs du numérique, parlons un peu éthique

Une lettre ouverte de la communauté des technologies de l’information invite à réfléchir un peu à la notion de responsabilité de chacun, compte tenu de l’enjeu du numérique pour nous tous.

Une invitation à réfléchir et débattre donc, au-delà de la pétition (encore une !) aux accents idéalistes. Nous avons peut-être tous besoin de nous demander ce que nous faisons concrètement pour nous mettre en phase avec nos idéaux. C’est en ce sens que la traduction que nous vous proposons nous semble digne d’intérêt.

Pendant 48 heures, les 150 participants issus du monde du numérique (des développeurs et développeuses, des designers, mais aussi des philosophes, des enseignant⋅e⋅s et des artistes)  du Techfestival de Copenhague ont échangé, débattu et se sont accordés entre autres pour lancer cet appel dont vous trouverez la version originale sur la page https://copenhagenletter.org/

Les auteurs précisent :

Cette lettre reflète (notre) engagement, et lance un débat sur les valeurs et les principes qui guident la technologie.

Vous avez bien lu : voilà une petite bande qui estime que ce n’est pas la technologie ou le profit qui doivent guider leur activité mais des valeurs et des principes.

Oserons-nous avancer que cette perspective, qui peut exister dans le milieu libriste, est bien rare dans une communauté de travailleurs du numérique (si cette expression vous heurte dites-nous pourquoi…) ou la notion de responsabilité est trop souvent mise sous le tapis.

S’il vous faut des exemples : la responsabilité de ceux qui conçoivent des algorithmes, on en parle ? Les objets connectés qui commencent à investir notre vie quotidienne, quels principes en gouvernent la conception ? L’administration des bases de données sensibles, quels garde-fous ?

Si après avoir parcouru cet appel vous souhaitez signer et donc vous engager, vous trouverez le lien au bas de la page.

Traduction Framalang : mo, goofy, PasDePanique, Penguin, xi, audionuma et des anonymes

 

La lettre de Copenhague, 2017

 

À tous ceux qui façonnent la technologie aujourd’hui

Nous vivons dans un monde où la technologie dévore la société, l’éthique et notre existence elle-même.

Il est temps d’assumer la responsabilité du monde que nous créons. Il est temps que les êtres humains passent avant le business. Il est temps de remplacer la rhétorique creuse du « construire un monde meilleur » par un engagement à agir concrètement. Il est temps de nous organiser et de nous considérer comme responsables les uns envers les autres.

La technologie ne nous est pas supérieure. Elle devrait être gouvernée par nous tous, par nos institutions démocratiques. Elle devrait respecter les règles de nos sociétés. Elle devrait répondre à nos besoins, individuels et collectifs, tout autant qu’à nos envies.

Le progrès ne se limite pas à l’innovation. Nous sommes des bâtisseurs-nés. À nous de créer une nouvelle Renaissance. Nous ouvrirons et animerons un débat public honnête sur le pouvoir de la technologie. Nous sommes prêt⋅e⋅s à servir nos sociétés. Nous mettrons en œuvre les moyens à notre disposition pour faire progresser nos sociétés et leurs institutions.

Bâtissons sur la confiance. Jetons les bases d’une véritable transparence. Nous avons besoin de citoyens numériques, pas de simples consommateurs. Nous dépendons tous de la transparence pour comprendre comment la technologie nous façonne, quelles données nous partageons et qui peut y avoir accès. Se considérer les uns les autres comme des produits de base dont on peut tirer le maximum de valeur économique est désastreux, non seulement pour notre société qui est un ensemble complexe et interconnecté, mais aussi pour chacun d’entre nous.

Concevons des outils ouverts à l’analyse. Nous devons encourager une réflexion continue, publique et critique sur notre définition de la réussite, qui précise comment nous construisons et concevons pour les autres. Nous devons chercher à concevoir avec ceux pour qui nous concevons. Nous ne tolérerons pas une conception qui viserait la dépendance, la tromperie ou le contrôle. Nous devons créer des outils que nous aimerions voir utilisés par nos proches. Nous devons remettre en question nos objectifs et écouter notre cœur.

Passons d’une conception centrée sur l’homme à une conception centrée sur l’humanité.
Notre communauté exerce une grande influence. Nous devons protéger et cultiver son potentiel de faire le bien. Nous devons le faire en prêtant attention aux inégalités, avec humilité et amour. En fin de compte, notre récompense sera de savoir que nous avons fait tout ce qui est en notre pouvoir pour rendre notre jardin un peu plus vert que nous ne l’avons trouvé.

Nous qui avons signé cette lettre, nous nous tiendrons, nous-mêmes et chacun d’entre nous, pour responsables de la mise en pratique de ces idées. Tel est notre engagement.

En signant, vous acceptez que votre nom soit listé. Un mail de confirmation vous sera envoyé. Votre adresse mail ne sera partagée avec personne.

Vous êtes invité⋅e à signer* ou répondre à la Lettre de Copenhague, et à partager son contenu.

Contact (en anglais) : hej@copenhagenletter.org

 

*Note : mardi 19/09 à 13h50 plus de 1300 signatures et plus de 2100 à 19h30, ce qui est plutôt bien compte tenu de la cible particulière de ce texte.




Se lancer dans l’open source : un témoignage engageant

Comment participer à des projets open source et s’y sentir légitime ? La réponse habituelle un peu désinvolte consiste à dire : « il suffit de commencer à proposer ne serait-ce qu’un signalement de bug ou une correction mineure dans la documentation et hop ». En commençant par une contribution minime, on peut donc trouver sa place dans une équipe. Théoriquement, c’est exact.

Mais quand on est une jeune femme à peine sortie de ses études d’informatique et qu’on éprouve un peu d’appréhension au contact des contributeurs supposés expérimentés, rien n’est tout à fait simple.

Comme on le lira dans le témoignage de Shubheksha, il faut non seulement parvenir à surmonter son manque de confiance en soi, mais aussi avoir la chance de rencontrer sur son chemin des mentors qui vous accueillent avec bienveillance, vous guident et vous invitent à contribuer davantage encore.

Le parcours cahoteux d’une débutante dans le monde de l’open source

Article original paru dans Medium : A Beginner’s Very Bumpy Journey Through The World of Open Source

Par Shubheksha

Traduction :  Lyn, audionuma, goofy, Lumibd, Manguito,et un anonyme

shubhekshaAvez-vous atterri ici en recherchant des conseils sur la meilleure manière de contribuer à l’open source ? Il y a des milliers d’histoires de ce genre sur Internet, n’est-ce pas ?
Je suis sûre que vous en avez lu beaucoup à présent, car vous essayez de contribuer depuis un bon moment. Et vous avez toujours l’impression de ne pas avoir progressé.
Je connais ce sentiment. J’étais exactement dans la même situation il y a quelques semaines. Laissez-moi vous conter mon histoire.

Voilà à peu près deux ans que j’essaie de contribuer à l’open source.

Oui. Deux ans.

Et il y a bien une chose que je peux affirmer : c’est intimidant. C’est dur de commencer. Vous devez apprendre comment travailler sur un long code source. Vous devez apprendre et adopter les règles de style de code d’un projet.

Tout paraît confus. L’ordre des instructions, comment les différents modules interagissent entre eux, comment et pourquoi le code est organisé de la manière dont il l’est : tout cela constitue un grand labyrinthe.

Je ressens cela en permanence car je ne suis, après tout, qu’une amatrice qui essaie d’en apprendre autant qu’elle le peut.

J’ai donc choisi de suivre la voie la plus facile : la correction de fautes dans la documentation ou les commentaires, et la résolution de bugs triviaux où il était évident de trouver ce qui devait être modifié. Je ne voulais pas poser trop de questions ni essayer de comprendre l’ensemble du code.

Chaque fois que je voulais contribuer, j’allais sur github — ou un autre gestionnaire de bugs – et j’essayais de rechercher des problèmes étiquetés « facile », « débutant », « premier bug facile ». Après en avoir consulté des centaines, je trouvais quelque chose de suffisamment simple à traiter sans beaucoup d’aide extérieure.

Alors, cela a bien fonctionné jusqu’au moment où j’ai pris conscience que je pourrais mieux utiliser les compétences que j’étais en train de développer. J’avais appris tant de nouvelles choses, mais je ne voyais pas à quoi j’aurais pu les utiliser. Apprendre sans mettre en application, c’est bien peu gratifiant. J’étais bloquée sur un palier et je n’avançais plus du tout.

Alors, il est arrivé quelque chose qui m’a terriblement effrayée en tant que nouvelle contributrice qui essaie de naviguer dans le monde de l’open source. J’avais trouvé un bug qui avait l’air assez facile dans un grand projet renommé.

J’ai pensé qu’il valait mieux demander quelques éclaircissements avant de procéder à la moindre modification car je craignais de tout bousiller. J’ai donc envoyé un commentaire indiquant que j’étais une nouvelle contributrice, et demandant quelle serait la meilleure manière de modifier un bout de texte pour corriger le bug.

La réponse que je reçus fut :

« Si tu n’arrives pas à déterminer comment effectuer cette modification, c’est que tu n’es pas qualifiée pour effectuer cette modification. »

Cette réponse me laissa complètement décontenancée, et m’effraya davantage encore à l’idée de poser des questions lorsque je ne comprenais pas quelque chose à propos d’un projet.

Peut-être étais-je indésirable parce que je n’en savais pas assez ? Peut-être devais-je travailler davantage pour acquérir des compétences au lieu de poser des questions stupides et maladroites à des personnes expérimentées beaucoup trop occupées pour me répondre ?

C’est aussi à cette époque que ma recherche d’un mentor a commencé. J’ai pensé que si je connaissais quelqu’un avec qui je serais plus à l’aise pour poser des questions, les choses se passeraient bien et je pourrais me rendre plus utile.

J’ai donc écrit à de nombreuses personnes en leur demandant de m’aider à débuter, vu que je me sentais particulièrement intimidée par mes précédentes expériences. J’ai reçu beaucoup de réponses positives, pleines d’encouragements, mais je n’ai jamais exactement trouvé ce que je cherchais.

J’avais l’impression de buter contre un environnement clos dans le monde ouvert de l’open source.

Tout semblait suggérer que je n’avais qu’à m’y mettre et à ne pas avoir peur. Mais je n’étais pas prête à ce moment là.

Moi, fuyant le monde du logiciel open source

Ma découverte de Mozilla

Par une belle soirée, alors que je cherchais des bugs à corriger, j’ai atterri sur le projet de Mozilla qui vous aide à tester des extensions web. J’étais contente de voir qu’il y avait quelques problèmes étiquetés comme « premier bug facile » mais aucun d’entre eux n’était aussi simple que de corriger une petite coquille.

Bon sang, j’en suis tellement heureuse maintenant.

J’ai commencé à travailler sur l’un de ces bugs, mais j’ai vite compris qu’il me faudrait poser des questions si je voulais être capable de résoudre le problème. J’ai parcouru le code source. Après avoir compris les grandes lignes du problème, j’ai demandé plus d’informations. et voila ! J’ai été capable de résoudre le problème une fois que j’ai eu tous les détails nécessaires.

Maintenant que j’ai soumis trois pull requests [NDT : demandes de modification du code source] (l’une a été acceptée, les deux autres sont en passe de l’être), je suis heureuse d’avoir franchi le pas. Je suis contente de ne pas avoir hésité à poser des questions pertinentes, même si je risquais parfois d’avoir l’air de poser des questions stupides.

Ce n’est pas un problème de ne pas tout savoir et de progresser par étapes pour apprendre quelque chose de nouveau.

Les gens de Mozilla qui encadrent ces corrections m’ont beaucoup aidée et ont toujours été très positifs. Ils m’ont guidée du début à la fin, prenant le temps de m’expliquer les choses de façon à la fois simple et très détaillée. Et cela malgré le fait qu’ils n’auraient mis que quelques heures à corriger ces problèmes eux-mêmes au lieu de prendre le temps de me guider vers une solution de mon cru, dont la conception m’a pris plusieurs jours.

J’ai appris et découvert énormément de choses juste en travaillant sur ces trois problèmes basiques. Et je suis vraiment excitée à l’idée de travailler sur des problèmes encore plus difficiles et d’augmenter ma compréhension de ce sujet et mes connaissances.

l'insatiable vieux dino de Mozilla se goinfre de bugs
l’insatiable vieux dino de Mozilla se goinfre de bugs

Je ne peux pas les remercier assez pour cette expérience tellement positive et enrichissante, qui m’amène à installer Firefox localement et à parcourir les bugs sur Bugzilla un jour sur deux (je garde mes questions sur « Pourquoi » et « Comment » pour un billet plus long).

Je prévois de contribuer à Mozilla aussi régulièrement que possible. À chaque fois que j’ai posé une question pertinente, que ce soit sur IRC, Github ou Bugzilla, j’ai reçu des réponses très aimables.
Jusqu’à aujourd’hui, j’ai résolu trois problèmes dans web-ext, et j’ai eu un correctif accepté et intégré dans Firefox.

Mes contributions ont été remarquées par la communauté, et j’ai aussi été nommée dans le « Addons Contribution Recognition document » [NdT : la liste des contributeurs aux extensions de Mozilla].

En définitive, mes expériences de ces dernières semaines ont été vraiment merveilleuses. J’ai appris tellement de choses, petites et grandes, qu’aucun manuel de programmation n’aurait pu m’apprendre.
Voici mes conseils pour les développeurs débutants qui veulent contribuer à un projet open source :

Conseil n°1 : n’ayez pas peur de poser des questions

Je ne saurais trop insister sur ce point. J’ai perdu beaucoup de temps parce que je ne cessais de me censurer, et c’était ma plus importante inhibition.

Tout le monde a peur de paraître stupide. Mais ne laissez pas cette peur paralysante devenir une entrave à votre progression.

Il est normal de demander si vous ne comprenez pas quelque chose qui est en rapport avec le projet. Les développeurs du projet sont devenus des experts au fil des années. Ils peuvent vous aider très rapidement. Sinon vous risquez de perdre des heures le nez dans le code source à essayer de deviner quelque chose que vous n’êtes même pas censés savoir au départ.

Mais quand vous demandez des informations, vérifiez si elles ne sont pas déjà disponibles dans une documentation ou une recherche Google. Ainsi, vous prendrez garde à respecter le temps libre des développeurs du projet.

Conseil n°2 : c’est normal d’avoir des lacunes

On ne s’attend pas à ce que vous sachiez tout de A à Z lorsque vous commencez à contribuer à un projet. Le processus, c’est plutôt que vous appreniez et gagniez en compétence en résolvant des problèmes de plus en plus difficiles, et en vous familiarisant avec le projet et les outils qu’il utilise. Le temps nécessaire pour cela varie d’un projet à l’autre et d’une personne à l’autre.

Conseil n°3 : lancez-vous !

Ne perdez pas un temps considérable à choisir le projet idéal. Si vous connaissez un projet ou une organisation dont la communauté accueille amicalement les débutants, faites-en votre point de départ.

Trouvez un problème avec lequel vous êtes à l’aise, de préférence dans un langage que vous pratiquez déjà depuis un moment, et essayez d’imaginer ce qui a besoin d’être fait. Demandez des informations pertinentes afin de combler vos lacunes, et après, lancez-vous ! N’attendez pas.

Merci à tous ceux qui travaillent dans l’open source

Une dédicace spéciale à tous les contributeurs aux projets open source qui sont super réactifs et qui encouragent les nouveaux. Vous aidez les nouveaux venus à se frayer un chemin au milieu d’interminables lignes de code et les faites contribuer de manière peut-être limitée mais néanmoins significative. Vos efforts sont nécessaires et sincèrement appréciés.

En tant que débutante et développeuse junior, j’essaie juste de trouver mon chemin dans le vaste et formidable monde de l’informatique. Quelques minutes de votre temps, que ce soit pour me présenter une simple technique de débogage ou pour me montrer comment écrire correctement des tests logiciels, m’aideront, au fil du temps, à devenir une meilleure développeuse.

Vous avez l’expérience et j’ai l’envie insatiable d’apprendre autant que je peux.

Un grand merci à Guido, Kumur McMillan et Luca qui ont été de fabuleux mentors tout au long de ce parcours, ils m’ont suivie à chaque instant et ont répondu à mes diverses questions. J’ai vraiment apprécié le temps et les efforts que vous m’avez consacrés 🙂

Si vous êtes un nouveau venu qui peine à entrer dans le monde de l’open source, j’aimerais que vous me parliez de votre histoire et de votre expérience. Si je peux vous aider de quelque façon que ce soit, surtout n’hésitez pas à me contacter.

J’envisage de rendre compte de mon parcours chez les contributeurs de l’open source, donc si vous désirez que j’aborde un sujet en particulier, merci de laisser un commentaire.
Merci à Pawan Dubey et Quincy Larson pour m’avoir aidée à peaufiner cet article.




Une contributrice du noyau Linux jette l’éponge

Sarah Sharp a de multiples passions sympathiques comme on peut le voir sur la page où elle se présente : développeuse, cycliste, jardinière… et geek. Si nous choisissons aujourd’hui de lui donner un écho francophone, c’est parce qu’elle est libriste de longue date et qu’elle a travaillé pendant sept ans dans l’équipe qui gère et maintient le kernel Linux, c’est-à-dire le noyau du système.

Dans un billet sans acrimonie ni attaque ad hominem, elle explique nettement pourquoi elle a cessé d’apporter sa contribution à ce haut niveau de programmation : lassée d’un mode de communication qui tolère et justifie la brutalité entre ses membres, elle regrette que l’équipe du kernel n’ait pas su évoluer vers des rapports humains plus acceptables.

Elle soulève ici une question désagréablement lancinante, celle du délicat respect de chacun ; il n’est pas indifférent qu’une fois encore ce soit une femme qui estime n’avoir plus sa place au sein d’une équipe de développement. Puisse cet exemple nourrir la réflexion et contribuer à faire évoluer un peu les esprits.

Notez que ce texte critique qui a eu un certain retentissement a été suivi d’un volet plus « constructif » de Sarah Sharp, dans lequel elle propose cinq niveaux et appelle à un changement culturel de fond dans les communautés libristes , ce qui est certes plus complexe que de s’abriter derrière l’alibi d’un code de conduite…

 

Tourner la page

par Sarah Sharp, article original sur son blog : Closing a door.
Traduction Framalang : Sphinx, audionuma, r0u, goofy, line

Sarah Sharp, programmeuse
Voilà un an que ce billet est dans mon répertoire de brouillons. Ce n’était jamais le bon moment pour le publier. je m’inquiétais toujours des contrecoups. Cela fait un bon moment que je tourne autour de l’idée d’évoquer ce sujet en public, mais mon propre refus de reconnaître ce problème a fini par me ronger complètement. Alors le voici.

En un mot : je ne suis plus développeuse du noyau Linux. J’ai transféré en douceur la maintenance du pilote du contrôleur USB 3.0 en mai 2014. En juin 2015, j’ai mis fin à mon rôle de coordinatrice du programme d’ouverture aux femmes du logiciel libre (OPW), et j’ai évolué pour aider à coordonner le programme Outreachy. Le 6 décembre 2014, j’ai animé ce que j’espère être ma dernière présentation sur le développement du noyau Linux. On m’a demandé de coordonner la conférence Linux Plumbers à Seattle en août 2015 et j’ai refusé. La fin de mon mandat au Linux Advisory Board approche et je ne serai pas candidate à ma réélection.

Si j’avais le choix, je n’enverrai jamais plus un correctif, un rapport de bug ou une proposition sur les listes de discussion du noyau Linux. Mes boîtes de réception personnelles ont regorgé de messages de cette liste et je les ai ignorés. Mon travail actuel sur l’activation des modes graphiques dans l’espace utilisateur nécessitera peut-être que j’envoie occasionnellement des correctifs du noyau, mais je sais que je vais passer au moins une journée à craindre les éventuels retours destructeurs de l’interaction avec la communauté qui gère le noyau avant d’envoyer quoi que ce soit.

Je ne fais plus partie de la communauté du noyau Linux.

C’est le résultat d’une longue période de réflexion, et de beaucoup de temps passé à planifier ma succession. Je n’ai pas pris à la légère cette décision de me retirer. Je me suis sentie coupable, pendant longtemps, de ce retrait. Quoi qu’il en soit, j’ai finalement pris conscience que je ne pouvais plus contribuer à une communauté au sein de laquelle j’étais respectée sur le plan technique, mais où je ne pouvais pas demander à être respectée en tant que personne. Je ne pouvais plus travailler avec des gens qui encouragent les nouveaux venus à envoyer des correctifs, et réclament ensuite le droit pour les « mainteneurs » de cracher n’importe quelle grossièreté qu’ils considèrent nécessaire pour conserver une honnêteté affective radicale. Je ne voulais plus travailler professionnellement avec des gens qui s’en sortent malgré leurs blagues subtilement sexistes ou homophobes. Je me sens désarmée devant une communauté qui a un « code de résolution des conflits » qui ne contient même pas une liste explicite de comportements à éviter et une communauté qui n’a pas la volonté de faire appliquer ce code.

J’ai le plus grand respect pour les efforts techniques accomplis par la communauté du noyau Linux. Elle a développé un projet qui se concentre sur le respect des meilleurs standards de code qui existent. La focalisation sur l’excellence technique, la surcharge de travail des mainteneurs et la collaboration entre personnes qui proviennent de différentes cultures et normes sociales sont trois facteurs qui expliquent que les mainteneurs du noyau Linux sont souvent directs, grossiers voire brutaux pour que le travail soit fait. Les meilleurs développeurs du noyau Linux se crient souvent dessus pour corriger mutuellement leur comportement.

Ce type de communication ne me convient pas du tout. J’ai besoin d’une communication qui puisse être brutale sur le plan technique tout en étant respectueuse sur le plan personnel. J’ai besoin que quelqu’un puisse me corriger lorsque je fais une erreur (qu’elle soit technique ou sur le plan social) sans pour autant me faire descendre en tant que personne. Nous sommes humains, nous commettons des erreurs et nous les corrigeons. Nous nous énervons envers quelqu’un, nous sur-réagissons, et puis nous nous excusons et essayons de travailler ensemble pour trouver une solution.

J’aurais préféré que la communication au sein de la communauté du noyau Linux se passe de manière plus respectueuse. J’aurais préféré que les mainteneurs du noyau Linux communiquent de façon plus saine quand ils sont contrariés. J’aurais préféré que davantage de personnes assurent la maintenance du noyau Linux, ainsi ils n’auraient pas eu à être aussi brusques et directs.

Malheureusement, les changements de comportement que j’aimerais voir dans la communauté du noyau Linux ne se produiront sans doute pas de sitôt. Plusieurs développeurs seniors du noyau Linux approuvent le fait que les mainteneurs puissent être durs sur les plans technique et personnel. Même si à titre personnel ce sont des gens charmants, ils ne veulent pas que le mode de communication du noyau Linux change.

Cela veut dire qu’ils font passer les besoins affectifs des autres développeurs du noyau Linux (faire tomber la pression en se défoulant sur les autres, en étant brutal, impoli ou grossier) avant mes propres besoins affectifs (le besoin d’être respectée en tant que personne, et de ne pas être la cible de violence psychologique ou d’injures). C’est une dynamique perverse qui privilégie la position des mainteneurs établis au mépris du respect fondamental de l’être humain.

Je ne publie pas ce message à l’attention des développeurs du noyau. Je ne publie pas ce message pour pointer du doigt des personnes précises. Je publie ce message parce que je suis affligée pour la communauté dont je ne souhaite plus faire partie. Je poste ce message car je suis triste à chaque fois que quelqu’un me remercie de revendiquer de meilleures normes pour la communauté, parce que j’ai finalement abandonné l’idée de changer la communauté du noyau Linux. Le changement de culture est un processus long et douloureux et je n’ai plus l’énergie pour prendre une part active à ce changement de mentalité dans la communauté du noyau.

J’ai l’espoir que la communauté du noyau Linux évoluera avec le temps. J’ai participé à cette évolution, et la documentation, les tutoriels et les programmes que j’ai initiés (comme les stages noyau Outreachy) continueront à se développer en mon absence. Je reviendrai peut-être un jour, lorsque les choses iront mieux. J’ai une carrière de plusieurs décennies devant moi. Je peux attendre. En attendant, il existe d’autres communautés du logiciel libre, plus amicales, où je peux jouer ma partition.

Lorsqu’une porte se ferme, une autre s’ouvre, mais souvent nous restons si longtemps et avec tant de regrets devant la porte fermée que nous ne voyons même pas celle qui vient de s’ouvrir devant nous.

— Alexander Graham Bell

 

________

Crédits image :

  • Photo  © Sarah Sharp licence CC-BY-NC-SA



Google Code ferme ses portes ? Nous, on les ouvre.

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) 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 ?

Pas touche à MES données.

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 ?

Forge logicielle Gitlab

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… »

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 !

 

Mise à jour du 5/08/2016 :
Le tutoriel d’installation de Gitlab est -enfin- disponible sur le Framacloud.
Notez que cette installation est conjointe à celle de Mattermost (Framateam) puisque c’est ainsi que nous avons procédé 😉



J’aime le logiciel libre

Aujourd’hui, c’est la Saint Valentin, et l’occasion de déclarer son amour des logiciels libres !

ilovefs-banner-extralarge

Framasoft vous a déjà proposé son adaptation délirante de poèmes pour l’occasion, et voici une petite bande-dessinée qui synthétise l’événement :

dm_001_jaime_le_logiciel_libre

Cette bande-dessinée est extraite du nouveau blog Grise Bouille hébergé par Framasoft.

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)




On <3 le logiciel libre !

Aujourd’hui, ce n’est pas un jour comme les autres. Journée de l’amour pour les uns, journée commerciale à bougonner pour les autres, elle ne laissera personne indifférent. Pourquoi ne lui donner une dimension toute différente, en en profitant pour déclarer notre amour aux logiciels libres, et aux développeurs du libre que nous torturons à longueur d’année, en bons utilisateurs exigeants et spécialistes du yakafokon que nous sommes.

C’est ce que nous propose la FSF avec sa campagne I love Free software, reconduite cette année. Il est important parfois de savoir lâcher prise pour clamer haut et fort que nous les aimons, ces logiciels libres.

Nous avons choisi pour notre part de vous proposer un fork de poèmes que vous devez tous connaître… Demain dès l’aube, de Victor Hugo et Le dormeur du Val d’Arthur Rimbaud.

 

ilovefs-banner-extralarge

Demain dès l’aube (v1.337)

Demain, dès l’aube, à l’heure des châteaux en Espagne,
Je râlerai. Vois-tu, je sais que tu m’entends.
De toi j’exigerai de coder des montagnes.
Je ne puis retenir mes commits plus longtemps.

Ce jour, je te le souhaite sans bug à obvier,
Nulle exigence en moi, nulle attente s’induit,
Seul, ton labeur, le dos courbé, mains au clavier,
Fier, voit le fruit de l’écran qui a blanchi tes nuits.

Je ne t’apporterai ni les bitcoins qui tombent,
Ni le vert des dollars qui ternit leur valeur,
Mais bientôt avec toi nous ferons la bombe
Une main sur la bière et l’autre sur le cœur.

 

Le codeur d’eval()

(v. 4.2)

Dans un réduit obscur il chante une rengaine
Enchaînant follement les semaines aux semaines,
Content quand des lignes obscures s’empilent
Et il boit du maté quand son code compile.

Un codeur jeune, Git ouvert, tête nue
Et la face baignant dans de frais rayons bleus
Dort ; il est vautré dans le PHP chenu
Pâle dans son t-shirt geek au Tux globuleux

Les mains dans le cambouis, il dort. Souriant comme
Sourirait un géant, ce n’est pourtant qu’un homme :
Le livreur de pizzas seul nourrit cet ermite.

Les crashtests, il s’en est déjà bien trop nourri ;
Il dort sur son clavier, la main sur la souris,
Tranquille. Il a deux bugfix dans son commit.

ilovefs-heart-px

Plein de datalove à vous !

Chez Framasoft, on ne code pas (ou très peu). On utilise le code développé par des personnes formidables, par des communautés de passionné-e-s, et on le propose au grand public sous forme de services libres et gratuits.

Nous tenons donc aujourd’hui à déclarer notre amour aux équipes développant Etherpad (Framapad), Ethercalc (Framacalc), studs & le fork framadate, Wisemapping et Mindmaps (FramindMap), SVG-Edit (Framavectoriel), TinyTinyRSS (Framanews), Wallabag (Framabag), Diaspora* (Framasphère)… et tant d’autres !

Et un spécial chaton d’amour aux équipes (et à la fondation Mozilla) derrière FireFox qui vous permettent  d’utiliser ces applications web depuis un navigateur Libre.