Des étudiants de l’Université de Technologie de Compiègne effectuent, dans le cadre de leur cursus, des Travaux de Laboratoire consistant à avancer sur des tickets du projet Framadate (qui n’en manque pas), avec le soutien de leur enseignant Stéphane Crozat (dont on vous reparlera) et du CHATONS local Picasoft. Leurs travaux sont documentés dans un wiki et leur avancement dans des pads.

De la belle contribution utile !

---

Pour commencer, une petite présentation s’impose : je m’appelle Justine et je suis en première année de formation ingénieur en informatique à l’UTC (Université de Technologie de Compiègne). Lors de ce semestre, c’est-à-dire lors des quatre derniers mois, et dans le cadre de ma formation (ce travail, après évaluation, pourra m’apporter 5 crédits ECTS), j’ai eu l’occasion de contribuer au logiciel libre Framadate. Cet article se veut être un bilan de mon expérience.

 

Contribuer à un logiciel libre, était-ce différent d’un projet « classique » ?

À l’UTC, les étudiants sont évalués selon des barèmes différents d’une matière à l’autre. En informatique, l’évaluation comprend souvent un projet (qui ne correspond pas souvent à plus de 20% de la note finale). Ce projet a des objectifs largement pertinents, comme vérifier sur un cas pratique que les étudiants ont assimilé la théorie qui leur a été enseignée. Cependant, j’ai souvent éprouvé une certaine frustration vis-à-vis  de ces projets. En effet, une fois rendu, évalué et donc noté, le projet tombe dans l’oubli : pas d’utilisation réelle, pas d’amélioration, une sorte de produit déjà mort à sa sortie. Ainsi, l’idée de travailler sur un logiciel  libre, avec des utilisateurs bien réels derrière, m’a semblé extrêmement pertinente et bien différente des projets que j’avais déjà pu mener.

Est ce que ces différences ont entraîné des difficultés ?

Les premières difficultés rencontrées ont été celles posées par l’installation et la prise en main de l’environnement de travail, proposé par les suiveurs. Alors que la plupart du temps, pour mener à bien les projets classiques, les installations des environnements sont déjà faites sur les machines de l’UTC, cela n’était pas le cas cette fois. Composé de nombreux outils (principalement Docker et Git au sein de Linux), l’installation de notre environnement a été relativement lourde et laborieuse. Une fois installé, l’environnement est au premier abord difficile à prendre en main : de nombreuses lignes sont à exécuter dans l’interpréteur de commandes avant de pouvoir tester le code.

Mais les difficultés les plus compliquées à surmonter ont été celles posées par le projet en lui-même. D’abord parce que les langages utilisés (SQL, PHP orienté objet, Javascript, HTML via le moteur de templates Smarty…) ne m’étaient pas ou peu connus. Ensuite, et surtout, parce qu’il m’a paru très compliqué de m’insérer dans un projet déjà bien développé (dans un projet « classique » à l’UTC, on part de rien, on développe tout), projet dont l’architecture n’est pas (ou très peu) documentée. Sa compréhension a donc nécessité beaucoup de temps et d’efforts, j’y reviendrai.

Comment s’est organisée ta contribution ?

Cette contribution a été organisée selon une méthode de type agile : le travail est découpé en itérations de six heures chacune, une itération par semaine. Le semestre a ainsi été rythmé par des réunions de suivi hebdomadaires avec les suiveurs, Stéphane Crozat et Andrés Maldonado, chargés d’accompagner et d’évaluer le travail. Sur chaque itération, nous déterminions donc ensemble l’objectif à atteindre pour la semaine suivante, et je déterminais seule l’articulation de mon travail (combien d’heures je devais passer à réaliser telle tâche). La contribution s’est articulée en deux volets : un volet de développement (qui consistait en la résolution de trois issues ouvertes sur le projet) et un volet de documentation (via le wiki de l’association Picasoft).

Concrètement, qu’as-tu apporté à Framadate ?

Comme évoqué plus haut, l’architecture du projet n’était que très peu documentée. Ainsi, afin de travailler efficacement sur le projet, j’ai préféré commencer par passer plusieurs heures (concrètement une vingtaine) à explorer le projet et documenter au maximum ce que j’en comprenais (les classes implémentées, leur articulation au sein du projet…). Un travail étudiant comme celui-ci est aussi l’occasion d’apprendre à formaliser et documenter, mon travail est disponible ici.

Ce n’est que dans un second temps que j’ai réellement commencé mon travail de résolution d’issues, et donc de développement et de documentation du travail réalisé. J’ai préféré travailler ces deux volets en parallèle, afin de restituer le travail réalisé lorsque tout était encore frais dans mon esprit. J’ai ainsi pu travailler sur trois issues :

Issue #38 : collecter les adresses e-mail des sondés
L’idée est de permettre à l’administrateur de choisir de collecter (ou non) les adresses e-mail des sondés. Si l’administrateur choisit la collecte, alors la saisie d’une adresse de courriel valide (respectant le format e-mail) est obligatoire pour voter. La collecte s’accompagne d’une fonctionnalité permettant à l’administrateur de récupérer efficacement l’ensemble des adresses des personnes sondées.

 

 

 

 

Issue #324 (et #61) : Amélioration de l’option de collecte des adresses e-mail des personnes sondées. L’idée était d’améliorer le travail réalisé précédemment en passant la collecte des adresses de courriel sous quatre options différentes :

• option 1 : la collecte est désactivée ;
• option 2 : la collecte est activée ;
• option 3 : la collecte est activée et la saisie est obligatoire ;

option 4 : la collecte est activée, la saisie est obligatoire et le vote doit être confirmé par un clic sur le lien envoyé dans un mail à l’adresse renseignée (cette dernière option n’a pas été implémentée car le service d’envoi d’e-mail est inutilisable au sein de l’installation).

 

Issue #208 : permettre la finalisation d’un sondage par l’administrateur
L’idée était d’ajouter une fonctionnalité pour l’administrateur de clôture de sondage et de lui permettre :

