De communications en directives, l’incurie de la Commission européenne dans le domaine de la technologie et des contenus en ligne apparaît de plus en plus clairement.

Faisant fi des avis des experts, voire des rapports qu’elle a elle-même commandés, la Commission s’entête à proposer des solutions imparfaites et simplistes à des problèmes complexes. Une de ses dernières initiatives le prouve une fois de plus et ne fait que rajouter à l’inquiétude de tous les défenseurs des libertés numériques et de la vie privée.

Filtres de publication, droit d’auteur et poudre de perlimpinpin

Par Glyn Moody, source : Copybuzz
Traduction à 20 mains par simon, satanas_g, QuoiQue, mo, FranBAG, Edgar Lori, goofy, Mika et dodosan

Image par Stromcarlson.

Le 28 septembre, la Commission européenne a dévoilé une initiative de grande ampleur pour s’attaquer au « contenu illicite en ligne ». Comme c’est souvent le cas lorsque des politiciens veulent avoir l’air de « faire quelque chose » au sujet du terrorisme, il y a beaucoup de mauvaises idées.

Le cœur de cette initiative est un plan pour encourager les plateformes en ligne à renforcer « la prévention, la détection et la suppression proactives des contenus illicites en ligne incitant à la haine, à la violence et au terrorisme ».  De manière insistante, ces idées sont présentées comme des « orientations et des principes ». C’est parce que tout repose sur le libre consentement. Sauf que la Commission a clairement dit que si ce système volontaire n’est pas adopté par des entreprises comme Facebook ou Google, elle promulguera de nouvelles lois pour leur forcer la main. La Commission est pressée de voir les résultats de ces efforts volontaires, et des projets de loi pourraient être mis sur la table dès mai 2018.

Une de ces mauvaises idées imposerait aux plateformes en ligne de travailler conjointement avec des signaleurs de confiance – « des entités spécialisées disposant d’une expertise en matière de contenu illicite ». Ils peuvent bien être experts, mais ils ne sont pas juges, ce qui implique que la Commission voudrait que Facebook et Google mettent des contenus hors ligne sans avoir besoin de se soucier de ce qu’un juge considérerait réellement comme illégal.

Mais la pire idée, et elle apparaît plusieurs fois dans les derniers plans de la Commission, est l’utilisation omniprésente et systématique de filtres de publication. Dans un document de 20 pages détaillant la proposition intitulée « Communication sur la suppression des contenus illicites en ligne – Vers une responsabilité renforcée des plateformes en ligne » l’accent est mis sur « l’utilisation des technologies pour détecter les contenus illicites ». En particulier, l’utilisation et le développement futur de la détection automatique et des technologies de filtrage sont encouragés.

Une des principales raisons pour lesquelles la Commission européenne place tant d’espoirs dans l’automatisation pour résoudre les problèmes de contenus illégaux est qu’elle croit apparemment que « dans le domaine du droit d’auteur, la reconnaissance automatique des contenus s’est avérée être un outil efficace depuis de nombreuses années ». Sauf que cela n’est pas vrai. L’eurodéputée Julia Reda (Parti pirate) a écrit un article de blog instructif qui détaille neuf façons bien distinctes dont les filtres de publication échouent. Ce faisant, ils causent de nombreux dégâts collatéraux, particulièrement en matière de droits fondamentaux.

Une réponse à cette démonstration fracassante de l’échec des filtres de publication est de concéder qu’ils sont imparfaits, mais dire ceci montre simplement que davantage de recherches sont nécessaires pour les améliorer. C’est l’argument classique du cherchez plus fort qui est souvent utilisé pour défendre la création de portes dérobées dans les logiciels de chiffrement. Bien que les experts en sécurité expliquent unanimement et de façon répétée qu’il n’est pas possible de créer une vulnérabilité qui soit utilisable seulement par les autorités et qui ne soit pas vulnérable aux attaques de criminels ou d’acteurs étatiques malveillants, les gouvernements persistent à croire qu’ils savent mieux que les experts, et que les entreprises devraient juste le faire. Et des vulnérabilités sont donc implémentées. Même si les gens qui comprennent le fonctionnement des filtres de publication expliquent patiemment qu’il est impossible de traduire l’extrême complexité du droit d’auteur dans les règles de filtrage pouvant être appliquées automatiquement et correctement, les autorités continuent de prôner ce supposé remède miracle.

Appelons cela le mirage de la « poudre de perlimpinpin numérique » – la croyance que l’on peut traiter tous les problèmes du monde réel avec de la technologie, et qu’ils seront résolus, juste comme ça. La Commission européenne est une grande adepte de cette poudre de perlimpinpin, comme le montre clairement sa demande de mettre en place des filtres de publication dans la directive sur le droit d’auteur et le nouveau cadre destiné à s’attaquer au contenu illégal. L’annonce de la semaine dernière est un signe inquiétant qu’elle est loin de comprendre que les filtres de publication ne sont pas une solution pratique pour la question du droit d’auteur en ligne, et qu’elle s’entête au contraire dans cette direction et l’étend désormais à d’autres domaines.

La Commission européenne est bien au courant que l’Article 15 de la directive sur le commerce électronique interdit explicitement aux États membres d’imposer « une obligation générale de surveiller les informations qu’ils transmettent ou stockent, ou une obligation générale de rechercher activement des faits ou des circonstances révélant des activités illicites » En mettant en avant la « responsabilité avancée des plateformes en ligne », comme le fait la première page de la communication du 29 septembre, la Commission semble souligner que sa nouvelle approche impose dans les faits une « obligation générale » à ces entreprises de filtrer tous les contenus mis en ligne qui correspondraient à une vaste gamme de « contenu illégal ». On imagine aisément la Cour de justice de l’Union européenne invalider toute tentative d’inscrire cette « responsabilité avancée » dans la loi.

Au-delà du fait qu’ils ne fonctionneront pas et qu’ils sont illégaux du fait de la directive sur le commerce électronique, il y a une autre raison pour laquelle les filtres de publication de l’article 13 devraient être abandonnés : il n’existe aucune preuve de leur nécessité. Tout comme la Commission européenne a joyeusement propagé l’idée fausse selon laquelle le filtrage automatique fonctionne, elle a aussi docilement accepté la rumeur selon laquelle les copies non autorisées d’œuvres soumises au droit d’auteur seraient un désastre pour l’industrie du droit d’auteur et les artistes.

Comme nous l’avons récemment appris par la publication tardive d’un rapport capital qui a coûté à la Commission européenne la somme princière de 369 871€, les faits montrent le contraire. Il est évident que la Commission a essayé d’enterrer sa propre analyse, payée par les citoyens européens, probablement parce que les résultats ne convenaient pas à son projet d’introduire des peines toujours plus fortes aux infractions au droit d’auteur. Comme l’admet le rapport, globalement, « les résultats ne montrent pas de preuves statistiques solides d’une modification des ventes due au non-respect du droit d’auteur en ligne ».

Deux domaines spécifiques ont été touchés par le partage non autorisé : les nouveaux films ont été affectés défavorablement, tandis que pour les jeux, la consommation illégale a mené à plus de ventes légales. C’est un signe de l’approche biaisée de la Commission européenne sur ce sujet : ses économistes ont publié une synthèse à propos des effets négatifs du téléchargement sur les films, mais ont omis de mentionner l’effet positif qu’il avait sur les jeux.

Cette mauvaise foi rend encore plus irritant l’acharnement de la Commission à vouloir trouver une solution technologique illusoire à un problème inexistant. Si elle avait le courage d’admettre la vérité sur la nature non problématique du partage non autorisé d’œuvres soumises au droit d’auteur, elle n’aurait pas à promouvoir des propositions stériles comme les filtres de publication dont on sait qu’ils nuiront immensément au monde en ligne ainsi qu’au Marché unique numérique de l’UE.

Raymond Rochedieu est, depuis des années, un pilier de l’équipe bénévole qui relit et corrige les framabooks. Quand ce perfectionniste a annoncé vouloir s’attaquer à la traduction et l’adaptation d’un ouvrage kolossal, personne ne pouvait imaginer la masse de travail qui l’attendait. Surtout pas lui !
Personnage haut en couleur et riche d’une vie déjà bien remplie, ce papi du Libre nous offre aujourd’hui le fruit d’un travail acharné de plusieurs années. Framabook renoue ainsi le temps d’un précieux ouvrage avec sa tradition de manuels et guides.

Markus Kohm, Raymond Rochedieu (traduction et adaptation), KOMA-Script. Typographie universelle avec XƎLATEX, Framabook, octobre 2017.

