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

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

Avez-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à.

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.

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.

Le groupe Framalang a traduit l’article de Julien, qui a listé tous les moyens de se tirer une balle dans le pied quand on coordonne un projet libre.

Apprenez à les éviter !

Conduite de projets Open Source : 10 erreurs à éviter

Article original : https://julien.danjou.info/blog/2016/foss-projects-management-bad-practice
Auteur : Julien Danjou(CC-BY-SA)
Traduction : lyn., KoS, AlienSpoon, David 5.1, Simon, goofy, Slimane Aguercif, Fred, galadas, terhemis, gégé

Il y a quelques semaines, lors de l’OpenStack Summit (réunion annuelle des contributeurs à OpenStack, NDT), j’ai eu l’occasion de discuter de mon expérience de la conduite de projets Open Source. Je me suis rendu compte qu’après avoir fait partie de plusieurs communautés et beaucoup contribué pendant des années, je pourrais faire profiter les nouveaux venus de conseils et d’avis expérimentés.

Il existe une foule de ressources disponibles expliquant comment conduire un projet Open Source. Mais aujourd’hui, je voudrais aborder ce sujet sous un angle différent, en insistant sur ce qu’il convient de ne pas faire avec les personnes qui y participent. Je tire cette expérience des nombreux projets Open Source auxquels j’ai participé ces dernières années. Je vais décrire, sans ordre particulier, quelques mauvaises pratiques que j’ai constatées, en les illustrant par des exemples concrets.

 

1. Considérer les contributeurs comme une nuisance

Quand les informaticiens sont au travail, qu’ils soient chargés du développement ou de la maintenance d’un logiciel, il est une chose dont ils n’ont pas besoin : du travail supplémentaire. Pour la plupart d’entre eux, la première réaction à toute contribution externe est : « Zut, du travail en plus ». Et c’est effectivement le cas.

Par conséquent, certains développeurs essayent d’éviter ce travail supplémentaire : ils déclarent ne pas vouloir de contributions, ou font en sorte que les contributeurs se sentent indésirables. Cela peut prendre de nombreuses formes, comme les ignorer ou être désagréable avec eux. Ainsi, les développeurs évitent d’avoir à traiter le surplus de travail qu’on leur met sur le dos.

C’est une des plus grandes erreurs que l’on peut commettre, et une vision fausse de l’Open Source. Si des gens vous apportent du travail supplémentaire, faites tout ce que vous pouvez pour bien les accueillir afin qu’ils continuent à travailler avec vous. Il s’agit peut-être de ceux qui prendront votre relève d’ici peu. Préparez votre future retraite.

Prenons le cas de mon ami Gordon, que j’ai vu démarrer en tant que contributeur sur Ceilometer en 2013. Il examinait très bien le code, si bien qu’il me donnait en fait davantage de travail : non seulement en détectant les anomalies dans mes contributions, mais aussi en me faisant vérifier les siennes. Au lieu de m’en prendre à lui pour qu’il arrête de me faire retravailler mon code et vérifier ses correctifs, j’ai proposé qu’on lui fasse davantage confiance en l’ajoutant officiellement à l’équipe des correcteurs sur un des projets.

Et s’ils ne font pas cette première contribution, ils ne feront pas non plus la seconde. En fait, ils n’en feront aucune ; et ces projets perdraient alors leurs futurs correcteurs.

2. Ne confier aux autres que le sale boulot

Lorsque de nouveaux contributeurs se présentent pour travailler sur un certain projet, leurs motivations peuvent être très diverses. Certains sont des utilisateurs, d’autres veulent simplement voir ce que c’est de contribuer. Ressentir le frisson de la participation, comme un simple exercice ou avec la volonté d’apprendre afin de contribuer en retour à l’écosystème qu’ils utilisent.

En général, les développeurs confient le sale boulot à ces personnes, c’est à dire des tâches sans intérêt, à faible valeur ajoutée, et qui n’auront sans doute aucun impact direct sur le projet.