• de sélectionner le choix retenu ;
• de justifier son choix.

 

Chacune de ces résolutions d’issues a fait l’objet d’une merge-request. C’est un processus itératif très intéressant à découvrir au sein duquel on peut interagir avec les développeurs logiciel et web de Framasoft qui vont vérifier le travail proposé et en demander des corrections.

Tout au long de mon travail, j’ai pu ainsi interagir avec différents interlocuteurs : les suiveurs bien sûr, Stéphane Crozat et Andrés Maldonado, mais aussi Thomas Citharel, développeur logiciel web chez Framasoft, et Kyâne Pichou, diplômé de l’UTC. Je tiens à remercier tous ces interlocuteurs pour leur soutien et leurs conseils, je pense qu’il est indispensable d’être bien accompagnés dans ce processus de contribution afin qu’il soit efficace et utile à tous.

Finalement, quels sont les apports au sein de ta formation ?

Contribuer à Framadate m’a d’abord permis de gagner en compétences d’utilisation des outils utilisés (Docker, Git, Linux) et en développement web : interface, base de données,…. Mais cette contribution m’a surtout fait gagner énormément d’indépendance et d’autonomie vis-à-vis d’un projet déjà existant et bien développé, ce qui est très formateur et pertinent en amont de mon futur stage (six mois en entreprise à partir de septembre).

Que faudrait-il retenir de cet article ?

Contribuer à un logiciel libre au sein de la formation en école d’ingénieur constitue une expérience très pertinente pour compléter le profil théorique et « scolaire » d’un étudiant. Cette expérience permet de faire face à de nouvelles difficultés, et ainsi développer de toutes nouvelles aptitudes.

 

En savoir plus :

ECTS : European Credits Transfer System, calculés en fonction de la charge de travail de l’étudiant , ils permettent l’obtention des diplômes français (et européens).

Picasoft est le CHATON créé par les étudiants de l’UTC.

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

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

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.

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.

É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 !

Le projet de réforme du droit d’auteur provoque une forte inquiétude au sein des communautés de développeurs et développeuses de logiciels libres. Que restera-t-il de leur liberté de partager et modifier si obligation est faite aux forges logicielles de mettre en place des filtres de contenus ? L’eurodéputée Julia Reda nous indique les façons dont nous pouvons tous agir, dès maintenant.

 

« Les machines à censurer arrivent : il est temps que la communauté du logiciel libre prenne conscience de son impact politique »

 

Source : article rédigé par l’eurodéputée Julia Reda et publié sur son site le 6 avril 2018

Traduction initialement publiée par l’April : Guestr, Alain Mille, etienne, mmu_man, tierce, Vanecx, mo, MicroCheapFx, freepoet, yannicka, Fred.

Le développement du logiciel libre tel que nous le connaissons est menacé par les projets de réforme du droit d’auteur de l’Union européenne.

La bataille continue autour de la proposition de réforme du droit d’auteur dans l’UE, se concentrant autour du projet de filtrer les contenus au moment de leur téléversement (en anglais). En résumé, on demanderait aux plateformes en ligne de contrôler les contenus chargés par leurs utilisateurs et utilisatrices afin de tenter de prévenir les violations du droit d’auteur par des filtres automatiques. Puisque la plupart des communications en ligne consistent en un dépôt de fichiers sur différentes plateformes, de telles « machines à censurer » auraient de larges conséquences, y compris pour les dépôts de logiciels libres et open source.

Sur ces plateformes, des développeurs et développeuses du monde entier travaillent de concert sur des projets de logiciels que quiconque peut librement utiliser et adapter. À coup sûr, ces filtres automatiques feraient état de nombreux faux-positifs. La suppression automatique de contenus signifierait que les personnes ayant contribué seraient présumées coupables jusqu’à prouver leur innocence : des contributions légitimes se verraient bloquées.

Les récentes levées de boucliers à ce sujet au sein de la communauté du logiciel libre/open-source commencent à porter leurs fruits : nos préoccupations sont en train d’attirer l’attention des porteurs de lois. Malheureusement cependant, la plupart comprennent mal les enjeux et tirent de mauvaises conclusions. Maintenant que nous savons quelle est la force de la voix de la communauté, il est d’autant plus important de continuer à la faire entendre !

Pourquoi cela ?

Le point de départ de cette législation a été une bataille entre de grosses entreprises, l’industrie musicale et YouTube, à propos d’argent. L’industrie musicale s’est plainte de moins percevoir chaque fois qu’un morceau de leur catalogue est joué sur une plateforme vidéo comme YouTube que lorsqu’il est diffusé sur des services d’abonnement comme Spotify, qualifiant la différence de « manque-à-gagner ». Elle s’est alors lancée, avec succès, dans une campagne de lobbying : la loi sur le filtrage des contenus vise principalement à lui donner un atout afin de demander plus d’argent à Google au moment des négociations. Pendant ce temps, toutes les autres plateformes se retrouvent au milieu de cette bagarre, y compris les communautés de partage de code.

Le lobbying a ancré dans l’esprit de nombreux législateurs la fausse idée que les plateformes d’hébergement à but lucratif exploitent nécessairement les créateurs et créatrices.

Partage de code

Il y a cependant beaucoup d’exemples où il existe une relation symbiotique entre la plateforme et les créateurs et créatrices. Les développeurs et développeuses utilisent et versent volontairement dans les dépôts logiciels parce que les plateformes ajoutent de la valeur. GitHub est une société à but lucratif qui soutient des projets sans but lucratif – elle finance l’hébergement gratuit de projets libres et open source en facturant l’utilisation commerciale des services du site. Ainsi, des travaux libres et open source seront affectés par une loi destinée à réguler un différend entre quelques grandes sociétés.

Dans un récent billet (en anglais), GitHub a tiré la sonnette d’alarme, indiquant trois raisons pour lesquelles le filtrage automatique des contenus constitue une terrible attaque contre les forges logicielles :