Bonjour Raymond, si tu aidais nos lecteurs à faire connaissance avec toi ?

Bonjour, je m’appelle Raymond Rochedieu et depuis une quinzaine d’année, lors de la naissance de mon premier petit fils, tout le monde m’appelle Papiray. Je suis âgé de 72 ans, marié depuis 51 ans, j’ai deux garçons et 6 petits-enfants.

Je suis à la retraite, après avoir exercé des métiers aussi variés que : journaliste sportif vacataire (1959-1963), agent SNCF titulaire (1963-1967), VRP en machines-outils bois Guilliet (1967-1968), éducateur spécialisé (1968-1970, école d’éducateur de Reims), artisan imprimeur en sérigraphie (1970-1979), VRP (Textiles Florimond Peugnet – Cambrai, Éditions Paris-Match, Robert Laffont et Quillet, Laboratoires Messegué, Électro-ménager Vorwerk et Electrolux, Matra-Horlogerie JAZ…), puis ingénieur conseil, directeur commercial, artisan menuisier aluminier, avant de reprendre des études à 52 ans et de passer en 10 mois un BTS d’informaticien de gestion. Malgré les apparences, je ne suis pas instable, seulement curieux, « jusqu’auboutiste » et surtout socialement et individuellement responsable mais (très) indépendant, ce que j’appelle mon « Anarchie Utopiste » (expression qui, comme chacun le sait, vaut de l’or) : je rêve d’un monde où tous seraient responsables et égaux… mais ce n’est qu’un rêve !

J’ai terminé ma carrière professionnelle comme intervenant en informatique, installateur, dépanneur, créateur de sites internet, formateur agréé éducation nationale, chambre de commerces et chambre des métiers et même jury BTS à l’IUT de Reims.

Ton projet de traduction et de Framabook a été une œuvre de longue haleine et aboutit à un ouvrage massif. Comment tout cela a-t-il commencé ? Pourquoi as-tu entamé seul ce gigantesque labeur ?

Je me suis tout d’abord intéressé à l’ouvrage de Vincent Lozano Tout ce que vous avez toujours voulu savoir sur LATEX sans jamais oser le demander (Ou comment utiliser LATEX quand on n’y connaît goutte) auquel j’ai participé, à l’époque, en qualité de correcteur. Mais 2008, c’est aussi, pour moi, une rupture d’anévrisme et 14 jours de coma dont je suis sorti indemne, bien que physiquement diminué.

Puis j’ai enchaîné opération du genou droit, infection nosocomiale, prothèse du genou gauche, phlébite, re-opération pour éviter l’amputation, bref vous comprenez pourquoi j’ai mis du temps pour poursuivre le travail !

J’ai cependant connu quelques moments de bonheur : deux stages de tourneur sur bois, à l’école Jean-François Escoulen d’Aiguines (83630) avec le « Maître » qui m’ont conduit à un premier projet : construire un tour à bois fonctionnant à l’ancienne sans électricité et raconter mon ouvrage, projet toujours d’actualité mais qui s’est fait croquer, l’âge aidant, par l’envie d’écrire mes souvenirs, moins de sport… car même la marche m’est devenue pénible… un refuge, mon bureau… l’ordi…et KOMA-Script…

En réalité, ce n’est pas tout à fait ça. Début 2014, je rencontre une amie  qui se plaint de l’utilisation du logiciel Word, inadapté à son besoin actuel : à 72 ans, elle a repris ses études et prépare un doctorat de théologie. Chapeau, Françoise… elle a aujourd’hui 75 ans et elle est, je crois, en dernière année…

Je cherche donc quels sont les outils utilisés par les « thésards » et les « doctorants », et je découvre LaTeX que l’on dit « créé par les Américains, pour les Américains » et mal adapté à la typographie du reste du monde. J’achète le livre de Maïeul Rouquette et découvre finalement cette perle qu’est KOMA-Script, à travers « Les fiches de Bébert » (voir liste de références plus bas).

Ce qu’il en écrit me donne envie d’aller plus loin dans la connaissance de l’ouvrage de Markus KOHM, mais pour moi, c’est l’horreur : l’original en langue allemande n’existe que dans une traduction en langue anglaise.

Et qu’est-ce qu’y fait, Papiray ? Hein ? Qu’est-ce qu’y fait ?

Ben y contacte Markus Kohm pour lui demander l’autorisation de passer l’ouvrage en langue française et y demande à ses « amis » de Framasoft ce qu’ils en pensent… ou l’inverse… toujours est-il que Markus m’y autorise en date du 19 juillet 2014 et que mes amis de Framasoft me disent « vas-y, fonce », le début d’une aventure commencée en réalité en mai de la même année.

Dans l’absolu, je n’ai pas l’impression d’avoir été réellement seul. La curiosité, la découverte des différents systèmes, les réponses – surtout par Christophe Masutti – aux questions posées, les lectures des multiples articles et ouvrages consacrés au sujet, les tests permanents des codes (dont les résultats n’étaient pas toujours ce que j‘en attendais), les erreurs de compilation non identifiées et dont il me fallait corriger la source…

Et puis, pour tout avouer, je ne savais pas réellement où je mettais les doigts… une fois la machine lancée, fallait bien assurer et assumer…

Tu as travaillé dur pendant longtemps et par-dessus le marché, les passes de révision des bénévoles de Framabook ont été nombreuses et t’ont souvent obligé à reprendre des détails, version après version. Comment tu as vécu ça, tu ne t’es jamais découragé ?

Vu dans l’instance Framapiaf du 26 juillet 2017 à propos de l’utilisation d’une varwidth dans une fbox :

Ce sont surtout les modifications de versions dues à Markus qui m’ont « obligé ».

Comme je l’ai indiqué ci-dessus, j’ai démarré ce travail, en mai 2014, sur la base de la version de l’époque qui a évolué le 16 avril, le 15 septembre, le 3 octobre 2015, avant de devenir la v3.20 en date du 10 mai 2016, la v3.21 le 14 juin puis la v3.22 le 2 janvier 2017, enfin la v3.23 le 13 avril 2017 et chaque fois, pour coller à la réalité, je me suis adapté en intégrant ces modifications.

De plus, Markus Kohm a multiplié des extensions et additifs publiés sur internet et j’ai décidé de les intégrer dans la version française de l’ouvrage. KOMA-Script est bien entendu le noyau, mais LaTeX, le système d’encodage abordé, m’était totalement inconnu. Je me suis inspiré, pour le découvrir à travers XƎLATEX, des ouvrages suivants qu’il m’a fallu ingérer, sinon comprendre :

• Vincent Lozano, Tout ce que vous avez toujours voulu savoir sur LaTeX sans jamais oser le demander, Framasoft/Framabook, 2013 (seconde édition) ;
• Noel-Arnaud Maguis, Rédigez des documents de qualité avec LaTeX OpenClassRooms ;
• Maïeul Rouquette, XƎLATeX appliqué aux sciences humaines Éditions Atramenta, 2012 ;
• Sébastien Combéfis, LaTeX HowTo – Le Guide Pratique, 2^e éditionn, UKO Publication, 2010, accompagné par une version en ligne sur le site UKO ;
• W. Appel, et al., LaTeX pour l’impatient, Éditions Minimax, 2007 ;
• …sans oublier le wiki des fiches à Bébert ;
• La FAQ latex l’équipe Grappa, M-P. Kluth, B. Bayart : FAQ LaTeX.

Cette liste n’est pas exhaustive et ne mentionne que les quelques ouvrages et sites parcourus le plus fréquemment.

Quant au bon usage de la langue française, j’ai toujours, à portée de main,

• Jean-Pierre Lacroux, Orthotypographie, sous licence CC-By-Nc-Nd, 2007 (édition originale) ;
• Aurel Ramat et Romain Muller, Le Ramat européen de la Typographie, éditions De Champlain, 2009 ;
• Éric Martini, Petit guide de Typographie, Éditions Glyphe, troisième édition, 2010 ;

que je consulte régulièrement. En cas de doute, il me reste trois références françaises solides :

• Imprimerie Nationale, Lexique des règles typographiques en usage à l’imprimerie nationale, édition (1971) 2002 ;
• le site Renouvo, réseau pour la nouvelle orthographe du français qui diffuse l’information sur les rectifications orthographiques proposées et recommandées par les instances francophones compétentes (entre autres, l’Académie française et « les » Conseil supérieur de la langue française) ;
• le forum de l’ABC de la langue française ;
• et une référence éclairée de nos amis canadiens francophones, l’Office Québécois de la Langue Française.

