D’autres technologies pour répondre à l’urgence de la personne ?

« Ce dont nous avons besoin, c’est le contraire de la Big Tech. Nous avons besoin de Small Tech – des outils de tous les jours conçus pour augmenter le bien-être humain, et non les profits des entreprises. »

Ce n’est pas une théorie complotiste : le profilage et la vente de données privées font, depuis des années, partie intégrante du modèle économique de la plupart des entreprises du numérique. Dans cet article traduit par Framalang, Aral Balkan (auquel nous faisons régulièrement écho) suggère qu’il est urgent de s’éloigner de ce modèle qui repose sur les résultats financiers pour gagner en indépendance et explique pourquoi c’est important pour chacun d’entre nous.

 

Article original : In 2020 and beyond, the battle to save personhood and democracy requires a radical overhaul of mainstream technology

Traduction Framalang : FranBAG, goofy, wisi_eu, gangsoleil, Khrys – Mise en forme :

En 2020 et au-delà, la bataille pour sauver l’identité individuelle et la démocratie exigera une révision radicale des technologies dominantes

par Aral Balkan

Un jeune garçon pilotant un canot sur un lac, durant les grands incendies australiens. Crédit photo: Allison Marion.

 

Alors que nous entrons dans une nouvelle décennie, l’humanité est confrontée à plusieurs urgences existentielles :

  1. L’urgence climatique1
  2. L’urgence démocratique
  3. L’urgence de la personne

Grâce à Greta Thunberg, nous parlons sans aucun doute de la première. La question de savoir si nous allons vraiment faire quelque chose à ce sujet, bien sûr, fait l’objet d’un débat.2

De même, grâce à la montée de l’extrême droite dans le monde entier sous la forme de (entre autres) Trump aux États-Unis, Johnson au Royaume-Uni, Bolsonaro au Brésil, Orban en Hongrie et Erdoğan en Turquie, nous parlons également de la seconde, y compris du rôle de la propagande (ou « infox ») et des médias sociaux dans sa propagation.

Celle sur laquelle nous sommes les plus désemparé·e·s et partagé·e·s, c’est la troisième, même si toutes les autres en découlent et en sont les symptômes. C’est l’urgence sans nom. Enfin, jusqu’à présent.

L’urgence de la personne

On ne peut pas comprendre « l’urgence de la personne » sans comprendre le rôle que la technologie de réseau et numérique grand public joue dans sa perpétuation.

Votre télé ne vous regardait pas, YouTube si.

La technologie traditionnelle – non numérique, pas en réseau – était un moyen de diffusion à sens unique. C’est la seule chose qu’un livre imprimé sur la presse Gutenberg et votre téléviseur analogique avaient en commun.

Autrefois, quand vous lisiez un journal, le journal ne vous lisait pas aussi. Lorsque vous regardiez la télévision, votre téléviseur ne vous regardait pas aussi (à moins que vous n’ayez spécifiquement permis à une société de mesure d’audience, comme Nielsen, d’attacher un audimètre à votre téléviseur).

Aujourd’hui, lorsque vous lisez le journal The Guardian en ligne, The Guardian – et plus de deux douzaines d’autres parties tierces, y compris la Nielsen susmentionnée – vous lit également. Quand vous regardez YouTube, YouTube vous regarde aussi.

Il ne s’agit pas d’une théorie de la conspiration farfelue, mais simplement du modèle d’affaires de la technologie actuelle. J’appelle ce modèle d’affaires « l’élevage d’êtres humains ». C’est une partie du système socio-économique, dont nous faisons partie, que Shoshana Zuboff appelle le capitalisme de surveillance.3

Et pis encore : Alphabet Inc, qui possède Google et YouTube, ne se contente pas de vous observer lorsque vous utilisez un de leurs services, mais vous suit également sur le Web lorsque vous allez de site en site. À lui seul, Google a les yeux sur 70 à 80 % du Web.
Mais ils ne s’arrêtent pas là non plus. Les exploitants d’êtres humains achètent également des données auprès de courtiers en données, partagent ces données avec d’autres exploitants et savent même quand vous utilisez votre carte de crédit dans les magasins ayant pignon sur rue. Et ils combinent toutes ces informations pour créer des profils de vous-même, constamment analysés, mis à jour et améliorés.