1. la loi impose que le code soit filtré parce qu’il est soumis au droit d’auteur – mais de nombreux développeurs et développeuses souhaitent que leur code source soit partagé sous une licence libre et open source ;
2. le risque de faux positifs est très élevé parce que les différentes parties d’un logiciel peuvent être soumises à des licences différentes, ce qui est très difficile à traiter de manière automatisée ;
3. le fait de supprimer automatiquement un code suspecté de porter atteinte au droit d’auteur peut avoir des conséquences désastreuses pour les développeurs et développeuses de logiciels qui s’appuient sur des ressources communes risquant de disparaître à tout moment.

Les inquiétudes commencent à être entendues

Dans sa dernière proposition, le Conseil de l’Union européenne cherche à exclure « les plateformes de développement open source à but non lucratif » de l’obligation de filtrer les contenus chargés par les utilisateurs et utilisatrices. Cet amendement est la conséquence directe de la levée de boucliers par la communauté FLOSS. Cependant, cette exception ne couvre pas les plateformes à but lucratif comme GitHub et bien d’autres, même si une partie seulement de leur activité est à but lucratif.

Plutôt que de remettre en cause le principe de base de la loi, les politiciens essayent d’étouffer les critiques en proposant de plus en plus d’exceptions à celles et ceux qui peuvent démontrer de façon crédible que la loi va les affecter négativement. Créer une telle liste d’exceptions est une tâche titanesque vouée à rester inachevée. Le filtrage des contenus devrait être rejeté dans son ensemble car c’est une mesure disproportionnée mettant en danger le droit fondamental de la liberté d’expression en ligne.

Nous pouvons y arriver !

Pour y parvenir, nous avons besoin de votre aide. La communauté FLOSS ne peut pas résoudre ces problèmes simplement avec du code : elle a un impact politique, la force du nombre et des allié⋅e⋅s au Parlement (européen). Nous avons déjà provoqué certains changements. Voici comment vous pouvez agir dès maintenant :

1. signez la lettre ouverte sur SaveCodeShare (Note de traduction : en anglais, voir l’article de l’April qui soutient cette campagne) ;
2. utilisez l’outil gratuit de Mozilla pour appeler les membres du Parlement européen ;
3. tweetez aux principaux acteurs de la Commission des affaires légales du Parlement européen via FixCopyright (en anglais).

Note technique :

Trois acteurs sont impliqués dans le processus législatif. La Commission émet une première proposition de loi, à laquelle le Parlement européen et le Conseil de l’Union européenne peuvent proposer des amendements. Au sein du Parlement, la loi est d’abord discutée en Commission des affaires légales dans laquelle chaque groupe politique nomme un négociateur. Une fois que la Commission aura voté le compromis élaboré par les négociateurs, le texte sera soumis au vote en séance plénière du Parlement, avant que les négociations ne commencent avec les autres institutions. Le parcours législatif exact est disponible ici (en anglais).

Dans la mesure du possible et conformément à la loi, l’auteur [Julia Reda] renonce à tous les droits d’auteur et droits voisins sur ce texte.

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

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

= 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.

Quand un libriste s’amuse à reprendre et développer spectaculairement un petit Framaprojet, ça mérite bien une interview ! Voici Valvin, qui a dopé notre, – non, votre Geektionnerd Generator aux stéroïdes !

Gégé, le générateur de Geektionnerd, est un compagnon déjà ancien de nos illustrations plus ou moins humoristiques. Voilà 4 ans que nous l’avons mis à votre disposition, comme en témoigne cet article du Framablog qui vous invitait à vous en servir en toute occasion. Le rapide historique que nous mentionnions à l’époque, c’est un peu une chaîne des relais qui se sont succédé de William Carvalho jusqu’à Gee et ses toons en passant par l’intervention en coulisses de Cyrille et Quentin.

Vous le savez, hormis le frénétique Luc qu’on est obligés de piquer d’une flèche hypodermique pour l’empêcher de coder à toute heure, on développe peu à Framasoft. Aussi n’est-il guère surprenant que ce petit outil ludique soit resté en sommeil sans évolution particulière pendant ces dernières années où la priorité allait aux services de Dégooglisons.

Enfin Valvin vint, qui à l’occasion de l’ajout d’une tripotée de nouveaux personnages se mit à coder vite et bien, poursuivant avec la complicité de Framasky – ô Beauté du code libre ! – la chaîne amicale des contributeurs.

Mais faisons connaissance un peu avec celui qui vient d’ajouter généreusement des fonctionnalités sympathiques à Gégé.

Commençons par l’exercice rituel : peux-tu te présenter pour nos lecteurs et lectrices. Qui es-tu, Valvin ?

Salut Framasoft, je suis donc Valvin, originaire de Montélimar, j’habite maintenant dinch Nord avec ma petite famille. Je suis un peu touche-à-tout et il est vrai que j’ai une attirance particulière pour le Libre mais pas uniquement les logiciels.

 

Qu’est-ce qui t’a amené au Libre ? Tu es tombé dedans quand tu étais petit ou bien tu as eu droit à une potion magique ?

J’ai commencé en tant qu’ingénieur sur les technologies Microsoft (développement .NET, Active Directory, SQL Server…) J’avais bien commencé non ? Puis Pepper m’a concocté une potion et puis …. vous savez qu’elle ne réussit pas souvent ses potions ?

Plus sérieusement lors de mon parcours professionnel, j’ai travaillé dans une entreprise où Linux était largement déployé, ce qui m’a amené à rencontrer davidb2111, libriste convaincu depuis tout petit (il a dû tomber dans la marmite …). Et je pense que c’est lui qui m’a mis sur la voie du Libre…

Cependant ce qui m’a fait passer à l’action a été la 1^re campagne « Dégooglisons Internet »… Elle a débuté juste après mon expérience de e-commerce, quand je gérais un petit site web de vente en ligne où j’ai découvert l’envers du décor : Google analytics, adwords, comparateurs de prix… et pendant que j’intégrais les premiers terminaux Android industriels.