Et j’ai navigué au hasard de mes hésitations (merci Mozilla), sur de nombreux sites que je n’ai pas cités dans mes références.

Que leurs auteurs et animateurs ne m’en tiennent pas rigueur.

Tu es donc passionné de LaTeX ? Pourquoi donc, quels avantages présente ce langage ?

LaTeX — prononcer « latèk » ou « latèr » comme avec le « j » espagnol de « rota » ou le « ch » allemand de « maren » (machen), selon votre goût — est un langage de description de document, permettant de créer des écrits de grande qualité : livres, articles, mémoires, thèses, présentations projetées…

On peut considérer LaTeX comme un collaborateur spécialisé dans la mise en forme du travail en typographie tandis que l’auteur se consacre au contenu. La fameuse séparation de la forme et du fond : chacun sa spécialité !

Et ce KOMA-Script c’est quoi au juste par rapport à LaTeX ?

LaTeX a été écrit par des Américains pour des Américains. Pour pouvoir l’utiliser convenablement il nous faut charger des paqs qui permettent de l’adapter à notre langue car les formats de papiers américains et européens sont très différents et les mises en page par défaut de LaTeX ne sont adaptées ni à notre format a4, ni à notre typographie.

L’utilisation de KOMA-Script, outil universel d’écriture, permet de gérer la mise en page d’un ensemble de classes et de paqs polyvalents adaptés, grâce au paq babel, à de multiples langues et pratiques d’écriture, dont le français. Le paq KOMA-Script fonctionne avec XƎLATEX, il fournit des remplacements pour les classes LaTeX et met l’accent sur la typographie.

Les classes KOMA-Script permettent la gestion des articles, livres, documents, lettres, rapports et intègrent de nombreux paqs faciles à identifier : toutes et tous commencent par les trois lettres scr : scrbook, scrartcl, scrextend, scrlayer…

Tous ces paqs peuvent être utilisés non seulement avec les classes KOMA-Script, mais aussi avec les classes LaTeX standard et chaque paq a son propre numéro de version.

Donc ça peut être un ouvrage très utile, mais quel est le public visé particulièrement ?

j’ai envie de répondre tout le monde, même si, apparemment, ce système évolué s’adresse d’avantage aux étudiants investis dans des études supérieures en sciences dites « humaines » (Géographie, Histoire, Information et communication, Philosophie, Psychologie, Sciences du langage, Sociologie, Théologie…) et préparant un DUT, une licence, une thèse et même un doctorat plutôt qu’aux utilisateurs des sciences « exactes » qui peuvent être néanmoins traitées.

En réalité, je le pense aussi destiné aux utilisateurs basiques de MSWord, LibreOffice ou de logiciels équivalents de traitement de texte, amoureux de la belle écriture, respectueux des règles typographiques utilisées dans leur pays, désireux de se libérer des carcans plus ou moins imposés par la culture anglo-saxonne, même s’il n’est pas évident, au départ, d’abandonner son logiciel wysiwyg pour migrer vers d’autres habitudes liées à la séparation du fond et de la forme.

Est-ce que tu as d’autres projets pour faire partager des savoirs et savoir-faire à nos amis libristes ?

Oui, dans le même genre, j’ai sous le coude un ouvrage intitulé « Utiliser XƎLATEX c’est facile, même pour le 3^e âge  » écrit avec la complicité de Paul Bartholdi et Denis Mégevand, tous deux retraités de l’université de Genève, l’Unige. Ces derniers sont les co-auteurs, en octobre 2005, d’un didacticiel destiné à leurs étudiants « Débuter avec LaTeX » simple, clair, plutôt bien écrit et dont je m’inspire, avec leurs autorisations, pour composer la trame de mon ouvrage qui sera enrichi (l’original compte 98 pages) et portera – comme son titre le laisse supposer – sur l’usage de XƎLATEX, incluant des développements et surtout des exemples de codes détaillés et commentés de diverses applications (mon objectif est de me limiter à 400 pages), mais ne le répétez pas…

• Vous pouvez découvrir et télécharger le guide KOMA-SCRIPT sur cette page Framabook

Mine de rien, entre les services Dégooglisons Internet et les projets Framasoft, nous maintenons près d’une cinquantaine de sites/projets ouverts au public.

C’est bien joli, mais si on n’accompagne pas ces sites des savoir-faire et outils pour mieux vous aider à vous en emparer… c’est triste, non ?

Un peu de cathédrale dans notre joli bazar…

Depuis près de trois ans que nous Dégooglisons Internet, nous n’aurions rien pu faire sans votre aide. Nous savons que proposer des outils c’est bien, et que cela ne suffit pas. Il faut aussi les présenter, donner des tutoriels, des outils pour les comprendre et les prendre en main.

Bien entendu, ces logiciels sont déjà souvent soutenus par leurs propres communautés, qui proposent leur propre documentation dont chacun·e peut bénéficier. Il nous fallait, néanmoins, un endroit où rassembler tout cela.

Et depuis trois ans, nombre d’entre nous (contributeurs et contributrices, bénévoles et salarié·e·s…) ont apporté leur petite pierre à l’édifice. Il fallait nous voir, à chaque nouvelle contribution, nous émerveiller :

« Chouette ! Arpinux a fait une vidéo de prise en main de Framapic, pour mieux héberger ses images ! »

« Ah ! je me suis bien marré devant la présentation de Framapack que Pyves vient de nous proposer. J’espère que de plus en plus de windowsiens l’utiliseront pour télécharger des logiciels libres… »

« Attend, en plus de coder des fonctionnalités à Nexcloud pour ouvrir Framagenda, Tcit il s’est fadé d’écrire une jolie documentation pour synchroniser ses rendez-vous et ses contacts… GG ! »

« Sérieusement, le groupe Framalang s’est encore surpassé en traduisant la doc de Mattermost… Ça va bien aider à ce que les gens s’emparent de Framateam pour abandonner leurs groupes Facebook. »

« Oh, tu as vu la vidéo de SVTux pour découvrir Framapad ? En deux minutes, on voit que le libre peut faire aussi bien que GoogleDocs. »

« Pouhiou a encore trippé sur sa présentation de Framanotes. J’espère que Turtl aura autant de succès qu’Evernotes… »

« Franchement, les tutos de Cartocité pour utiliser Umap et Framacartes sont excellents… Si ça pouvait libérer les gens de Google Maps… »

(L’est-y pas belle, la vidéo Framalistes de Nicolas Geiger pour le site Colecti.cc ?)

Au départ, nous avons essayé de mettre les liens vers ces outils de documentation dans chaque page d’accueil de chacun de nos projets, afin que vous ayez tout sous la main dès que vous commencez à vous y intéresser… Mais souvent, une fois que vous êtes dans le service, vous n’allez plus voir la page d’accueil. On le sait, parce que nous, on fait pareil.

Alors nous avons lancé le défi à JosephK de mettre un peu de cathédrale dans ce merveilleux bazar, et de rassembler nos documentations en un seul et même endroit. N’écoutant que les clapotis de son clavier, ce dernier a décidé de collecter, d’organiser et de présenter tout cela sous la forme d’un gitbook, afin d’avoir un outil que l’on puisse modifier, amender et mettre à jour de façon collaborative (et pas trop ardue).

Demandez la doc !

Le principe est simple : vous cherchez comment utiliser un de nos services ? Pourquoi choisir tel Frama-bidule ? À quoi sert tel Framachin ? rendez-vous sur docs.framasoft.org.

Vous y serez accueillies par un choix de langue (parce qu’un jour, peut-être, on pourrait avoir des versions en anglais, breton ou espéranto).

Puis sur la page d’accueil, vous verrez une barre latérale qui vous permet de vous guider dans l’ensemble de notre documentation (elle s’adapte selon la rubrique dans laquelle vous vous trouvez). C’est dans la colonne principale, à droite, que se trouvent l’accès aux informations. Tout en haut, vous y trouverez des guides pratiques.

Ce sont des guides à destination du grand public, regorgeant d’informations aussi pratiques qu’indispensables. Pour l’instant, nous y avons inclus :

• Libertés Numériques, de C. Masutti, déjà paru chez Framabook
• L’auto-hébergement facile, de X. Cartron

(si vous voulez nous proposer le vôtre, rendez-vous dans la prochaine partie de cet article)

Ensuite, toujours sur cette page, vous y trouverez une liste des services Framasoft.

Ce sont l’ensemble des services Dégooglisons Internet sur lesquels nous avons une documentation en Français et (plus ou moins ^^) à jour à proposer.

Il vous suffit de cliquer sur le service qui vous intéresse pour découvrir les outils que nous avons pu récolter à son sujet.