Nous pouvons considérer ces profils comme des simulations de nous-mêmes. Ils contiennent des aspects de nous-mêmes. Ils peuvent être (et sont) utilisés comme des approximations de nous-mêmes. Ils contiennent des informations extrêmement sensibles et intimes sur nous. Mais nous ne les possédons pas, ce sont les exploitants qui les possèdent.

Il n’est pas exagéré de dire qu’au sein de ce système, nous ne sommes pas en pleine possession de nous-mêmes. Dans un tel système, où même nos pensées risquent d’être lues par des entreprises, notre identité et le concept même d’autodétermination sont mis en danger.

Nous sommes sur le point de régresser du statut d’être humain à celui de propriété, piratés par une porte dérobée numérique et en réseau, dont nous continuons à nier l’existence à nos risques et périls. Les conditions préalables à une société libre sont soumises à notre compréhension de cette réalité fondamentale.
Si nous nous prolongeons en utilisant la technologie, nous devons étendre le champ d’application légal des droits de l’homme pour inclure ce « Moi » prolongé.

Si nous ne pouvons définir correctement les limites d’une personne, comment pouvons-nous espérer protéger les personnes ou l’identité d’une personne à l’ère des réseaux numériques ?

Aujourd’hui, nous sommes des êtres fragmentés. Les limites de notre être ne s’arrêtent pas à nos frontières biologiques. Certains aspects de notre être vivent sur des morceaux de silicium qui peuvent se trouver à des milliers de kilomètres de nous.

Il est impératif que nous reconnaissions que les limites du moi à l’ère des réseaux numériques ont transcendé les limites biologiques de nos corps physiques et que cette nouvelle limite – le « Moi » prolongé ; la totalité fragmentée du moi – constitue notre nouvelle peau numérique et que son intégrité doit être protégée par les droits de l’homme.

Si nous ne faisons pas cela, nous sommes condamné·e·s à nous agiter à la surface du problème, en apportant ce qui n’est rien d’autre que des changements cosmétiques à un système qui évolue rapidement vers un nouveau type d’esclavage.

C’est l’urgence de la personne.

Un remaniement radical de la technologie grand public

Si nous voulons nous attaquer à l’urgence de la personne, il ne faudra rien de moins qu’un remaniement radical des technologies grand public.

Nous devons d’abord comprendre que si réglementer les exploitants d’humains et les capitalistes de la surveillance est important pour réduire leurs préjudices, cette réglementation constitue une lutte difficile contre la corruption institutionnelle et n’entraînera pas, par elle-même, l’émergence miraculeuse d’une infrastructure technologique radicalement différente. Et cette dernière est la seule chose qui puisse s’attaquer à l’urgence de l’identité humaine.

Imaginez un monde différent.

Faites-moi le plaisir d’imaginer ceci une seconde : disons que votre nom est Jane Smith et que je veux vous parler. Je vais sur jane.smith.net.eu et je demande à vous suivre. Qui suis-je ? Je suis aral.balkan.net.eu. Vous me permettez de vous suivre et nous commençons à discuter… en privé.

Imaginez encore que nous puissions créer des groupes – peut-être pour l’école où vont nos enfants ou pour notre quartier. Dans un tel système, nous possédons et contrôlons tou·te·s notre propre espace sur Internet. Nous pouvons faire toutes les choses que vous pouvez faire sur Facebook aujourd’hui, tout aussi facilement, mais sans Facebook au milieu pour nous surveiller et nous exploiter.

Ce dont nous avons besoin, c’est d’un système en pair à pair qui établisse une passerelle avec le réseau mondial existant.

Ce dont nous avons besoin, c’est le contraire de la « Big Tech » (industrie des technologies). Nous avons besoin de « Small Tech » (technologie à petite échelle) – des outils de tous les jours pour les gens ordinaires, conçus pour augmenter le bien-être humain, et non les profits des entreprises.

Étapes concrètes