Je suis maintenant un libriste convaincu mais surtout défenseur de la vie privée. Certains diront extrémiste mais je ne le pense pas.

Dans ta vie professionnelle, le Libre est-il présent ou bien est-ce compliqué de l’utiliser ou le faire utiliser ?
Aujourd’hui, je suis une sorte d’administrateur système mais pour les terminaux mobiles industriels (windows mobile/ce mais surtout Android). Pour ceux que ça intéresse, ça consiste à référencer du matériel, industrialiser les préparations, administrer le parc avec des outils MDM (Mobile Device Management), mais pas seulement !

Je suis en mission chez un grand compte (comme ils disent) où le Libre est présent mais pas majoritairement. On le retrouve principalement côté serveur avec Linux (CentOS), Puppet, Nagios/Centreon, PostgreSQL … (la liste est longue en fait). Après je travaille sur Android au quotidien mais j’ai un peu du mal à le catégoriser dans le Libre ne serait-ce qu’en raison de la présence des Google Play Services.

J’ai la chance d’avoir mon poste de travail sous Linux mais j’utilise beaucoup d’outils propriétaires au quotidien. (j’démarre même des fois une VM Windows … mais chuuuut !!).

Je suis assez content d’avoir mis en place une instance Kanboard (Framaboard) en passant par des chemins obscurs mais de nombreux utilisateurs ont pris en main l’outil ce qui en fait aujourd’hui un outil officiel.

On découvre des choses diverses sur ton blog, des articles sur le code et puis un Valvin fan de graphisme et surtout qui est prêt à contribuer dès qu’il y a passion ? Alors, tu as tellement de temps libre pour le Libre ?

Du temps quoi ?… Malheureusement, je n’ai pas beaucoup de temps libre entre le travail, les trajets quotidien (plus de 2 heures) et la famille. Du coup, une fois les enfants couchés, plutôt que regarder la télé, j’en profite (entre deux dessins).
Mes contributions dans le libre sont principalement autour du projet de David Revoy, Pepper & Carrot. J’ai la chance de pouvoir vivre l’aventure à ses côtés ainsi que de sa communauté. Et dans l’univers de la BD, c’est inédit ! D’ailleurs je te remercie, Framasoft, de me l’avoir fait découvrir 🙂
Si je peux filer un petit coup de main avec mes connaissances sur un projet qui me tient à cœur, je n’hésite pas. Et même si ce n’est pas grand-chose, ça fait plaisir d’apporter une pierre à l’édifice et c’est ça aussi la magie du Libre !
J’ai eu parfois l’ambition de lancer moi même des projets libres mais j’ai bien souvent sous-estimé le travail que ça représentait …

Et maintenant, tu t’attaques au geektionnerd, pourquoi tout à coup une envie d’améliorer un projet/outil qui vivotait un peu ?
Je dois avouer que c’est par hasard. J’ai vu un message sur Mastodon qui m’a fait découvrir le projet. Il n’y a pas si longtemps, je m’étais intéressé au projet Bird’s Dessinés et j’avais trouvé le concept sympa. Mais tout était un peu verrouillé, notamment les droits sur les réalisations. J’aime bien le dessin et la bande dessinée, le projet du générateur de Geektionnerd m’a paru très simple à prendre en main… du coup, je me suis lancé !

Tu peux parler des problèmes du côté code qui se sont posés, comment les as-tu surmontés  ?
Globalement, ça s’est bien passé jusqu’au moment où j’ai voulu ajouter des images distantes dans la bibliothèque. Le pire de l’histoire c’est que ça fonctionnait bien à première vue. On pouvait ajouter toutes les images que l’on voulait, les déplacer… Nickel ! Et puis j’ai cliqué sur « Enregistrer l’image » et là… j’ai découvert la magie de  CORS !

CORS signifie Cross Origin Ressource Sharing et intervient donc lorsque le site web tente d’accéder à une ressource qui ne se situe pas sur son nom de domaine.
Il est possible de créer une balise image html qui pointe vers un site extérieur du type :

<img src="https://www.peppercarrot.com/extras/html/2016_cat-generator/avatar.php?seed=valvin" alt="c'est mon avatar" />

En revanche, récupérer cette image pour l’utiliser dans son code JavaScript, c’est possible mais dans certaines conditions uniquement. Typiquement, si j’utilise jquery et que je fais :

$.get("https://www.peppercarrot.com/extras/html/2016_cat-generator/avatar.php?seed=Linux", function(data){
    $("#myImg").src = data;
});

On obtient :

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.peppercarrot.com/extras/html/2016_cat-generator/avatar.php?seed=Linux. (Reason: CORS header 'Access-Control-Allow-Origin' missing).

En revanche, si on utilise une image hébergée sur un serveur qui autorise les requêtes Cross-Origin, il n’y a pas de souci :

$.get("https://i.imgur.com/J2HZir3.jpg", function(data){
    $("#myImg").src = data;
});

Tout cela en raison de ce petit en-tête HTTP que l’on obtient du serveur distant :

Access-Control-Allow-Origin *

où `*` signifie tout le monde, mais il est possible de ne l’autoriser que pour certains domaines.
Avec les canvas, ça se passait bien jusqu’à la génération du fichier PNG car on arrivait au moment où l’on devait récupérer la donnée pour l’intégrer avec le reste de la réalisation. J’avais activé un petit paramètre dans la librairie JavaScript sur l’objet Image

image.crossOrigin = "Anonymous";

mais avec ce paramètre, seules les images dont le serveur autorisait le Cross-Origin s’affichaient dans le canvas et la génération du PNG fonctionnait. Mais c’était trop limitatif.

Bref, bien compliqué pour par grand-chose !