Pour certains, ce n’est pas grave, pour d’autres, ça l’est. Certains seront vexés de se voir confier du travail sans grand intérêt, alors que d’autres seront heureux de le faire pourvu qu’on leur témoigne de la reconnaissance. Soyez sensible à cela, et félicitez ces personnes. C’est la seule manière de les garder dans le projet.

3. Mépriser les petites contributions

Quand le premier patch d’un nouveau contributeur est une correction d’orthographe, qu’en pensent les développeurs ? Qu’ils s’en fichent, que vous gâchez de leur temps précieux avec votre petite contribution. Et personne ne s’intéresse à la perfection grammaticale d’une documentation, n’est-ce pas ?

C’est faux. Voyez mes premières contributions à home-assistant et Postmodern : j’ai corrigé des fautes d’orthographe dans la documentation.

J’ai contribué au projet Org-mode pendant quelques années. Mon premier patch corrigeait simplement une chaîne de caractères du code. Ensuite, j’ai envoyé 56 patchs, corrigeant des bogues et ajoutant de nouvelles fonctionnalités élégantes, et j’ai aussi codé quelques extensions. À ce jour, je suis toujours seizième dans la liste des plus gros contributeurs d’Org-mode, qui en contient 390. Certainement pas ce qu’on appellerait un petit contributeur, donc. Je suis sûr que la communauté est bien contente de n’avoir pas méprisé ma première correction dans la documentation.

4. Mettre la barre trop haut pour les nouveaux arrivants.

Quand de nouveaux contributeurs arrivent, leurs connaissances du projet, de son contexte, et des technologies sont très variables. L’une des erreurs que les gens font le plus souvent consiste à demander aux nouveaux contributeurs des choses trop compliquées, dont ils ne pourront pas venir à bout. Cela leur fait peur (surtout les timides ou les introvertis) et ils risquent de disparaître, se croyant trop stupides pour aider.

Avant de faire le moindre commentaire, vous ne devriez avoir strictement aucun a priori sur leur niveau. Cela permet d’éviter ce genre de situations. Il faut également mettre beaucoup de délicatesse quand vous estimez les compétences des nouveaux, car certains pourraient se vexer si vous les sous-estimez trop.

Quand son niveau est bien estimé (un petit nombre d’échanges devrait suffire), vous devez former votre contributeur en ne le guidant ni trop ni trop peu, afin qu’il puisse s’épanouir. Il faut du temps et de l’expérience pour y parvenir, et vous allez probablement perdre certains contributeurs avant de bien maîtriser ce processus, mais c’est un chemin que tous ceux qui gèrent des projets doivent suivre.

Façonner ainsi les nouveaux arrivants est au cœur de la gestion de vos contributeurs, et ce quel que soit votre projet. Et je suis quasiment sûr que cela s’applique à tout projet, même en dehors du logiciel libre.

5. Exiger des gens qu’ils fassent des sacrifices sur le plan personnel

C’est un point qui dépend beaucoup du projet et du contexte, mais il est très important. Dans le logiciel libre, où la plupart des gens vont contribuer par bonne volonté et parfois sur leur temps libre, vous ne devez surtout pas exiger d’eux qu’ils fassent des sacrifices personnels importants. Ça ne passera pas.

L’une des pires manières de faire cette erreur est de fixer un rendez-vous à l’autre bout du monde pour discuter du projet. Cela place les contributeurs qui vivent loin dans une situation injuste, car ils ne peuvent pas forcément quitter leur famille pour la semaine, prendre l’avion ou un autre moyen de transport, louer une chambre d’hôtel… Ce n’est pas bon : tout devrait être mis en œuvre pour que les contributeurs se sentent partie prenante du projet et intégrés à la communauté, sans que l’on exige cela de leur part. Entendons-nous bien, cela ne veut pas dire qu’il faut s’interdire toute rencontre ou activité sociale, au contraire. Pensez simplement à n’exclure personne lorsque vous discutez d’un projet.