Bien entendu, si vous ne trouvez pas votre service préféré et/ou que vous souhaitez proposer un élément de documentation, nous sommes preneurs (voir plus bas).

Enfin, toujours sur cette page, vous y verrez une rubrique « Culture et Logiciels Libres »

Ici, vous aurez des savoirs et savoir-faire sur les projets Framasoft qui ne sont pas des services Dégooglisons, qui tendent à promouvoir le logiciel libre et sa culture.

Libre à vous de cliquer et de consulter ce que bon vous semble, et de faire passer les liens à vos ami·e·s, collaborateurs et collaboratrices !

Une documentation qui n’attend que vous

Bien entendu, l’ensemble de ces documents sont libres. Par défaut, la licence utilisée pour les productions Framasoft est la CC-BY-SA, mais prenez soin de vérifier pour chaque outil de documentation, car leurs auteurs et autrices peuvent tout à fait les avoir placé sous une autre licence libre ^^ !

C’est néanmoins une des grandes forces du Libre : n’importe qui peut y participer.

Vous cherchez à soutenir le (logiciel) libre sans forcément savoir coder ? Présentez votre service ou projet favori avec une petite vidéo, une présentation animée, un texte avec captures d’images… Nous vous l’assurons, cela aidera énormément de monde à passer le pas et à adopter du libre dans ses habitudes numériques.

Pour participer, deux cas de figure :

• Vous connaissez le git, les push et pull request ne vous font pas peur ? : rendez-vous sur la forge de notre gitbook pour proposer vos commits afin que l’on merge tout cela ensemble.
• Vous n’avez rien compris à la phrase ci dessus ? (ne vous inquiétez pas, celui qui l’a écrite est comme vous !) Rendez-vous sur notre forum des bénévoles, partie tutoriels, pour proposer vos tutos, vidéos, et autres trucs en -os !

Enfin, une manière toute simple de participer, c’est simplement d’aller lire ces petits bouts de savoirs qui aident à mieux se dégoogliser… et de les partager avec son entourage !

Vous avez déjà perdu une soirée à errer de vidéo en vidéo suivante ? À cliquer play en se disant « OK c’est la dernière… » puis relever les yeux de votre écran 3 heures plus tard… ?

C’est grâce à (ou la faute de, au choix !) l’algorithme des recommandations, une petite recette qui prend plein d’éléments en compte pour vous signaler les vidéos qui peuvent vous intéresser.

Guillaume Chaslot a travaillé sur cet algorithme. Il a même créé un petit outil open-source pour le tester, afin de valider sa théorie : ces recommandations nous pousseraient de plus en plus vers les « faits alternatifs » (ça s’appelle aussi une légende urbaine, un complot, une fiction, du bullshit… vous voyez l’idée.)

Le groupe Framalang a décidé de traduire cet article passionnant.

Ne soyons pas complotistes à notre tour. Cet article ne dit pas que Google veut nous remplir la tête de mensonges et autres légendes numériques. Il s’agirait là, plutôt, d’un effet de bord de son algorithme.

Nous ne doutons pas, en revanche, qu’un des buts premiers de Google avec ses recommandations YouTube est de captiver notre attention, afin de vendre à ses clients notre temps de cerveau disponible (et d’analyser nos comportements au passage pour remplir ses banques de données avec nos vies numériques).

Sauf qu’avec ce genre de vision (et de buts) à court/moyen terme, on ne réfléchit pas aux conséquences sur le long terme. Lorsque l’on représente l’endroit où une grande portion de notre civilisation passe la majeure partie de son temps… C’est problématique, non ?

Tout comme les révélations de Tristan Harris, ce témoignage nous rappelle que, même chez les géants du web, notre monde numérique est tout jeune, immature, et qu’il est grand temps de prendre du recul sur les constructions que nous y avons dressées : car chacun de ces systèmes implique ses propres conséquences.

Comment l’I.A. de YouTube favorise les « faits alternatifs »

de Guillaume Chaslot, source : Medium.

Traduction : Jerochat, jaaf, dominix, mo, goofy, Asta, Opsylac, Nimanneau, audionuma, Lyn. + les anonymes

Les I.A. sont conçues pour maximiser le temps que les utilisateurs passent en ligne… Et pour ce faire, la fiction, souvent, dépasse la réalité.

Tout le monde a déjà entendu parler des théories du complot, des faits alternatifs ou des fake news qui circulent sur Internet. Comment sont-ils devenus si répandus ? Quel est l’impact des algorithmes de pointe sur leur succès ?

Ayant moi-même travaillé sur l’algorithme de recommandation de YouTube, j’ai commencé à enquêter, et je suis arrivé à la conclusion que le puissant algorithme que j’avais contribué à concevoir joue un rôle important dans la propagation de fausses informations.

Pour voir ce que YouTube promeut actuellement le plus, j’ai développé un explorateur de recommandations open source qui extrait les vidéos les plus recommandées sur une requête donnée. Je les ai comparées aux 20 premiers résultats venant de requêtes identiques sur Google et Youtube Search.
Les résultats sur les 5 requêtes suivantes parlent d’eux-mêmes :

1 — Question élémentaire : « La Terre est-elle plate ou ronde ? »

2 — Religion : « Qui est le Pape ? »

3 —Science : « Le réchauffement climatique est-il une réalité ? »

4 —Conspirations : « Est-ce que le Pizzagate est vrai ? »

Le Pizzagate est une théorie du complot selon laquelle les Clinton auraient été à la tête d’un réseau pédophile en lien avec une pizzeria de Washington. Des vidéos faisant la promotion de cette théorie ont été recommandées des millions de fois sur YouTube pendant les mois précédant l’élection présidentielle américaine de 2016.

5 — Célébrités: « Qui est Michelle Obama ? »

Pourquoi les recommandations sont-elles différentes des résultats de recherche ?

Dans ces exemples, une recherche YouTube et une recommandation YouTube produisent des résultats étonnamment différents, alors que les deux algorithmes utilisent les mêmes données. Cela montre que de petites différences dans les algorithmes peuvent produire de grosses différences dans les résultats. La recherche est probablement optimisée dans un objectif de pertinence, alors que les recommandations prennent sûrement davantage en compte le temps de visionnage.

YouTube ne recommande pas ce que les gens « aiment »

Étonnamment, on remarque que les « j’aime » ou « je n’aime pas » (pouce bleu ou rouge) ont peu d’impact sur les recommandations. Par exemple, beaucoup de vidéos qui prétendent que Michelle Obama est « née homme » ont plus de pouces rouges que de bleus, et pourtant elles sont toujours fortement recommandées sur YouTube. Il semble que YouTube accorde davantage d’importance au temps de visionnage qu’aux « j’aime ».

Ainsi, si « la Terre est plate » maintient les utilisateurs connectés plus longtemps que « la Terre est ronde », cette théorie sera favorisée par l’algorithme de recommandation.

L’effet boule de neige favorise les théories du complot.

Une fois qu’une vidéo issue d’une théorie du complot est favorisée par l’I.A., cela incite les créateurs de contenus à charger des vidéos supplémentaires qui confirment le complot. En réponse, ces vidéos supplémentaires font augmenter les statistiques en faveur du complot. Et ainsi, le complot est d’autant plus recommandé.

Finalement, le nombre important de vidéos qui soutiennent une théorie du complot rend cette dernière plus crédible. Par exemple, dans l’une des vidéos sur le thème de « la terre plate », l’auteur a commenté

Il y a 2 millions de vidéos sur la « terre plate » sur YouTube, ça ne peut pas être des c***!

Ce que nous pouvons faire

L’idée ici n’est pas de juger YouTube. Ils ne le font pas intentionnellement, c’est une conséquence involontaire de l’algorithme. Mais chaque jour, les gens regardent plus d’un milliard d’heures de contenu YouTube.

Parce que YouTube a une grande influence sur ce que les gens regardent, il pourrait également jouer un rôle important en empêchant la propagation d’informations alternatives, et le premier pas vers une solution serait de mesurer cela.

Faites des expériences avec l’explorateur de recommandations si vous souhaitez découvrir ce que YouTube recommande le plus au sujet des thèmes qui vous tiennent à cœur.

Chaque semaine, l’équipe Framalang vous propose la traduction d’un chapitre de Roads and Bridges de Nadia Eghbal, une enquête fouillée qui explore les problématiques des infrastructures numériques, et en particulier leur intrication avec l’écosystème open source.