J’ai proposé de mettre en place un proxy CORS, un relais qui rajoute simplement les fameux en-têtes mais ça faisait un peu usine à gaz pour ce projet. Heureusement, framasky a eu une idée toute simple de téléchargement d’image qui a permis de proposer une alternative.
Tout cela a fini par aboutir, après plusieurs tentatives à ce Merge Request : https://framagit.org/framasoft/geektionnerd-generator/merge_requests/6

Et après tous ces efforts quelles sont les fonctionnalités que tu nous as apportées sur un plateau ?

Chaud devant !! Chaud !!!

• Tout d’abord, j’ai ajouté le petit zoom sur les vignettes qui était trop petites à mon goût

• Ensuite, j’ai agrandi la taille de la zone de dessin en fonction de la taille de l’écran. Mais tout en laissant la possibilité de choisir la dimension de la zone car dans certains cas, on ne souhaite qu’une petite vignette carrée et cela évite de ré-éditer l’image dans un second outil.

• Et pour terminer, la possibilité d’ajouter un image depuis son ordinateur. Cela permet de compléter facilement la bibliothèque déjà bien remplie 🙂

Merci ! D’autres développements envisagés, d’autres projets, d’autres cartoons dans tes cartons ?

D’autres développements pour Geektionnerd ? Euh oui, j’ai plein d’idées … mais est ce que j’aurai le temps ?
– intégration Lutim pour faciliter le partage des réalisations
– recherche dans la librairie de toons à partir de tags (nécessite un référencement de méta-data par image)
– séparation des toons des bulles et dialogues : l’idée serait de revoir la partie gauche de l’application et trouver facilement les différents types d’images. Notamment en découpant par type d’image : bulles / personnages / autres.
– ajout de rectangles SVG pour faire des cases de BD
– amélioration de la saisie de texte (multi-ligne) et sélection de la fonte pour le texte
– …
Je vais peut-être arrêter là 🙂

Sinon dans les cartons, j’aimerais poursuivre mon projet Privamics dont l’objectif est de réaliser des mini-BD sur le sujet de la vie privée de façon humoristique. Mais j’ai vu avec le premier épisode que ce n’était pas une chose si facile. Du coup, je privilégie mon apprentissage du dessin 🙂

Bien entendu, Pepper & Carrot reste le projet auquel je souhaite consacrer le plus de temps car je trouve que le travail que fait David est tout simplement fantastique !

Le mot de la fin est pour toi…
Un grand merci à toi Framasoft, tu m’as déjà beaucoup apporté et ton projet me tient particulièrement à cœur.

Vive le Libre !!! 🙂

• Usez et abusez de Gégé dans sa nouvelle version « turbo »  : https://framalab.org/gknd-creator/
• Comme Valvin, contribuez au code : https://framagit.org/framasoft/geektionnerd-generator

57 lignes de code et deux ou trois bidules électroniques feraient aussi bien voire mieux qu’un gros système coûteux. Telle est la démonstration que vient de faire un développeur australien.
L’expérience que relate ici Tait Brown relève du proof of concept, la démonstration de faisabilité. La spectaculaire économie de moyens numériques et financiers qu’il démontre avec 57 lignes de code open source et des appareils à la portée d’un bidouilleur ordinaire n’est peut-être pas une solution adaptable à grande échelle pour remplacer les puissants et massifs systèmes propriétaires mis en place par des entreprises. Pas plus que les services libres de Framasoft n’ambitionnent de remplacer les GAFAM, mais démontrent que des solutions alternatives libres et plus respectueuses sont possibles et viables, et de plus en plus disponibles.

Outre le pied de nez réjouissant du hacker occasionnel aux institutions locales (ici, la police de l’état australien de Victoria) qui ont confié un traitement informatique à des sociétés privées, ce petit témoignage ouvre au moins une question : le code est mis au service de la police au bénéfice des citoyens (repérer les voitures volées, pister la délinquance…), mais peut fort bien ne faire qu’augmenter la surveillance de masse au détriment des mêmes citoyens, avec les conséquences pas du tout triviales qu’on connaît et dénonce régulièrement. Le fait que le code open source soit auditable est-il un garde-fou suffisant ?

 

Comment j’ai recréé un logiciel de 86 millions de dollars en 57 lignes de code

par Tait Brown

Publication originale : How I replicated an $86 million project in 57 lines of code
Traduction Framalang : xi, Lyn., goofy, framasky, Lumibd, Penguin

Quand un essai à base de technologie open source fait le boulot « suffisamment bien ».

La police est le principal acteur du maintien de l’ordre dans l’État du Victoria, en Australie. Dans cet État, plus de 16 000 véhicules ont été volés l’an passé, pour un coût d’environ 170 millions de dollars. Afin de lutter contre le vol de voitures, la police teste différentes solutions technologiques.

Pour aider à prévenir les ventes frauduleuses de véhicules volés, VicRoads propose déjà un service en ligne qui permet de vérifier le statut d’un véhicule en saisissant son numéro d’immatriculation. L’État a également investi dans un scanner de plaque minéralogique : une caméra fixe sur trépied qui analyse la circulation pour identifier automatiquement les véhicules volés.

Ne me demandez pas pourquoi, mais un après-midi, j’ai eu envie de réaliser un prototype de scanner de plaques minéralogiques embarqué dans une voiture, qui signalerait automatiquement tout véhicule volé ou non immatriculé. Je savais que tous les composants nécessaires existaient et je me suis demandé à quel point il serait compliqué de les relier entre eux.

Mais c’est après quelques recherches sur Google que j’ai découvert que la Police de l’État du Victoria avait récemment testé un appareil similaire dont le coût de déploiement était estimé à 86 millions de dollars australiens. Un commentateur futé a fait remarquer que 86 millions de dollars pour équiper 220 véhicules, cela représentait 390 909 AUSD par véhicule.
On devait pouvoir faire mieux que ça.

 

Les critères de réussite

Avant de commencer, j’ai défini à quelles exigences clés devait répondre la conception de ce produit.