À la Small Technology Foundation, Laura et moi avons déjà commencé à construire certains des éléments fondamentaux d’un pont possible entre le capitalisme de surveillance et un avenir radicalement démocratique, entre pairs. Et nous continuerons à travailler sur les autres composantes cette année et au-delà. Mais il y a des mesures pratiques que nous pouvons tou·te·s prendre pour aider à faire avancer les choses dans cette direction.

Voici quelques suggestions pratiques pour différents groupes :

Les gens ordinaires

1. Ne vous culpabilisez pas, vous êtes les victimes. Quand 99,99999 % de tous les investissements technologiques vont aux « exploitants d’humains », ne laissez personne vous dire que vous devriez vous sentir mal d’avoir été obligé·e·s d’utiliser leurs services par manque d’alternatives.

2. Cela dit, il existe des alternatives. Cherchez-les. Utilisez-les. Soutenez les gens qui les fabriquent.

3. Prenez conscience que ce problème existe. Appelez des responsables et défendez ceux qui le font. À tout le moins, n’écartez pas les préoccupations et les efforts de ceux et celles d’entre nous qui tentent de faire quelque chose à ce sujet.

Les développeurs

1. Cessez d’intégrer les dispositifs de surveillance d’entreprises comme Google et Facebook dans vos sites Web et vos applications. Cessez d’exposer les gens qui utilisent vos services au capitalisme de surveillance.

2. Commencez à rechercher d’autres moyens de financer et de construire des technologies qui ne suivent pas le modèle toxique de la Silicon Valley.

3. Laissez tomber la « croissance » comme mesure de votre succès. Construisez des outils que les individus possèdent et contrôlent, et non votre entreprise ou organisation. Créez des applications Web pour utilisateur unique (dont chaque personne sera l’unique propriétaire). Soutenez des plateformes libres (comme dans liberté) et décentralisées (sans nager dans les eaux troubles de la blockchain).

L’Union Européenne

1. Cessez d’investir dans les start-ups et d’agir comme un Département de recherche et développement officieux de la Silicon Valley et investissez plutôt dans les « stayups » (entreprises durables, PME ou micro-entreprises matures).

2. Créez un domaine de premier niveau (DPN) non commercial ouvert à tous, où chacun peut enregistrer un nom de domaine (avec un certificat Let’s Encrypt automatique) pour un coût nul avec un seul « appel API ».

3. Appuyez-vous sur l’étape précédente pour offrir à chaque citoyen·ne de l’Union Européenne, payé par l’argent du contribuable européen, un serveur privé virtuel de base, doté de ressources de base pour héberger un nœud actif 24h/24 dans un système pair-à-pair qui le détacherait des Google et des Facebook du monde entier et créerait de nouvelles possibilités pour les gens de communiquer en privé ainsi que d’exprimer leur volonté politique de manière décentralisée.

Et, généralement, il est alors temps pour chacun·e d’entre nous de choisir un camp.

Le camp que vous choisissez décidera si nous vivons en tant que personnes ou en tant que produits. Le côté que vous choisissez décidera si nous vivons dans une démocratie ou sous le capitalisme.

Démocratie ou capitalisme ? Choisissez.

Si, comme moi, vous avez grandi dans les années 80, vous avez probablement accepté sans réfléchir la maxime néolibérale selon laquelle la démocratie et le capitalisme vont de pair. C’est l’un des plus grands mensonges jamais propagés. La démocratie et le capitalisme sont diamétralement opposés.

Vous ne pouvez pas avoir une démocratie fonctionnelle et des milliardaires et des intérêts corporatifs de billions de dollars et la machinerie de désinformation et d’exploitation des Big Tech de la Silicon Valley. Ce que nous voyons, c’est le choc du capitalisme et de la démocratie, et le capitalisme est en train de gagner.

Avons-nous déjà passé ce tournant ? Je ne sais pas. Peut-être. Mais on ne peut pas penser comme ça.

Personnellement, je vais continuer à travailler pour apporter des changements là où je pense pouvoir être efficace : en créant une infrastructure technologique alternative pour soutenir les libertés individuelles et la démocratie.