Après avoir exploré dans le précédent chapitre différents types de modèles économiques adaptés aux projets open source (retrouvez ici tous les chapitres antérieurs), l’auteure examine ici les cas de projets s’appuyant sur les dons ou le mécénat : du financement participatif au soutien institutionnalisé d’une entreprise, elle analyse les avantages et les limites de chaque solution, et livre les témoignages de nombreux porteurs de projets ou contributeurs qui relatent leur expérience au cœur de projets aussi divers qu’OpenSSL, jQuery ou encore Node.js.

Traduction Framalang : goofy, dominix, Opsylac, Rozmador, lyn, Julien, Penguin, Luc, serici, pasquin, et 2 anonymes

La deuxième option pour financer des projets d’infrastructure numérique consiste à trouver des mécènes ou des donateurs. Il s’agit d’une pratique courante dans les cas de figure suivants :

• Il n’existe pas de demande client facturable pour les services proposés par le projet.
• Rendre l’accès payant empêcherait l’adoption (on ne pourrait pas, par exemple, faire payer l’utilisation d’un langage de programmation comme Python, car personne ne l’utiliserait ; ce serait comme si parler anglais étant payant).
• Le projet n’a pas les moyens de financer des emplois rémunérés, ou bien il n’y a pas de volonté de la part du développeur de s’occuper des questions commerciales.
• La neutralité et le refus de la commercialisation sont considérés comme des principes importants en termes de gouvernance.

Dans ce type de situation, un porteur de projet cherchera des mécènes qui croient en la valeur de son travail et qui sont disposés à le soutenir financièrement. À l’heure actuelle, il existe deux sources principales de financement : les entreprises de logiciel et les autres développeurs.

Le financement participatif

Certains travaux de développement obtiennent des fonds grâce à des campagnes de financement participatif (« crowdfunding ») via des plateformes telles que Kickstarter ou Indiegogo. Bountysource, le site de récompenses dont nous parlions dans un chapitre précédent, possède également une plateforme appelée Salt dédiée au financement participatif de projets open source.

Andrew Godwin, un développeur du noyau Django résidant à Londres, a ainsi réussi à récolter sur Kickstarter 17952£ (environ 21000€) de la part de 507 contributeurs, afin de financer des travaux de base de données pour Django. Le projet a été entièrement financé en moins de quatre heures.

Pour expliquer sa décision de lever des fonds pour un projet open source, Godwin écrit :

« Une quantité importante de code open source est écrit gratuitement. Cependant, mon temps libre est limité. Je dispose actuellement d’une seule journée libre par semaine pour travailler, et j’adorerais la consacrer à l’amélioration de Django, plutôt qu’à du conseil ou à de la sous-traitance.

L’objectif est double : d’une part, garantir au projet un temps de travail conséquent et au moins 80 heures environ de temps de codage ; et d’autre part prouver au monde que les logiciels open source peuvent réellement rémunérer le temps de travail des développeurs. »

À l’instar des récompenses, le financement participatif s’avère utile pour financer de nouvelles fonctionnalités, ou des développements aboutissant à un résultat clair et tangible. Par ailleurs, le financement participatif a moins d’effets pervers que les récompenses, notamment parce qu’organiser une campagne de financement demande plus d’efforts que de poster une offre de récompense, et parce que le succès du financement repose en grande partie sur la confiance qu’a le public dans la capacité du porteur de projet à réaliser le travail annoncé. Dans le cas de Godwin, il était l’un des principaux contributeurs au projet Django depuis six ans et était largement reconnu dans la communauté.

Toutefois, le financement participatif ne répond pas à la nécessité de financer les frais de fonctionnement et les frais généraux. Ce n’est pas une source de capital régulière. En outre, planifier et mettre en œuvre une campagne de financement participatif demande à chaque fois un investissement important en temps et en énergie. Enfin, les donateurs pour ces projets sont souvent eux-mêmes des développeurs ou des petites entreprises – et un porteur de projet ne peut pas éternellement aller toquer à la même porte pour financer ses projets.

Avec le recul, Godwin a commenté sa propre expérience :

« Je ne suis pas sûr que le financement participatif soit totalement compatible avec le développement open source en général ; non seulement c’est un apport ponctuel, mais en plus l’idée de rétribution est souvent inadéquate car elle nécessite de promettre quelque chose que l’on puisse garantir et décrire a priori.

S’en remettre uniquement à la bonne volonté du public, cela ne fonctionnera pas. On risque de finir par s’appuyer de manière disproportionnée sur des développeurs, indépendants ou non, à un niveau personnel – et je ne pense pas que ce soit viable. »

À côté des campagnes de financement participatif, plusieurs plateformes ont émergé pour encourager la pratique du « pourboire » (tipping en anglais) pour les contributeurs open source : cela consiste à verser une petite somme de revenu régulier à un contributeur, en signe de soutien à son travail. Deux plateformes populaires se distinguent : Patreon (qui ne se limite pas exclusivement aux contributeurs open source) et Gratipay (qui tend à fédérer une communauté plus technique).

L’idée d’un revenu régulier est alléchante, mais souffre de certains problèmes communs avec le financement participatif. On remarque notamment que les parrains (patrons ou tippers en anglais) sont souvent eux-mêmes des développeurs, avec une quantité limitée de capital à se promettre les uns aux autres. Les dons ont généralement la réputation de pouvoir financer une bière, mais pas un loyer. Gratipay rassemble 122 équipes sur sa plateforme, qui reçoivent collectivement 1000 $ par semaine, ce qui signifie qu’un projet touche en moyenne moins de 40$ par mois.

Même les très gros projets tels que OpenSSL ne généraient que 2000$ de dons annuels avant la faille Heartbleed. Comme expliqué précédemment, après Heartbleed, Steve Marquess, membre de l’équipe, a remarqué « un déferlement de soutien de la part de la base de la communauté OpenSSL » : la première vague de dons a rassemblé environ 200 donateurs pour un total de 9000$.

Marquess a remercié la communauté pour son soutien mais a également ajouté :

« Même si ces donations continuent à arriver au même rythme indéfiniment (ce ne sera pas le cas), et même si chaque centime de ces dons allait directement aux membres de l’équipe OpenSSL, nous serions encore loin de ce qu’il faudrait pour financer correctement le niveau de main-d’œuvre humaine nécessaire à la maintenance d’un projet aussi complexe et aussi crucial. Même s’il est vrai que le projet « appartient au peuple », il ne serait ni réaliste ni correct d’attendre de quelques centaines, ou même de quelques milliers d’individus seulement, qu’ils le financent à eux seuls. Ceux qui devraient apporter les vraies ressources, ce sont les entreprises lucratives et les gouvernements qui utilisent OpenSSL massivement et qui le considèrent comme un acquis. »

(À l’appui de l’argument de Marquess, les dons de la part des entreprises furent par la suite plus importants, les sociétés ayant davantage à donner que les particuliers. La plus grosse donation provint d’un fabricant de téléphone chinois, Smartisan, pour un montant de 160000$. Depuis, Smartisan a continué de faire des dons substantiels au projet OpenSSL.)

Au bout du compte, la réalité est la suivante : il y a trop de projets, tous qualitatifs ou cruciaux à leur manière, et pas assez de donateurs, pour que la communauté technique (entreprises ou individus) soit en mesure de prêter attention et de contribuer significativement à chacun d’eux.

Le mécénat d’entreprises pour les projets d’infrastructure

À plus grande échelle, dans certains cas, la valeur d’un projet devient si largement reconnue qu’une entreprise finit par recruter un contributeur pour travailler à plein temps à son développement.

John Resig est l’auteur de jQuery, une bibliothèque de programmation JavaScript qui est utilisée par près des 2/3 du million de sites web les plus visités au monde. John Resig a développé et publié jQuery en 2006, sous la forme d’un projet personnel. Il a rejoint Mozilla en 2007 en tant que développeur évangéliste, se spécialisant notamment dans les bibliothèques JavaScript.

La popularité de jQuery allant croissante, il est devenu clair qu’en plus des aspects liés au développement technique, il allait falloir formaliser certains aspects liés à la gouvernance du projet. Mozilla a alors proposé à John de travailler à plein temps sur jQuery entre 2009 et 2011, ce qu’il a fait.

À propos de cette expérience, John Resig a écrit :

« Pendant l’année et demi qui vient de s’écouler, Mozilla m’a permis de travailler à plein temps sur jQuery. Cela a abouti à la publication de 9 versions de jQuery… et à une amélioration drastique de l’organisation du projet (nous appartenons désormais à l’organisation à but non lucratif Software Freedom Conservancy, nous avons des réunions d’équipe régulières, des votes publics, fournissons des états des lieux publics et encourageons activement la participation au projet). Heureusement, le projet jQuery se poursuit sans encombre à l’heure actuelle, ce qui me permet de réduire mon implication à un niveau plus raisonnable et de participer à d’autres travaux de développement. »