Il en va de même pour les moyens de communication susceptibles de compliquer la vie des participants : se retrouver sur IRC (il est difficile pour certaines personnes de réserver une heure, surtout lorsqu’il faut tenir compte des différents fuseaux horaires), faire une visioconférence (en particulier quand on n’utilise pas de logiciel libre et gratuit), etc.

En gros, tout ce qui impose de se synchroniser en temps réel avec l’avancement du projet est contraignant pour certains contributeurs.

C’est pourquoi le meilleur moyen de communiquer reste le courriel, mais tous les outils de communication asynchrones (pisteurs de bogues, etc.) feront l’affaire dans la mesure où ils permettent à chacun de travailler à son rythme et à l’heure qui lui convient.

6. Ne pas avoir de code de conduite

À une époque où de plus en plus de communautés s’ouvrent à un public plus large que celui auquel elles étaient habituées (ce qui est fantastique), les codes de conduite semblent être un sujet à la mode, mais aussi délicat.

En réalité, toutes les communautés ont un code de conduite, qu’il soit inscrit noir sur blanc ou suivi inconsciemment par chacun. Sa forme dépend de la taille et de la culture de la communauté.

Cependant, en fonction de la taille de votre communauté et de la façon dont ce code s’applique, vous auriez peut-être intérêt à l’écrire dans un document, comme l’a par exemple fait Debian.

Ce n’est pas parce que vous aurez rédigé un code de conduite que tous les membres de votre communauté vont soudain se transformer en adorables Bisounours le suivant à la lettre, mais il fournit des règles que vous pouvez citer en cas de besoin. Il peut être utile de le transmettre à certains pour leur faire comprendre que leur comportement ne convient pas, et cela peut aider si une exclusion devient nécessaire, même s’il ne sert que rarement à cela, puisqu’en général personne ne veut aller aussi loin.

Je pense qu’on peut très bien se passer d’un tel document sur de petits projets. Mais vous devez garder à l’esprit qu’un code de conduite implicite découlera de votre comportement. La manière dont vos membres les plus influents communiqueront avec les autres installera l’ambiance à travers tout le réseau. Ne sous-estimez pas cela.

Quand nous avons commencé le projet Ceilometer, nous avons suivi le code de conduite du projet OpenStack avant même qu’il ait été écrit, et probablement avons-nous même placé la barre un peu plus haut. En étant agréables, accueillants et ouverts d’esprit, nous avons réussi à obtenir une certaine mixité, avec plus de 25% de femmes dans notre équipe permanente — bien au dessus de la moyenne actuelle d’OpenStack et de la plupart des projets de logiciel libre !

7. Mettre les non-anglophones à l’écart

Il est important d’être conscient que la grande majorité des projets de logiciel libre utilisent l’anglais en tant que langue de communication principale. C’est logique. C’est une langue répandue, et qui semble remplir ce rôle correctement.

Mais une grande partie des codeurs n’ont pas l’anglais pour langue maternelle. Beaucoup ne le parlent pas couramment. Cela signifie que le rythme auquel ils peuvent converser peut-être très lent, ce qui peut en frustrer certains, notamment ceux qui sont nés en terre anglophone.

 

On peut observer ce phénomène dans les rencontres de codeurs, lors de conférences par exemple. Quand les gens débattent, il peut être très difficile pour certains d’expliquer leurs pensées en anglais et de communiquer à un rythme correct, ce qui ralentit la conversation et la transmission des idées. La pire chose qu’un anglophone puisse faire dans ce cas est de leur couper la parole, ou de les ignorer, pour la seule raison qu’ils ne parlent pas assez vite. Je comprends que cela puisse être frustrant, mais le problème n’est pas la façon de parler des non-anglophones mais les outils de communication utilisés qui ne mettent pas tout le monde au même niveau en privilégiant des conversations orales.