Le traitement de l’image doit être effectué localement
Transmettre en continu le flux vidéo vers un site de traitement centralisé semblait l’approche la moins efficace pour répondre au problème. La facture pour la transmission des données serait énorme, de plus le temps de réponse du réseau ne ferait que ralentir un processus potentiellement assez long.
Bien qu’un algorithme d’apprentissage automatique centralisé ne puisse que gagner en précision au fil du temps, je voulais savoir si une mise en œuvre locale sur un périphérique serait « suffisamment bonne ».

Cela doit fonctionner avec des images de basse qualité
Je n’avais ni caméra compatible avec un Raspberry Pi, ni webcam USB, j’ai donc utilisé des séquences vidéo issues de dashcam [NdT : caméra installée dans un véhicule pour enregistrer ce que voit le conducteur], c’était immédiatement disponible et une source idéale de données d’échantillonnage. En prime, les vidéos dashcam ont, en général, la même qualité que les images des caméras embarquées sur les véhicules.

Cela doit reposer sur une technologie open source
En utilisant un logiciel propriétaire, vous vous ferez arnaquer chaque fois que vous demanderez un changement ou une amélioration, et l’arnaque se poursuivra pour chaque demande ultérieure. Utiliser une technologie open source évite ce genre de prise de tête.

Solution

Pour l’expliquer simplement, avec ma solution, le logiciel prend une image à partir d’une vidéo dashcam, puis l’envoie vers un système de reconnaissance des plaques minéralogiques open source installé localement dans l’appareil, il interroge ensuite le service de contrôle des plaques d’immatriculation et renvoie le résultat pour affichage.
Les données renvoyées à l’appareil installé dans le véhicule de police comprennent : la marque et le modèle du véhicule (pour vérifier si seules les plaques ont été volées), le statut de l’immatriculation et la notification d’un éventuel vol du véhicule.
Si cela semble plutôt simple, c’est parce que c’est vraiment le cas. Le traitement de l’image, par exemple, peut être opéré par la bibliothèque openalpr. Voici vraiment tout ce qu’il faut pour reconnaître les caractères sur les plaques minéralogiques :

 openalpr.IdentifyLicense(imagePath, function (error, output) {
 // handle result
 });
 (le code est sur Github)

Mise en garde mineure
L’accès public aux API de VicRoads n’étant pas disponible, les vérifications de plaques d’immatriculation se font par le biais du web scraping (NdT : une technique d’extraction automatisée du contenu de sites web) pour ce prototype. C’est une pratique généralement désapprouvée, mais il ne s’agit ici que d’un test de faisabilité et je ne surcharge pas les serveurs de quiconque.

Voici à quoi ressemble mon code, vraiment pas propre, utilisé pour tester la fiabilité de la récupération de données :

(le code est sur Github)

Résultats

Je dois dire que j’ai été agréablement surpris.

Je m’attendais à ce que la reconnaissance des plaques minéralogiques open source soit plutôt mauvaise. De plus, les algorithmes de reconnaissance d’images ne sont probablement pas optimisés pour les plaques d’immatriculation australiennes.

Le logiciel a été capable de reconnaître les plaques d’immatriculation dans un champ de vision large.

Toutefois, le logiciel a parfois des problèmes avec des lettres particulières.

Mais… il finit par les corriger :

 

Comme vous pouvez le voir dans les deux images ci-dessus, le traitement de l’image quelques images plus tard a bondi d’un indice de confiance de 87% à un petit peu plus de 91%.

Il s’agit de solutions très simples au niveau de la programmation, qui n’excluent pas l’entraînement du logiciel de reconnaissance des plaques d’immatriculation avec un ensemble de données locales.
Je suis certain que la précision pourrait être améliorée en augmentant le taux d’échantillonnage, puis en triant suivant le niveau de confiance le plus élevé. On pourrait aussi fixer un seuil qui n’accepterait qu’une confiance supérieure à 90% avant de valider le numéro d’enregistrement.
Il s’agit de choses très simples au niveau de la programmation, qui n’excluent pas l’entraînement du logiciel de reconnaissance des plaques d’immatriculation avec un jeu de données locales.

La question à 86 000 000 dollars

Pour être honnête, je n’ai absolument aucune idée de ce que le chiffre de 86 millions de dollars inclut – et je ne peux pas non plus parler de la précision d’un outil open source sans entraînement spécifique adapté au pays par rapport au système pilote BlueNet.
Je m’attendrais à ce qu’une partie de ce budget comprenne le remplacement de plusieurs bases de données et applications logicielles existantes pour répondre à des demandes de renseignements sur les plaques d’immatriculation à haute fréquence et à faible latence plusieurs fois par seconde par véhicule.
D’un autre côté, le coût de 391 000 dollars par véhicule semble assez élevé, surtout si le BlueNet n’est pas particulièrement précis et qu’il n’ existe pas de projets informatiques à grande échelle pour la mise hors service ou la mise à niveau des systèmes dépendants.

Applications futures

Bien qu’on puisse aisément être soucieux de la nature orwellienne d’un réseau qui fonctionne en continu de mouchards à plaques minéralogiques, cette technologie a de nombreuses applications positives. Imaginez un système passif qui analyse les autres automobilistes à la recherche d’une voiture de ravisseurs et qui avertit automatiquement et en temps réel les autorités et les membres de la famille de leur emplacement et de leur direction.

Les véhicules Tesla regorgent déjà de caméras et de capteurs capables de recevoir des mises à jour OTA (NdT : Over The Air, c’est-à-dire des mises à jour à distance) – imaginez qu’on puisse en faire une flotte virtuelle de bons Samaritains. Les conducteurs Uber et Lyft pourraient également être équipés de ces dispositifs pour augmenter considérablement leur zone de couverture.

En utilisant la technologie open source et les composants existants, il semble possible d’offrir une solution qui offre un taux de rendement beaucoup plus élevé – pour un investissement bien inférieur à 86 millions de dollars.