Après avoir passé du temps chez Mozilla pour donner à jQuery le support organisationnel dont il avait besoin, John a annoncé qu’il rejoindrait la Khan Academy afin de se concentrer sur de nouveaux projets.

Cory Benfield, développeur Python, a suivi un chemin similaire. Après avoir contribué à plusieurs projets open source sur son temps libre, il est devenu un développeur-clé pour une bibliothèque essentielle de Python intitulée Requests. Cory Benfield note que :

« Cette bibliothèque a une importance comparable à celle de Django, dans la mesure où les deux sont des « infrastructures critiques » pour les développeurs Python. Et pourtant, avant que j’arrive sur le projet, elle était essentiellement maintenue par une seule personne. »

Benfield estime qu’il a travaillé bénévolement sur le projet environ 12 heures par semaine pendant presque quatre ans, en plus de son travail à plein temps. Personne n’était payé pour travailler sur Requests.

Pendant ce temps, HP embauchait un employé, Donald Stufft, pour se consacrer spécifiquement aux projets en rapport avec Python, un langage qu’il considère comme indispensable à ses logiciels. (Donald est le développeur cité précédemment qui est payé à plein temps pour travailler sur le packaging Python). Donald a alors convaincu son supérieur d’embaucher Cory pour qu’il travaille à temps plein sur des projets Python. Il y travaille toujours.

Les entreprises sont des acteurs tout désignés pour soutenir financièrement les projets bénévoles qu’elles considèrent comme indispensables à leurs activités, et quand des cas comme ceux de John Resig ou de Cory Benfield surviennent, ils sont chaleureusement accueillis. Cependant, il y a des complications.

Premièrement, aucune entreprise n’est obligée d’embaucher quelqu’un pour travailler sur des projets en demande de soutien ; ces embauches ont tendance à advenir par hasard de la part de mécènes bienveillants. Et même une fois qu’un employé est embauché, il y a toujours la possibilité de perdre ce financement, notamment parce que l’employé ne contribue pas directement au résultat net de l’entreprise. Une telle situation est particulièrement périlleuse si la viabilité d’un projet dépend entièrement d’un seul contributeur employé à plein temps. Dans le cas de Requests, Cory est le seul contributeur à plein temps (on compte deux autres contributeurs à temps partiel, Ian Cordasco et Kenneth Reitz).

Une telle situation s’est déjà produite dans le cas de « rvm », un composant critique de l’infrastructure Ruby. Michal Papis, son auteur principal, a été engagé par Engine Yard entre 2011 et 2013 pour soutenir le développement de rvm. Mais quand ce parrainage s’est terminé, Papis a dû lancer une campagne de financement participatif pour continuer de financer le développement de rvm.

Le problème, c’est que cela ne concernait pas seulement rvm. Engine Yard avait embauché plusieurs mainteneurs de projets d’infrastructure Ruby, qui travaillaient notamment sur JRuby, Ruby on Rails 3 et bundler. Quand les responsables d’Engine Yard ont été obligés de faire le choix réaliste qui s’imposait pour la viabilité de leur entreprise, c’est-à-dire réduire leur soutien financier, tous ces projets ont perdu leurs mainteneurs à temps plein, et presque tous en même temps.

L’une des autres craintes est qu’une entreprise unique finisse par avoir une influence disproportionnée sur un projet, puisqu’elle en est de facto le seul mécène. Cory Benfield note également que le contributeur ou la contributrice lui-même peut avoir une influence disproportionnée sur le projet, puisqu’il ou elle dispose de beaucoup plus de temps que les autres pour faire des contributions. De fait, une telle décision peut même être prise par une entreprise et un mainteneur, sans consulter le reste de la communauté du projet.

On peut en voir un exemple avec le cas d’Express.js, un framework important pour l’écosystème Node.js. Quand l’auteur du projet a décidé de passer à autre chose, il en a transféré les actifs (en particulier le dépôt du code source et le nom de domaine) à une société appelée StrongLoop dont les employés avaient accepté de continuer à maintenir le projet. Cependant StrongLoop n’a pas fourni le soutien qu’attendait la communauté, et comme les employés de StrongLoop étaient les seuls à avoir un accès administrateur, il est devenu difficile pour la communauté de faire des contributions. Doug Wilson, l’un des principaux mainteneurs (non-affilié à StrongLoop), disposait encore d’un accès commit et a continué de traiter la charge de travail du projet, essayant tant bien que mal de tout gérer à lui seul.

Après l’acquisition de StrongLoop par IBM, Doug déclara que StrongLoop avait bel et bien tué la communauté des contributeurs.

« Au moment où on est passé à StrongLoop, il y avait des membres actifs comme @Fishrock123 qui travaillaient à créer… de la documentation. Et puis tout à coup, je me suis retrouvé tout seul à faire ça sur mon temps libre alors que les demandes de support ne faisaient que se multiplier… et pendant tout ce temps, je me suis tué à la tâche, je me suis engagé pour le compte StrongLoop. Quoi qu’il arrive, jamais plus je ne contribuerai à aucun dépôt logiciel appartenant à StrongLoop. »

Finalement, le projet Express.js a été transféré de StrongLoop à la fondation Node.js, qui aide à piloter des projets appartenant à l’écosystème technologique Node.js.

En revanche, pour les projets open source qui ont davantage d’ampleur et de notoriété, il n’est pas rare d’embaucher des développeurs. La Fondation Linux a fait savoir, par exemple, que 80% du développement du noyau Linux est effectué par des développeurs rémunérés pour leur travail. La fondation Linux emploie également des Fellows [« compagnons » selon un titre consacré, NdT] payés pour travailler à plein temps sur les projets d’infrastructure, notamment Greg Kroah-Hartman, un développeur du noyau Linux, et Linus Torvalds lui-même, le créateur de Linux.

Un service d’agenda touche à l’intime. On a beau partager le rendez-vous « déjeuner d’affaires » et mettre en privé celui qui est noté « Dépist.HIV »… notre emploi du temps est malgré tout partagé avec celui à qui on le confie : l’hébergeur.

Google Agenda.

Apple Agenda.

Microsoft Agenda…

Si vous êtes le produit, ce n’est pas gratuit

(ceci est une référence à l’excellente tribune de Laurent Chemla, à lire !)

Comment Siri (Apple™) sait-elle que vous préférez tel restaurant pour vos déjeuners d’affaires ? Comment Cortana (Microsoft™) peut-elle vous proposer d’ajouter ce PowerPoint™ à la réunion que vous êtes en train de planifier ? Comment Google Now™ sait-elle vous prévenir à temps de rejoindre votre voiture afin d’éviter les bouchons pour aller à votre rendez-vous ? (eh oui : les GAFAM accordent les assistants numériques au féminin -_-)

C’est simple : vous leur donnez ces informations et ils ne se privent pas pour les scanner, analyser, indexer. Pour alimenter votre profil personnel, votre graphe social. Les gestionnaires d’emploi du temps sont l’illustration parfaite de ce que recouvre l’expression « données personnelles ». Tout simplement, la traduction de nos vies : nos vies numériques, liées à nos vies physiques. Où nous sommes, à quel moment, pour quoi faire, avec qui…

« Oui, mais c’est tellement pratique…»

En effet. Mais ce confort a un prix : des morceaux de votre vie… et de celle des personnes qui la partagent, par ricochet. Bien sûr, vous pouvez tenter de tricher, de noter une cryptique « chasse au crabe avec Jérôme » pour indiquer l’accompagnement de votre frère à sa séance de chimiothérapie. Mais si lui (ou vous) n’a pas désactivé la géolocalisation de vos téléphones, une fois arrivé-e-s au centre anti-cancer, un GAFAM aura vite fait de recouper les données et de déjouer votre subterfuge. Surtout si vous avez utilisé votre téléphone en mode GPS pour trouver cette fichue clinique…

Sans aller si loin dans l’intime, nous ne souhaitons pas toujours dévoiler les informations de nos plannings collaboratifs : les réunions d’un syndicat, le rétro-planning du projet phare de votre entreprise, le local d’accueil pour victimes de violences conjugales, les horaires d’arrivée et de départ des loupiots à la crèche, etc.

Un planning, ou un agenda, note ce que vous faites de votre vie et avec qui. Il était plus qu’urgent de trouver une alternative éthique offrant une réelle indépendance.

L’histoire du stagiaire qui fit la nique à Google Agenda