L’humanité a déjà mis en place l’infrastructure du techno-fascisme. Nous avons déjà créé (et nous sommes toujours en train de créer) des éléments panoptiques. Tout ce que les fascistes ont à faire, c’est d’emménager et de prendre les commandes. Et ils le feront démocratiquement, avant de détruire la démocratie, tout comme Hitler l’a fait.

Et si vous pensez que «les années 30 et 40 c’était quelque chose», rappelez-vous que les outils les plus avancés pour amplifier les idéologies destructrices de l’époque étaient moins puissants que les ordinateurs que vous avez dans vos poches aujourd’hui. Aujourd’hui, nous avons le « Machine Learning » (Apprentissage machine) et sommes sur le point de débloquer l’informatique quantique.

Nous devons nous assurer que les années 2030 ne reproduisent pas les années 1930. Car nos systèmes centralisés avancés de saisie, de classification et de prévision des données, plus une centaine d’années d’augmentation exponentielle de la puissance de traitement (notez que je n’utilise pas le mot « progrès »), signifient que les années 2030 seront exponentiellement pires.

Qui que vous soyez, où que vous soyez, nous avons un ennemi commun : l’Internationale nationaliste. Les problèmes de notre temps dépassent les frontières nationales. Les solutions le doivent également. Les systèmes que nous construisons doivent être à la fois locaux et mondiaux. Le réseau que nous devons construire est un réseau de solidarité.

Nous avons créé le présent. Nous allons créer le futur. Travaillons ensemble pour faire en sorte que cet avenir soit celui dans lequel nous voulons vivre nous-mêmes.


Discours d’Aral Balkan au Parlement européen, fin 2019, lors de la rencontre sur l’avenir de la réglementation de l’Internet.  Merci à la Quadrature du Net et à sa chaîne PeerTube.

 





Funkwhale : Eliot franchit le pas

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

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

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

 

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

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

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

Passé

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

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

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

 

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

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

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

Présent

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

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

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

 

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

Maintenant, que puis-je faire à long terme ?

Avenir

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

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

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

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

logo de funkwhale, couleur verte
Feu vert pour Funkwhale !

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

 

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

Liens utiles




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

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

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

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

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

 

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

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

Vers la version 1, et au-delà !

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

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

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

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

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

 

Framasoft Need You!

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

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

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

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

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

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

Comment nous aider ?

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

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

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

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

 

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




Ce qui nous pousse au Libre

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

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

Marien, développeur et membre de Framasoft.

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

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

Apprentissage

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

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

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

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

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

Plaisir

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

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

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

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

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

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

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

Partage

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

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

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

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

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

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

Éthique

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

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

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

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

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

Ou encore :

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

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

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

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

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

Convergence des buts ?

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

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

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

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

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


Merci à Maiwann pour sa relecture attentive !




Merci du signalement, ton bug peut attendre…

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

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

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

 

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

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

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

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

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

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

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

Il y 24 h dans une journée

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

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

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

= il reste 6h

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

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

Voyons voir :

6h

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

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

= il reste 2h

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

2h = 120 min

/130 outils (estimation basse)4

= une moyenne de 55 secondes par outil

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

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

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

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

 

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




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

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

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

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

Les auteurs précisent :

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

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

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

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

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

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

 

La lettre de Copenhague, 2017

 

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

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

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

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

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

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

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

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

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

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

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

Contact (en anglais) : hej@copenhagenletter.org

 

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




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

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

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

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

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

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

Par Shubheksha

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

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

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

Oui. Deux ans.

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

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

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

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

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

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

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

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

La réponse que je reçus fut :

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

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

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

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

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

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

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

Moi, fuyant le monde du logiciel open source

Ma découverte de Mozilla

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

Bon sang, j’en suis tellement heureuse maintenant.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conseil n°3 : lancez-vous !

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

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

Merci à tous ceux qui travaillent dans l’open source

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

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

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

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

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

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




Une contributrice du noyau Linux jette l’éponge

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

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

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

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

 

Tourner la page

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Alexander Graham Bell

 

________

Crédits image :

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