Pendant que vous cherchez la contrepèterie dans ce titre purement factuel, on vous explique : Sympa, c’est le logiciel qui nous permet de gérer Framalistes, un des services de notre modeste plan de libération du monde© !

Marc Chantreux a lancé une invitation à tous les fans de Sympa (eh oui, ils sont sympas, on va se débarrasser de ça tout de suite) pour le rejoindre dans un grand hackathon à Strasbourg le week-end du premier avril 2017.

C’est super, mais… c’est quoi ?

 

 

 

 

 

Bonjour Marc, est-ce que tu veux bien te présenter ?

Je m’appelle Marc Chantreux, je suis libriste (par conviction éthique et technique) depuis les années 90 et suis actuellement informaticien à l’université de Strasbourg où j’ai géré sympa pendant 5 ans.

Sympa, le logiciel libre qui nous sert à gérer Framalistes, va fêter ses 20 ans, c’est bien ça ?

C’est ça et je me suis connecté pour la première fois à Internet la même année. Ce qui m’a immédiatement plu à l’époque, ce n’était pas la quantité de documentation disponible (parce qu’on avait déjà des e-zines et autres documentations qui circulaient sur CD-Rom ou supports imprimés) mais la possibilité de poser directement des questions aux experts dans une ambiance extrêmement ouverte et respectueuse. Les deux principaux outils pour cela étaient Usenet et les listes de discussion. En France, un gros hébergeur de listes était Universalistes qui tournait déjà (qui tourne toujours) sous sympa.

Ce logiciel a été créé et maintenu par la communauté universitaire française depuis l’origine. Entre temps, sympa a été adopté dans le monde entier et s’est enrichi de fonctionnalités nécessaires au travail collaboratif pour lequel les listes étaient utilisées (documents partagés, archives, modération, délégation de droits, etc.).

Je me réjouis de voir que Framasoft ait monté une instance de sympa pour sa communauté mais perso, j’aurais utilisé « framagroupes » comme nom.

À cette occasion tu organises un fork communautaire et un hackathon. Tu peux nous expliquer ? Nan, parce que Framasky, il m’a demandé de t’interviewer mais j’y comprends que pouic. 🙂

Ces dernières années, la communauté universitaire a affecté de moins en moins de ressources jusqu’à ce que tout s’arrête complètement au courant de l’année dernière. La communauté est pourtant forte de millions d’utilisateurs et il n’existe pas d’alternative crédible si on considère sympa dans son ensemble. J’ai donc proposé à la communauté de se rassembler pour s’organiser et posé les bases d’un développement qui ne repose plus sur le seul acteur historique (RENATER). Les 20 ans de sympa tombaient un week-end, c’était une belle occasion.

RENATER a réagi très positivement à cette initiative et nous a rapidement prêté assistance, en ouvrant une partie de l’infrastructure, en parrainant la venue du leader historique du projet — David Verdin — et en nous rassurant sur leur volonté de rester investi dans le projet. J’ai eu des échanges téléphoniques et électroniques avec leur direction technique et je suis confiant dans la perspective de voir RENATER redonner de la force de frappe à sympa.

Et c’est quoi, l’objectif de ce hackathon ? Sur quel critère le jugeras-tu réussi ?

L’objectif de ce hackathon est d’initier les projets qui permettront aux utilisateurs de sympa d’avoir accès plus simplement à un grand nombre de fonctionnalités. Il nous faut au passage nous mettre d’accord sur des pratiques communes de développement mais le plus important pour moi n’est pas là.

Je suis membre de longue date de la communauté Perl et je suis toujours ému par l’énergie qui se dégage du sentiment que nous partageons tous d’appartenir à une communauté soudée, au service de millions d’utilisateurs et vivant une grande aventure technique avec des défis à relever au quotidien pour produire le meilleur logiciel possible. Si nous arrivons à faire germer cet esprit dans la communauté sympa naissante, alors je serais heureux.

Le hackathon, c’est que pour les développeurs, ou tout le monde peut contribuer ?

Sympa est comme tout logiciel libre : sa valeur réside dans son utilité et non dans son code.

Pour le rendre utile, il faut aussi le rendre accessible et visible et nous avons besoin de faire plein de choses nécessitant plein de compétences ! Dites-moi ce que vous voulez ou savez faire et j’aurais probablement des tâches à vous proposer. Celles qui me viennent sont : collecter les besoins et retours des utilisateurs, organiser ou participer à des événements, faire du graphisme et de la communication, nous aider à réaliser de la documentation, créer et animer la formation, assister les communautés d’utilisateur, faire de la traduction…

Il va y avoir du beau monde, dans ce hackathon, les copains de Yunohost, notamment. Qui d’autre ?

De nombreux acteurs associatifs en faveur de l’auto-hébergement et de l’internet neutre (par exemple Framasoft, YUNoHost, ARN qui est un FAI associatif alsacien) mais aussi des hackers du Libre User Group alsacien et du Hackstub, des membres de la communauté universitaire (Universités de Strasbourg et Oslo et RENATER qui est le FAI des universités françaises) ainsi que les sociétés Hackcendo et Linuxia.

Et ça se passe où ? Il faut s’inscrire quelque part ?

Ça se passe au portique de l’université de Strasbourg mais les inscriptions sont maintenant closes. Désolé…

Du coup, on peut participer à distance ? Ou aider d’une autre façon ?

Bien sûr : le mieux est de rejoindre le canal IRC #sympa sur freenode dès maintenant et de dire que vous êtes intéressés par la contribution. Si vous avez du mal avec l’anglais, vous pouvez aussi vous abonner à la liste sympa-fr (https://listes.renater.fr/sympa/info/sympa-fr) ou me contacter directement.

Sympa, ça peut gérer des listes de diffusion vraiment balaises ? Genre quoi ?