Nous connaissions déjà Thomas, vu qu’il est l’un des développeurs principaux de wallabag, le logiciel libre qui fait fonctionner Framabag, notre service de lecture différée d’articles Web. Lorsqu’il nous a proposé de faire son stage de fin d’études chez nous, nous avons tout de suite pensé à ce projet d’agenda libre !

Le besoin était aussi grand que précis : il nous fallait une solution permettant de gérer des agendas privés, confidentiels et publics. Qui offre la possibilité d’inviter (par courriel) une personne sur un des événements qu’on y saisit. Qui soit vraiment facile à installer sur un serveur (sur le petit hébergement mutualisé d’une association, par exemple). Et, enfin, qui se base sur des logiciels libres déjà existants, parce que même si aucun ne remplissait déjà tous nos critères, on n’allait pas non plus réinventer la roue alors qu’on pouvait simplement contribuer à un projet (et une communauté) déjà reconnu(e).

Thomas a donc travaillé d’arrache-pied sur l’application Agenda de ownCloud/NextCloud, en collaboration avec les communautés de ces logiciels, afin qu’on puisse rendre certains plannings publics (si on le veut) et que l’on puisse s’abonner à des agendas existants (par le standard CalDAV). Le moins que l’on puisse dire, c’est que c’est un succès, vu l’accueil que Thomas a reçu lors de sa présentation à la ownCloud Contributors Conference en septembre dernier à Berlin.

Le résultat ? Vous pouvez le tester dès aujourd’hui, il s’appelle Framagenda. La morale de cette histoire ? Au sortir de son stage, Thomas a été engagé en tant que développeur chez Framasoft pour un CDD de six mois, que nous envisageons de pérenniser si tel est son souhait, et si les moyens que vous nous offrez par vos dons nous le permettent.

Framagenda expliqué aux pros du mulot

Ici, nous allons être un peu techniques mais brefs. Si vous préférez un petit tutoriel illustré, n’hésitez pas à passer directement au titre suivant ;).

Framagenda vous permet :

• La création d’un compte (sur une instance Nextcloud, mais avec 5 Mo d’espace disque, ce n’est pas un Framadrive)
• La création et l’édition de multiples agendas (perso, pro, associatif, fêtes familiales, etc.)
• La création d’événements (rendez-vous) dans un agenda :
  • Privé, confidentiel, public…
  • Possibilité de détailler : horaires, lieux, description…
  • Possibilité de faire des rappels
  • Récurrence : possibilité de paramétrer des événements qui se répètent régulièrement
  • Possibilité d’ajouter des participant-e-s par email (avec envoi d’email & d’un fichier .ics en pièce jointe)
• L’intégration avec un carnet de contacts (le calendrier de leurs anniversaires est automatiquement créé \o/)
• L’intégration avec les listes de tâches (une par agenda, mais plus si affinités)
• La synchronisation avec vos appareils (exemple pour Android : via DAVDroid)
  • de vos agendas (avec un choix agenda par agenda)
  • des listes de tâches afférentes (exemple pour Android : avec Open Tasks)
  • de vos contacts (toujours via DAVDroid pour Android)
• Le partage d’un ou plusieurs agendas avec d’autres utilisateurs de Framagenda (par leur pseudo)
• L’abonnement à d’autres agendas/calendriers externes (intégration via ics/WebCal, dont les calendriers des GAFAM : Gmail, Apple, Outlook, etc.)
• La création de liens publics vers chacun de vos agendas :
  • Lien « vue publique », toute simple
  • Lien CalDAV pour les clients (Thunderbird, DAVDroid, etc.)
  • Lien WebDAV pour ajouter dans Google Agenda & Cie
• La possibilité de publier un agenda sur votre site web (code d’intégration iframe)
• L’import ics (dans un nouvel agenda ou dans un agenda existant)
• L’export ics (agenda ou événement)

Framagenda est basé sur l’application Nextcloud 11 et l’application Agenda (1.5), sous licence GNU AGPL v3. Si vous voulez l’installer sur vos serveurs (et gagner en indépendance) notre tutoriel d’installation se trouve ici.

« Expliquez-moi Framagenda en un exemple simple à comprendre »

C’est une demande que nous avons régulièrement, le fameux exemple « simple à comprendre ». C’est aussi un bon exercice d’expliquer comment fonctionne un service et ce qu’il peut faire (à une personne qui n’est pas forcément passionnée par l’informatique). Nous nous y plions donc avec plaisir mais surtout avec cet exemple :

Farida se dégooglise de l’Agenda
(et du carnet de contacts)

Farida n’est pas une libriste de la première heure : juste une personne indépendante à qui ça pose problème de dévoiler sa vie à Google. Agnès, qui coache l’équipe de football de sa fille, lui a parlé de Framagenda : elle décide de se lancer.

Pour cela elle doit se créer un compte. Mouais, OK, mais que va-t-on faire de ses données ? Elle prend cinq minutes pour lire les conditions générales d’utilisation des services Framasoft (il n’en faut pas plus) et cela lui convient. Du coup, elle :

1. se rend donc sur Framagenda.org ;
2. clique sur « S’enregistrer » ;
3. saisit son adresse email pour recevoir un lien de vérification ;
4. crée son compte dans la fenêtre ouverte par le lien de vérification.

Bien. Une fois son compte créé, elle n’a plus qu’à saisir son mot de passe, quelque chose de somme toute classique. C’est bien, dès l’accueil, elle a droit à quelques liens pour savoir comment utiliser son Framagenda : de la documentation, des outils pour le synchroniser sur son mobile…

Elle décide de voir si elle arrive à récupérer son agenda personnel Google. Ce n’est pas hyper intuitif (tiens, Google est moins son ami, sur ce coup !), mais en suivant leur tutoriel, elle arrive à aller dans les paramètres dudit agenda pour obtenir l’export de son calendrier.

Bon il lui faut le dézipper (merci Google, grrrrr), mais ça y est, elle a un fichier .ics ! Ce doit être ça qu’il lui faut…

Dans son Framagenda, il lui suffit de cliquer sur « paramètres » puis sur « importer un agenda » pour qu’elle puisse intégrer son Google Agenda à son agenda personnel (ouf, sauvée, c’est bien le fichier .ics qu’il lui fallait !).

La voilà devant une interface d’agenda comme elle en connaît bien, avec au choix une visualisation de la journée, de la semaine, du mois ; ainsi qu’un agenda personnel (celui dans lequel elle a importé ses rendez-vous qui étaient sur Google) et un « Anniversaire de ses contacts » déjà intégrés.

Bon, c’est pas tout ça, mais samedi à 15 h elle a une réunion avec Agnès, justement, l’entraîneuse de l’équipe de foot de sa fille. Elle crée donc l’événement en cliquant sur l’horaire. Comme elle veut inviter Agnès au rendez-vous, elle clique sur « plus » pour détailler cet événement. Elle rentre l’email d’Agnès, pour que cette dernière soit prévenue du rendez-vous directement dans sa boite mail.

Sandrine trouve que finalement, c’est pas si compliqué que ça, de se dégoogliser. Elle se dit qu’elle devrait aller rencontrer des libristes près de chez elle. Du coup, elle va sur l’Agenda du Libre, LE site qui regroupe les événements publics des libristes en France. Farida voit que dans les flux, en bas, elle peut s’abonner au calendrier des rencontres libristes de sa région.

Bon, c’est bien gentil, mais entre le RSS, le WebCal, l’iCal et autres, elle ne sait que choisir (si ce n’est sa région : l’Occitanie). Heureusement, lorsqu’elle clique sur « nouvel abonnement » dans son Framagenda, elle voit qu’on lui demande une adresse Webcal : d’un clic-droit de la souris, elle copie l’adresse du lien WebCal de l’agenda du libre, et ajoute cet abonnement à son Framagenda.

La voilà désormais avec un agenda bien chargé. C’est bien. Mais ce serait tout de même mieux si elle pouvait l’avoir sur son téléphone. Mince : dans l’image qui l’a accueillie lors de son inscription, il y avait le lien d’un tuto pour synchroniser son agenda avec son téléphone Android, mais elle a oublié de noter ce lien… Pas de soucis, elle le retrouve dans l’aide de Framagenda.

Farida télécharge donc DAVDroid (3€99… si ce n’est pas gratuit c’est bien que c’est elle qui soutient le produit !) et se laisse porter par le tutoriel… Et voilà le travail !

#gallery-1 { margin: auto; } #gallery-1 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-1 img { border: 2px solid #cfcfcf; } #gallery-1 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Oh ! Incroyable ! En suivant le tuto d’installation de son agenda sur son téléphone, elle se rend compte qu’elle peut aussi y prendre les contacts qu’elle avait confiés à Google (ses ami-e-s, leurs téléphones, leurs emails et adresses physiques) et les importer dans son Framagenda…