La même chose s’applique, à un moindre degré, aux rencontres sur IRC, qui sont relativement synchrones. Les médias complètement asynchrones ne pâtissent pas de ce défaut, et c’est pourquoi ils faudrait, à mon avis, les privilégier.

8. Pas de vision, aucune délégation des tâches

C’est une autre grosse erreur de gestion si le responsable ne parvient pas à gérer la croissance du projet alors que des gens sont disponibles et prêts à aider.

Évidemment, lorsque le flux des contributeurs commence à grossir, ajoutant de nouvelles fonctionnalités, demandant des retours et des instructions à suivre, certains responsables se retrouvent la tête sous l’eau et ne savent pas comment répondre. Ce qui a pour conséquences de frustrer les contributeurs, qui vont simplement partir.

Il est important d’avoir une vision de votre projet et de la communiquer. Dites clairement à vos contributeurs ce que vous voulez, et ne voulez pas, dans votre projet. Exprimer ces informations de manière claire (et non-agressive !) permet de minimiser les frictions entre vos contributeurs. Ils vont vite savoir s’ils veulent rejoindre ou non votre navire et quoi en attendre. Donc, soyez un bon capitaine.

S’ils choisissent de travailler avec vous et de contribuer, vous devez rapidement commencer à croire en eux et à leur déléguer certaines de vos responsabilités. Cela peut être n’importe quelle tâche que vous faites d’habitude vous-même : vérifier les patchs de certains sous-systèmes, traquer les bogues, écrire la documentation… Laissez les gens s’approprier entièrement une partie du projet car ils se sentiront responsables et ils y mettront autant de soin que vous. Faire le contraire en voulant tout contrôler vous-même est la meilleure façon de vous retrouver seul avec votre logiciel open source.

Aucun projet ne va gagner en taille et en popularité de cette manière.

En 2009, quand Uli Schlachter a envoyé son premier patch à awesome, cela m’a donné plus de travail. J’ai du vérifier son patch, et j’étais déjà bien occupé pour sortir la nouvelle version d’awesome sur mon temps libre en dehors de mon travail ! Le travail d’Uli n’était pas parfait, et j’ai eu à gérer les bogues moi-même. Plus de travail. Alors qu’ai-je fait ? Quelques minutes plus tard, je lui ai répondu en lui envoyant un plan de ce qu’il devait faire et de ce que je pensais de son travail.

En retour, Uli envoya d’autres patchs et améliora le projet. Savez-vous ce que fait Uli aujourd’hui ? Il est responsable du gestionnaire des fenêtres awesome à ma place depuis 2010. J’ai réussi à transmettre ma vision, déléguer, puis à quitter le projet en le laissant dans de bonnes mains !

9. Ignorer certains types de contributions

Les gens contribuent de différentes manières, et pas toujours en codant. Il y a beaucoup de choses autour d’un projet de logiciel libre : la documentation, le tri de bogues, le support, la gestion de l’expérience utilisateur, la communication, les traductions…

Par exemple, il a fallu du temps pour que Debian songe à donner le statut de Développeur Debian à leurs traducteurs. OpenStack prend la même direction en essayant de reconnaître les contributions autres que techniques.

Dès lors que votre projet commence à récompenser certaines personnes et à créer différents statuts dans la communauté, vous devez faire très attention à n’oublier personne, car c’est le meilleur moyen de perdre des contributeurs en chemin.

10. Oublier d’être reconnaissant

Cette liste est le fruit de nombreuses années de bidouillages open source et de contributions à des logiciels libres. L’expérience et le ressenti de chacun sont différents, et les mauvaises pratiques peuvent prendre différentes formes : si vous connaissez ou si vous avez vous-même rencontré d’autres obstacles dans vos contributions à des projets open-source, n’hésitez pas à compléter la liste dans les commentaires. C’est une forme de contribution.