Genre j’ai personnellement géré des listes de 140 000 abonnés ou le goulot d’étranglement n’était pas sympa mais l’infra de messagerie. Les listes permettant de contacter l’ensemble des personnels de l’enseignement supérieur tournent avec sympa et il existe des groupes qui dépassent le million d’abonnés.

Mais si on se lance dans le concours du plus gros site, je dirais que le principal intérêt de sympa réside non pas dans sa capacité d’envoyer des millions de messages mais de réussir à les envoyer en respectant l’état de l’art dans les pratiques relatives à la lutte anti-spam (DMARC, DKIM…) et de donner la possibilité à des administrateurs d’industrialiser la création et la maintenance d’un grand nombre de listes (l’université de Strasbourg en compte près de 35 000).

Comme d’hab, nous te laissons le mot de la fin, lâche-toi.

Lors de l’apparition des premiers web fora, j’ai vu les communautés se diviser autour des outils de discussion. les « surfers » (qui aiment les fora pour leur côté immédiat, simple et « beau ») et les fans de la messagerie électronique qui apprécient le degré de liberté qui leur est donné de présenter et traiter les messages comme ils l’entendent. Les deux approches sont valables et ne devraient pas être un frein pour ce qui compte réellement : l’échange ! Avec ses outils (postage, archives en ligne, dépôt de documents) sympa est soit un gestionnaire de listes haut de gamme soit le système de forum avec la pire interface web du monde.

L’urgence de sympa, c’est donc son interface web et c’est là-dessus que nous allons mettre le paquet.

Pour en savoir plus, et surtout donner un coup de main, c’est par ici

Aujourd’hui menu allégé (après les agapes), avec un bref chapitre de Des routes et des ponts par Nadia Eghbal, ouvrage dont tous les chapitres précédents sont là.
Il s’agit cette fois-ci de dresser la liste des principes qui devraient gouverner le soutien durable aux projets et infrastructures open source.

Traduction Framalang :  Penguin, goofy, xi, Lumi, xXx, Mika

Élaborer des stratégies d’assistance efficaces

Même si les gens sont de plus en plus intéressés par les efforts pour soutenir les infrastructures numériques, les initiatives actuelles sont encore récentes, faites pour des cas particuliers ou fournissent seulement un support partiel (comme le partage d’avantages fiscaux par des organisations à but non lucratif avec des groupes extérieurs à celles-ci).

Le développement de stratégies de soutien efficaces demande une compréhension fine de la culture open source qui caractérise une très grande partie de notre infrastructure numérique, mais aussi de reconnaître que beaucoup de choses ont changé dans les cinq dernières années, y compris la définition même de l’open source.

L’argent seul ne suffira pas à répondre aux problèmes d’un projet d’infrastructure en difficulté, parce que l’open source s’épanouit grâce aux ressources humaines et non financières. Il existe beaucoup de façons d’accroître les ressources humaines, comme distribuer la charge de travail parmi davantage de contributeurs ou encourager les entreprises à faire publier en open source une partie du travail de leurs employés. Une stratégie de soutien efficace doit inclure plusieurs façons de générer du temps et des ressources au-delà du financement direct du développement. Elle doit partir du principe que l’approche open source n’est pas défectueuse en elle-même, mais manque simplement de ressources.

Soutenir les infrastructures nécessite d’intégrer le concept d’intendance en lieu et place du concept de contrôle. Comme nous l’avons vu, les infrastructures numériques ne ressemblent pas aux infrastructures physiques. Elles sont réparties entre de multiples acteurs et organisations, avec des projets de toute forme et de toute taille, et il est difficile de prédire quels projets deviendront un succès ou qui y contribuera sur le long terme.

 

Avec cela en tête, voici quelques clés pour élaborer une stratégie d’assistance efficace :

Adopter la décentralisation, plutôt que s’y opposer

Les ressources de l’open source sont destinées à être partagées, c’est en partie ce qui leur donne autant d’impact.
Utiliser la force que donne l’aspect communautaire comme un levier, plutôt que de recentraliser l’autorité.

Travailler étroitement avec les communautés informatiques existantes.

Les communautés informatiques sont actives, soudées et savent se faire entendre. Faites appel à elles plutôt que de prendre une décision en aparté. Les voix les plus sonores des communautés agissent comme un signal de danger quand un problème nécessite d’être soulevé.

Envisager une approche globale du soutien aux projets

Les projets ont besoin de bien plus que du code ou de l’argent, parfois même ils n’ont besoin ni de l’un ni de l’autre. Le soutien sur le long terme est davantage une question de temps accordé que d’argent. La revue de code, la documentation technique, les tests de code, la soutien de la communauté, et la promotion du projet constituent un ensemble de ressources importantes.

Aider les mainteneurs de projets à anticiper

Aujourd’hui, les efforts pour soutenir l’infrastructure numérique ont tendance a être uniquement de la réactivité liée aux circonstances ponctuelles. En plus des projets existants, il existe sûrement de nouveau projets qui ont besoin d’être lancés et accompagnés.
Pour les projets existants, les mainteneurs trouveront un grand avantage à pouvoir planifier en vue des trois à cinq ans à venir, et pas seulement pour six mois ou un an.

Voir les opportunités, pas seulement les risques

Soutenir l’open source de nos jours, cela ne consiste pas uniquement à éviter les scénarios catastrophes (par exemple les failles de sécurité), mais plutôt à donner les moyens à davantage de personnes de réaliser davantage de choses. Ce concept est une caractéristique essentielle de la culture open source actuelle, et permet aussi de mettre en place un soutien pérenne. Tenez compte dans votre stratégie de la façon dont vous pourriez accueillir davantage de personnes d’horizons, de compétences et de talents différents, plutôt que de limiter l’activité pour favoriser les personnes qui participent déjà.

David Heinemeier Hansson, le créateur de Ruby on Rails, compare l’open source à un récif de corail :

« C’est un milieu plus fragile que vous ne le pensez, et il est difficile de sous-estimer la beauté qui est involontairement en jeu. Marchez avec précaution. »