Elle peut même ajouter les listes de tâches liées à chacun de ses agendas en utilisant l’application OpenTasks.

Cela ne lui prend que quelques tapotis de plus, alors elle s’exécute avec plaisir !

#gallery-2 { margin: auto; } #gallery-2 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-2 img { border: 2px solid #cfcfcf; } #gallery-2 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Du coup, Farida se demande si elle ne peut pas aller plus loin. Le club de foot de sa fille a besoin d’un agenda partagé pour afficher les entraînements, matchs et événements des différentes équipes.

Elle tente donc de créer un agenda « FootClub des Arceaux » avec un événement récurrent (entraînement tous les samedis matin pour l’équipe de sa fille). Du coup elle va cacher ses autres agendas (en cliquant sur leurs pastilles colorées) pour en voir le résultat :

Elle partage ensuite la tenue de cet agenda avec Agnès, la coach. Il lui suffit de cliquer sur l’icône partager à côté de l’agenda « FootClub des Arceaux » et de rentrer le pseudonyme d’Agnès. Comme Agnès est aussi sur Framagenda, cela se complète automatiquement et fonctionne directement.

Avec cette astuce, Agnès a elle aussi la main sur cet agenda partagé. Cela lui permet de rentrer les entraînements des autres équipes et les prochains matchs. En cherchant à partager le lien public de l’agenda du club de foot, Farida et elle se rendent compte qu’en regardant les paramètres de cet affichage public, elles ont justement un code HTML à intégrer dans le site web du club de foot ! Et voilà leur agenda en ligne !

Si on intègre ce code ici cela donne :

Ni Farida, ni Agnès ne se définissent comme expertes en informatique ou même Geeks. Pourtant, désormais, leurs rendez-vous, contacts et listes de tâches n’appartiennent plus ni à Google (pour Farida) ni à Apple (pour Agnès qui s’est désintoxiquée de l’Iphone). Prochaine étape : voir avec les libristes du coin si elles peuvent installer le même logiciel sur les serveurs du Foot-Club des Arceaux et y importer leurs données Framagenda (on leur a assuré qu’avec Nextcloud, c’est hyper facile).

Cette fois-ci, elles deviendront totalement indépendantes !

Si vous voulez les suivre sur cette route, c’est simple, la voie est libre : testez Framagenda !

Pour aller plus loin :

• Essayer Framagenda
• Le site officiel de Nexcloud (à soutenir !)
• Participer au code de Nextcloud
• Installer Nextcloud sur vos serveurs
• Dégooglisons Internet
• Soutenir Framasoft

José Antonio Rey, membre depuis plusieurs années de la communauté Ubuntu, témoigne de la richesse des échanges dans les communautés open source. Des communautés réunissant des gens que tout pourrait séparer : langue, culture, distance mais qui au contraire se rejoignent autour d’un but commun.

Faire tomber les barrières de la langue et de la distance dans les projets open source

Article original : Open source took me around the world

Par José Antonio Rey

Traduction : Framasky, goofy, audionuma, Brice, AFS

Les communautés open source ont été parmi les premières à utiliser Internet pour s’affranchir de la distance physique entre les personnes. Internet est un outil incroyable, puisqu’il nous permet de collaborer où que l’on soit. Peu importe que vous déjeuniez au pied de la tour Eiffel ou que vous vous réveilliez sous le soleil de San Francisco, Internet a permis de connecter les personnes de manière plus étroite.

J’habite au Pérou, et j’y ai toujours vécu. J’étudie au Pérou, et Internet m’a permis de découvrir des informations précieuses pour mes projets et ma vie en général. Néanmoins, lorsque j’ai rejoint la communauté Linux, ma vie a radicalement changé.

Une nuit, j’avais des problèmes avec mon écran qui ne fonctionnait pas correctement. Je me suis donc connecté à un canal IRC, et quelqu’un en Espagne m’a aidé à résoudre le problème. Ensuite, j’ai pris une décision que je n’ai jamais regrettée : je me suis connecté pour répondre à des questions posées par d’autres utilisateurs de Linux. Je l’ai fait un temps, me concentrant sur les communautés Ubuntu, et on m’a finalement demandé de rédiger un tutoriel pour la communauté. Je n’y connais pas grand chose, ai-je alors pensé, mais j’ai décidé de le faire quand même. J’ai présenté des trucs et astuces concernant l’utilisation du navigateur Firefox. Ma présentation s’est bien déroulée, même si j’étais plutôt nerveux. Cela m’a amené à rencontrer des gens de la communauté, et deux mois plus tard, je m’envolais vers San Francisco pour mon premier sommet des développeurs Ubuntu. Ce fut le premier de mes nombreux voyages.

Rejoindre une communauté Linux m’a permis d’améliorer bon nombre de mes compétences, en anglais par exemple. Ma langue maternelle est l’espagnol, le début de l’apprentissage a donc été difficile. La moitié de mes journées était en espagnol, l’autre en anglais. Tous mes logiciels fonctionnaient en anglais, et j’ai commencé à trouver bizarre de lire des traductions en espagnol. Améliorer mon anglais m’a aussi permis de me sentir un peu plus à l’aise lors de conversations avec d’autres personnes. Je commençais à m’impliquer de plus en plus, et j’ai donc fait la connaissance d’un grand nombre de personnes, des États-Unis, d’Australie, d’Inde, du Royaume-Uni, de Colombie, d’Argentine, d’Uruguay et d’autres pays. Le nombre de personnes que j’ai rencontrées est incroyable, et ne cesse d’augmenter. Bien sûr, le décalage horaire est une vraie plaie quand on travaille avec des gens tout autour du monde, mais c’est largement compensé par les avantages liés au fait de connaître ces gens et de travailler avec eux.

Ce passe-temps me permet de travailler sur de beaux projets qui m’intéressent. Et si j’ai un problème avec un logiciel, je peux le réparer moi-même ! Je n’ai pas besoin d’attendre que quelqu’un m’entende et fasse attention à moi. Encore mieux, j’apprends à utiliser de nouveaux outils en faisant cela. Si je suis bloqué ou si je ne sais pas comment régler un problème, la communauté est là pour me donner un coup de main.

En travaillant avec le Conseil des Communautés Locales d’Ubuntu (Ubuntu Local Communities Council), j’ai rendu service à des communautés partout dans le monde et les ai rendues plus autonomes, dans leurs actions de promotion par exemple. Les différences culturelles sont l’une des choses les plus difficiles à gérer dans un projet. Contrairement à ce que pensent certaines personnes, gérer un projet ce n’est pas seulement superviser les choses, parfois nous avons dû mettre fin à des disputes entre participants ou entre équipes. J’ai alors été frappé par cette caractéristique importante de la participation à une communauté en ligne : nous sommes tous des personnes avec des points de vue différents, et notre compréhension des choses et des problèmes peut varier en fonction de notre culture. Cela n’est pas quelque chose qui doit nous effrayer, mais bien une chose que nous devons comprendre. Cela montre à quel point notre monde est grand, comment Internet et les communautés du Libre peuvent nous rapprocher et quelle diversité règne dans notre communauté.

Grâce à Internet, les communautés open source ont le pouvoir de vous mettre en contact avec d’autres personnes à travers le monde, parfois vous les rencontrerez même dans le monde réel. Il existe plusieurs communautés qui organisent des rencontres de développeurs et des conférences. Et, si vous êtes assez actif, vous serez invité à y participer. En ce qui me concerne, les personnes qui développaient les logiciels voulaient connaître mes contributions, j’ai alors pu voyager tout autour du monde afin de les rencontrer pour en discuter.

En rejoignant une communauté open source, vous ne contribuez pas seulement à un logiciel, vous rejoignez un réseau de personnes disséminées à travers le monde qui rendent ce logiciel réalisable. Vous devrez franchir différentes barrières, et tout particulièrement celle de la langue. Mais je peux vous dire que c’est une des plus valorisantes expériences que vous pourrez vivre. Vous deviendrez meilleur dans des domaines variés, acquerrez de nouvelles compétences, en découvrirez d’autres, et cerise sur le gâteau, vous travaillerez avec une formidable équipe de personnes provenant de tous les coins du monde, toutes unies vers un objectif commun. Une fois que vous aurez rejoint une communauté open source, vous comprendrez comment un groupe de personnes travaillant avec le même but peut faire tomber toutes les barrières, même celle de la distance.

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.