Nous ouvrons volontiers nos colonnes aux témoignages de dégooglisation, en particulier quand il s’agit de structures locales tournées vers le public. C’est le cas pour l’interview que nous a donnée Fabrice, qui a entrepris de « dégafamiser » au sein de son association. Il évoque ici le cheminement suivi, depuis les constats jusqu’à l’adoption progressive d’outils libres et éthiques, avec les résistances et les passages délicats à négocier, ainsi que les alternatives qui se sont progressivement imposées. Nous souhaitons que l’exemple de son action puisse donner envie et courage (il en faut, certes) à d’autres de mener à leur tour cette « migration » émancipatrice.

Bonjour, peux-tu te présenter brièvement pour le Framablog ?
Je m’appelle Fabrice, j’ai 60 ans et après avoir passé près de 30 années sur Paris en tant que DSI, je suis venu me reposer au vert, à la grande campagne… Framasoft ? Je connais depuis très longtemps… Linux ? Aussi puisque je l’ai intégré dans une grande entreprise française, y compris sur des postes de travail, il y a fort longtemps…

Ce n’est que plus tard que j’ai pris réellement conscience du pouvoir néfaste des GAFAM et que je défends désormais un numérique Libre, simple, accessible à toutes et à tous et respectueux de nos libertés individuelles. Ayant du temps désormais à accorder aux autres, j’ai intégré une association en tant que bénévole, une asso qui compte un peu moins de 10 salariés et un budget annuel avoisinant les 400 K€.

Quel a été le déclencheur de  l’opération de dégafamisation ?

En fait, quand je suis arrivé au sein de l’association le constat était un peu triste :

• des postes de travail (PC sous Windows 7, 8, 10) poussifs, voire inutilisables, avec 2 ou 3 antivirus qui se marchaient dessus, sans compter les utilitaires en tout genre (Ccleaner, TurboMem, etc.)
• une multitude de comptes Gmail à gérer (plus que le nb d’utilisateurs réels dans l’asso.)
• des partages de Drive incontrôlables
• des disques durs portables et autres clés USB qui faisaient office aussi de « solutions de partage »
• un niveau assez faible de compréhension de toutes ces « technologies »

Il devenait donc urgent de « réparer » et j’ai proposé à l’équipe de remettre tout cela en ordre mais en utilisant des outils libres à chaque fois que cela était possible. À ce stade-là, je pense que mes interlocuteurs ne comprenaient pas exactement de quoi je parlais, ils n’étaient pas très sensibles à la cause du Libre et surtout, ils ne voyaient pas clairement en quoi les GAFAM posaient un problème…

En amont de votre « dégafamisation », avez-vous organisé en interne des moments pour créer du consensus sur le sujet et passer collectivement à l’action (lever aussi les éventuelles résistances au changement) ? Réunions pour présenter le projet, ateliers de réflexion, autres ?

Le responsable de la structure avait compris qu’il allait y avoir du mieux – personne ne s’occupait du numérique dans l’asso auparavant – et il a dit tout simplement « banco » à la suite de quelques démos que j’ai pu faire avec l’équipe :

• démo d’un poste de travail sous Linux (ici c’est Mint)
• démo de LibreOffice…

Pour être très franc, je ne pense pas que ces démos aient emballé qui que ce soit…

Franchement, il était difficile d’expliquer les mises à jour de Linux Mint à un utilisateur de Windows qui ne les faisait de toutes façons jamais, d’expliquer LibreOffice Writer à une personne qui utilise MS Word comme un bloc-notes et qui met des espaces pour centrer le titre de son document…
Néanmoins, après avoir dressé le portrait peu glorieux des GAFAM, j’ai tout de même réussi à faire passer un message : les valeurs de l’association (ici une MJC) sont à l’opposé des valeurs des GAFAM ! Sous-entendu, moins on se servira des GAFAM et plus on sera en adéquation avec nos valeurs !

Comment avez-vous organisé votre dégafamisation ? Plan stratégique machiavélique puis passage à l’opérationnel ? Ou par itérations et petit à petit, au fil de l’eau ?

Pour montrer que j’avais envie de bien faire et que mon bénévolat s’installerait dans la durée, j’ai candidaté pour participer au Conseil d’Administration et j’ai été élu. J’ai présenté le projet aux membres du C.A sans véritable plan, si ce n’est de remettre tout d’équerre avec du logiciel Libre ! Là encore, les membres du C.A n’avaient pas forcément une exacte appréhension le projet mais à partir du moment où je leur proposais mieux, ils étaient partants !

Le plan (étalé sur 12 mois) :

Priorité n^o1 : remettre en route les postes de travail (PC portables) afin qu’ils soient utilisables dans de bonnes conditions. Certains postes de moins de 5 ans avaient été mis au rebut car ils « ramaient »…

• choix de la distribution : Linux Mint Cinnamon ou Linux Mint XFCE pour les machines les moins puissantes
• choix du socle logiciel : sélection des logiciels nécessaires après analyse des besoins / observations

Priorité n^o 2 : stopper l’utilisation de Gmail pour la messagerie et mettre en place des boites mail (avec le nom de domaine de l’asso), boites qui avaient été achetées mais jamais utilisées…

Priorité n^o 3 : augmenter le niveau des compétences de base sur les outils numériques

Prorité n^o 4 : mettre en place un cloud privé afin de stocker, partager, gérer toutes les données de l’asso (350Go) et cesser d’utiliser les clouds des GAFAM…

Est-ce que vous avez rencontré des résistances que vous n’aviez pas anticipées, qui vous ont pris par surprise ?

Bizarrement, les plus réticents à un poste de travail Libre étaient ceux qui maîtrisaient le moins l’utilisation d’un PC…
« Nan mais tu comprends, Windows c’est quand même vachement mieux… Ah bon, pourquoi ? Ben j’sais pô…c’est mieux quoi… »

* Quand on représente la plus grosse association de sa ville, il y a de nombreux échanges avec les collectivités territoriales et, on s’arrache les cheveux à la réception des docx ou pptx tout pourris… Il en est de même avec les services de l’État et l’utilisation de certains formulaires PDF qui ont un comportement étrange…
* Quand un utilisateur resté sous Windows utilise encore des solutions Google alors que nous avons désormais tout en interne pour remplacer les services Google, je ne me bats pas…
* Quand certains matériels (un Studio de podcast par exemple) requièrent l’utilisation de Windows et ne peuvent pas fonctionner sous Linux, c’est désormais à prendre en compte dans nos achats…
* Quand Il faut aussi composer avec les services civiques et autres stagiaires qui débarquent, ne jurent que par les outils d’Adobe et expliquent au directeur que sans ces outils, leur création est diminuée…

* Quand le directeur commence à douter sur le choix des logiciels libres, je lui rappelle gentiment que le véhicule de l’asso est une Dacia et non une Tesla…
* Quand on se rend compte qu’un mail provenant des serveurs Gmail est rarement considéré comme SPAM par les autres alors que nos premiers mails avec OVH et avec notre nom de domaine ont eu du mal à « passer » les premières semaines…et de temps en temps encore maintenant…

Est-ce qu’au contraire, il y a eu des changements que vous redoutiez et qui se sont passés comme sur des roulettes ?

Rassembler toutes les données de l’asso. et de ses utilisateurs au sein de notre cloud privé (Nextcloud) était vraiment la chose qui me faisait le plus peur et qui est « passée crème » ! Peut-être tout simplement parce que certaines personnes avaient un peu « oublié » où étaient rangées leurs affaires auparavant…

… et finalement quels outils ou services avez-vous remplacés par lesquels ?

• Messagerie Google –> Messagerie OVH + Client Thunderbird ou Client mail de Nextcloud (pour les petits utilisateurs)
• Gestion des Contacts Google –> Nextcloud Contacts
• Calendrier Google –> Nextcloud Calendrier
• MS Office –> LibreOffice
• Drive Google, Microsoft, Apple –> Nextcloud pour les fichiers personnels et tous ceux à partager en interne comme en externe
• Doodle –> Nextcloud Poll
• Google Forms –> Nextcloud Forms

NB : Concernant les besoins en création graphique ou vidéo on utilise plusieurs solutions libres selon les besoins (Gimp, Krita, Inkscape, OpenShotVideo,…) et toutes les autres solutions qui étaient utilisées de manière « frauduleuse » ont été mises à la poubelle ! Nous avons néanmoins un compte payant sur canva.com

À combien estimez-vous le coût de ce changement ? Y compris les coûts indirects : perte de temps, formation, perte de données, des trucs qu’on faisait et qu’on ne peut plus faire ?

Il s’agit essentiellement de temps, que j’estime à 150 heures dont 2/3 passées en « formation/accompagnement/documentation » et 1/3 pour la mise au point des outils (postes de travail, configuration du Nextcloud).
Côté coûts directs : notre serveur Nextcloud dédié, hébergé par un CHATONS pour 360 €/an et, c’est tout, puisque les boîtes mail avaient déjà été achetées avec un hébergement web mais non utilisées…
Il n’y a eu aucune perte de données, au contraire on en a retrouvé !
À noter que les anciens mails des utilisateurs (stockés chez Google donc) n’ont pas été récupérés, à la demande des utilisateurs eux-mêmes ! Pour eux c’était l’occasion de repartir sur un truc propre !
À ma connaissance, il n’y a rien que l’on ne puisse plus faire aujourd’hui, mais nous avons conservé deux postes de travail sous Windows pour des problèmes de compatibilité matérielle.
Cerise sur le gâteau : des PC portables ont été ressuscités grâce à une distribution Linux, du coup, nous en avons trop et n’en avons pas acheté cette année !

Est-ce que votre dégafamisation a un impact direct sur votre public ou utilisez-vous des services libres uniquement en interne ? Si le public est en contact avec des solutions libres, comment y réagit-il ? Est-il informé du fait que c’est libre ?

Un impact direct ? Oui et non…

En fait, en plus de notre démarche, on invite les collectivités et autres assos à venir « voir » comment on a fait et à leur prouver que c’est possible, ce n’est pas pour autant qu’on nous a demandé de l’aide.

Pour eux, la marche peut s’avérer trop haute et ils n’ont pas forcément les compétences pour franchir le pas sans aide. Imaginez un peu, notre mairie continue de sonder la population à coups de GoogleForms alors qu’on leur a dit quantité de fois qu’il existe des alternatives plus éthiques et surtout plus légales !

Et encore oui, bien que nous utilisions essentiellement ces outils en interne le public en est informé, les « politiques » et autres collectivités qui nous soutiennent le sont aussi et ils sont toujours curieux et, de temps en temps, admiratifs ! La gestion même de nos adhérents et de nos activités se fait au travers d’une application client / serveur développée par nos soins avec LibreOffice Base. Les données personnelles de nos adhérents sont ainsi entre nos mains uniquement.

Est-ce qu’il reste des outils auxquels vous n’avez pas encore pu trouver une alternative libre et pourquoi ?
Oui… nos équipes continuent à utiliser Facebook et WhatsApp… Facebook pour promouvoir nos activités, actions et contenus auprès du grand public et WhatsApp pour discuter instantanément ensemble (en interne) ou autour d’un « projet »avec des externes. Dans ces deux cas, il y a certes de très nombreuses alternatives, mais elles sont soit incomplètes (ne couvrent pas tous les besoins), soit inconnues du grand public (donc personne n’adhère), soit trop complexes à utiliser (ex. Matrix) mais je garde un œil très attentif sur tout cela, car les usages changent vite…

Quels conseils donneriez-vous à des structures comparables à la vôtre (MJC, Maison de quartier, centre culturel…) qui voudrait se dégafamiser aussi ? Des erreurs à ne pas commettre, des bonnes pratiques éprouvées à l’usage ?

• Commencer par déployer une solution comme Nextcloud est une étape très fondatrice sur le thème « reprendre le contrôle de ses données » surtout dans des structures comme les nôtres où il y a une rotation de personnels assez importante (contrats courts/aidés, services civiques, volontaires européens, stagiaires, apprentis…).
• Pour un utilisateur, le fait de retrouver ses affaires, ou les affaires des autres, dans une armoire bien rangée et bien sécurisée est un vrai bonheur. Une solution comme Nextcloud, avec ses clients de synchronisation, représente une mécanique bien huilée désormais et, accessible à chacun. L’administration de Nextcloud peut très bien être réalisée par une personne avertie (un utilisateur ++), c’est à dire une personne qui sait lire une documentation et qui est rigoureuse dans la gestion de ses utilisateurs et de leurs droits associés. Ne vous lancez pas dans l’auto-hébergement si vous n’avez pas les compétences requises ! De nombreuses structures proposent désormais « du Nextcloud » à des prix très abordables.
• À partir du moment où ce type de solution est installée, basculez-y la gestion des contacts, la gestion des calendriers et faites la promotion, en interne, des autres outils disponibles (gestion de projets, de budget, formulaires…)
• Fort de ce déploiement et, si votre messagerie est encore chez les GAFAM, commencez à chercher une solution ailleurs en sachant qu’il y aura des coûts, des coups et des pleurs… Cela reste un point délicat compte-tenu des problèmes exposés plus haut… Cela prend du temps mais c’est tout à fait possible ! Pour les jeunes, le mail est « ringard », pour les administratifs c’est le principal outil de communication avec le monde extérieur… Là aussi, avant de vous lancer, analysez bien les usages… Si Google vous autorise à envoyer un mail avec 50 destinataires, ce ne sera peut-être pas le cas de votre nouveau fournisseur…
• Le poste de travail (le PC) est, de loin, un sujet sensible : c’est comme prendre la décision de jeter à la poubelle le doudou de votre enfant, doudou qui l’a endormi depuis de longues années… Commencez par recycler des matériels “obsolètes” pour Windows mais tout à fait corrects pour une distribution Linux et faites des heureux ! Montrer aux autres qu’il s’agit de systèmes non intrusifs, simple, rapides et qui disposent d’une logithèque de solutions libres et éthiques incommensurable !

Cela fait deux ans que notre asso. est dans ce mouvement et si je vous dis que l’on utilise FFMPEG pour des traitements lourds sur les médias de notre radio FM associative, traitements que l’on n’arrivait pas à faire auparavant avec un logiciel du commerce ? Si je vous dis qu’avec un simple clic-droit sur une image, un utilisateur appose le logo de notre asso en filigrane (merci nemo-action !). Si je vous dis que certains utilisateurs utilisent des scripts en ligne de commande afin de leur faciliter des traitements fastidieux sur des fichiers images, audios ou vidéos ? Elle est pas belle la vie ?

Néanmoins, cela n’empêche pas des petites remarques de-ci de-là sur l’utilisation de solutions libres plutôt que de « faire comme tout le monde » mais ça, j’en fais mon affaire et tant que je leur trouverai une solution libre et éthique pour répondre à leurs besoins alors on s’en sortira tous grandis !
Ah, j’oubliais : cela fait bien longtemps maintenant qu’il n’est plus nécessaire de mettre les mains dans le cambouis pour déployer un poste de travail sous Linux, le support est quasi proche du zéro !

Merci Fabrice d’avoir piloté cette opération et d’en avoir partagé l’expérience au lectorat du Framablog !

Voici déjà le troisième volet du processus de dégooglisation de la ville d’Échirolles (si vous avez manqué le début) tel que Nicolas Vivant nous en rend compte. Nous le re-publions volontiers, en souhaitant bien sûr que cet exemple suscite d’autres migrations vers des solutions libres et plus respectueuses des citoyens.

Dégooglisation d’Échirolles, partie 3 : les solutions

par Nicolas Vivant

L’organisation est structurée, les enjeux sont posés, place à la mise en œuvre opérationnelle.

L’âge de la maturité

Les informaticiens utilisent des logiciels libres, pour le fonctionnement de leur système d’information, depuis toujours. Pas par militantisme, dans la plupart des cas, mais simplement parce que ce sont les plus stables, les plus sûrs et souvent les meilleurs. L’immense majorité des serveurs web, par exemple, fonctionne avec Apache ou, de plus en plus, NGINX, et tournent sur des systèmes d’exploitation libres (GNU/Linux, souvent).

La nouveauté concerne le poste client, la communication et les applications métier. Dans ces trois domaines, les logiciels libres ont atteint un niveau de maturité inédit jusqu’alors. L’absence de publicité et de marketing ne favorise pas la découverte des solutions disponibles, mais certains logiciels ont fait leur chemin dans les organisations. Comment ? Par le bouche à oreille, les échanges sur les réseaux sociaux, la communication (et le travail) de différentes associations et structures étatiques (Adullact, April, Framasoft, Etalab, etc.) ou la contagion entre collectivités : une collectivité utilise un logiciel, j’en entends parler (ou je l’utilise dans mes échanges avec elle), je me renseigne et je finis par l’adopter.

Souvent, plusieurs solutions libres existent pour un même usage. L’exemple de la messagerie électronique est parlant. Microsoft (avec Outlook/Exchange) et Google (Gmail) sont dominants sur le marché. Pourtant, il existe au moins 6 alternatives « open source » : Zimbra, BlueMind, OpenXchange, SOGo, Kolab et eGroupWare qui ont peu ou prou les mêmes fonctionnalités ? Comment faire un choix ?

Savoir faire un choix

À Échirolles, après que les aspects fonctionnels sont validés, nous nous appuyons sur 4 piliers :

• la feuille de route et le schéma directeur qui en découle (voir Échirolles libérée (I) : structuration)
• l’analyse technique (voir Échirolles libérée (II) : transformation)
• la coopération intercommunale (qui utilise déjà, et comment ça se passe ?)
• le coût (combien ça coûte, pour quel niveau de service ?)

→ Le schéma directeur évoque des solutions gérées et maintenues en interne et met en avant les concepts de souveraineté numérique et d’autonomie vis-à-vis des éditeurs. C’est une première base de jugement : lesquelles de ces solutions correspondent le mieux aux enjeux identifiés par nos élus ?
→ L’analyse technique permet de vérifier les qualités intrinsèques de la solution, son interopérabilité correcte avec les outils existants, notre capacité à la gérer en autonomie, sa cohérence avec notre préoccupation de l’impact environnemental
→ La coopération intercommunale nous permet d’avoir une idée des problèmes rencontrés, de la réactivité des éventuels prestataires et, globalement, du niveau de satisfaction des collègues.
→ Le coût est évalué sur devis (le code de la commande publique nous contraignant, à raison, à la consultation de plusieurs acteurs et à la justification de nos choix) et par la vérification des références existantes même si pour nous, bien souvent, libre veut dire gratuit.

Les échanges entre services, et en interne au sein de la direction de la stratégie numérique, éclairent également nos décisions.

Go go go !

Sur la base de ces critères, Échirolles a fait le choix de SOGo, une solution fonctionnelle, éprouvée (par Gandi, notamment, en France), solide et qui semble le mieux correspondre à ce que sont nos orientations. D’autres communes font d’autres choix, privilégiant d’autres critères (le nombre et la qualité des prestataires susceptibles d’apporter une assistance sur la solution, par exemple).

Le choix d’une solution de Cloud et d’édition collaborative (alternative à Microsoft Teams ou Google Workspace) s’est fait selon les mêmes critères. Pour la partie Cloud/gestion de fichiers, la coopération intercommunale nous a conduit à éliminer Alfresco Share, peu adapté à nos usages. Pour l’édition collaborative, nous avons préféré Collabora à OnlyOffice, sur les conseils de différentes associations et partenaires et parce que le projet nous semblait mieux correspondre à nos valeurs.

Enfin, le passage à un système d’exploitation libre pour les postes clients est entamé à Échirolles. La ville a fait le choix de Zorin OS, pour de nombreuses raisons qui ont été expliquées dans des articles plus complets :

→ La stratégie gagnante d’une migration du poste de travail sous Linux (LeMagIT)
→ Le poste de travail Linux (étude d’ATOS réalisée par Arawa pour le Ministère des Finances)

Pour le reste, nous utilisons trop de logiciels libres pour les lister tous (les systèmes de gestion de bases de données, par exemple). Certains sont en place depuis très longtemps (Firefox, Thunderbird, 7zip…), d’autres ont été installés récemment (Peertube, Nextcloud, Joplin, Psono…), d’autres sont en cours de déploiement (Proxmox, Maarch courrier, Keycloak…). Quelques-uns, méconnus ou parce qu’ils ont fait l’objet d’une mise en œuvre particulière, ont fait l’objet d’articles dédiés sur mon blog : Mastodon, OBS Studio, Porteus Kiosk, BigBlueButton, etc.

Liste non exhaustive de logiciels libres utilisés à Échirolles

Postes clients :

• 7Zip : https://www.7-zip.org (compression/décompression de fichiers)
• FileZilla : https://filezilla-project.org (client FTP)
• Firefox : https://www.mozilla.org/fr/firefox (navigateur web)
• FOG Project : https://fogproject.org (gestion d’image de postes clients)
• Joplin : https://joplinapp.org (notes synchronisées)
• LibreOffice : https://fr.libreoffice.org (suite bureautique)
• Remmina : https://remmina.org (connexion à distance)
• Shotcut : https://shotcut.org (montage vidéo)
• Signal : https://signal.org (chat)
• Thunderbird : https://www.thunderbird.net (client de messagerie)
• VLC : https://www.videolan.org (lecteur vidéo)
• Zorin OS : https://zorin.com/os/ (système d’exploitation sur poste client)

Applications collectivité :

• Collabora : https://www.collaboraoffice.com (édition collaborative)
• Keycloak : https://www.keycloak.org (gestion des identités/SSO)
• Maarch courrier : https://maarch.com/maarch-courrier/ (gestion électronique de courrier)
• NextCloud : https://nextcloud.com (cloud)
• Odoo : https://www.odoo.com (ERP, utilisé pour la gestion du recrutement)
• KeePassXC : https://keepassxc.org (gestion de mots de passe)
• SOGo : https://www.sogo.nu (messagerie e-mail, agenda, carnets d’adresse)
• Sympa (via Framasoft) : https://framalistes.org (liste de discussion par e-mail)
• WordPress : https://fr.wordpress.org (intranet, sites web associatifs)

Applications DSI :

• BackupPC :https://backuppc.github.io/backuppc/ (sauvegarde)
• Apache : https://httpd.apache.org (serveurs web applicatifs)
• Checkmk : https://checkmk.com (monitoring serveurs)
• Debian : https://www.debian.org (système d’exploitation sur serveur)
• Docker : https://www.docker.com (conteneurs pour serveur)
• GLPI : https://glpi-project.org (gestion de parc)
• LibreNMS : https://www.librenms.org (monitoring réseau)
• NGINX : https://www.nginx.com (serveur web applicatifs, proxy)
• pfSense : https://www.pfsense.org (pare-feu)
• Proxmox : https://www.proxmox.com (virtualisation de serveurs)
• Psono : https://psono.com (gestion des mots de passe)
• QGIS : https://www.qgis.org (géomatique)
• Ubuntu : https://www.ubuntu-fr.org (système d’exploitation sur serveur)
• Wiki.js : https://wiki.js.org (documentation des procédures)
• XiVO : https://wisper.io/xivo/ (téléphonie/voix sur IP)
• Zammad : https://zammad.org (gestion de tickets/boîtes e-mail génériques)

Communication :

• Audacity : https://www.audacityteam.org (montage audio)
• Drupal : https://www.drupal.fr (site web de la ville)
• Mastodon : https://joinmastodon.org (réseau social)
• Matomo : https://fr.matomo.org (mesure d’audience de site web)
• OBS Studio : https://obsproject.com (streaming vidéo)
• Peertube : https://joinpeertube.org (hébergement vidéos)
• Porteus Kiosk : https://porteus-kiosk.org (PC en libre service, écrans de présentation)

Dématérialisation :

• • Asalae : https://www.libriciel.fr/logiciels/asalae/ (archivage électronique)

• Idélibre : https://www.libriciel.fr/logiciels/idelibre/ (gestion des instances municipales)
• iParapheur : https://www.libriciel.fr/logiciels/iparapheur/ (signature électronique)
• Pastell : https://www.libriciel.fr/logiciels/pastell/ (passerelle applicative)
• Slow : https://www.libriciel.fr/logiciels/slow/ (télétransmission des actes)
• WebDelib : https://www.libriciel.fr/logiciels/webdelib/ (préparation des instances municipales)

À noter l’excellente initiative de l’Adullact à destination des collectivités et des prestataires, qui permet d’identifier les acteurs pour chaque logiciel référencé : Comptoir du Libre. Échirolles y maintient les informations concernant les choix de logiciels de la commune.

Cet article ne serait pas complet sans dire un mot sur l’équipement des écoles maternelles et élémentaires, dont l’équipement en informatique incombe aux communes. Si les postes clients disposent des mêmes logiciels que ceux que nous déployons au sein des services municipaux, le passage à Linux attendra encore un peu, pour des raisons que j’ai détaillées dans un article dédié.

Structuration, transformation, mise en œuvre opérationnelle, tout cela est bel et bon. Mais comment être sûr de ne laisser personne au bord de la route ? C’est tout l’enjeu de l’inclusion numérique, sujet de l’article suivant.

→ L’épisode 1 (structuration)
→ L’épisode 2 (transformation)

***

• Source image :

https://commons.wikimedia.org/wiki/File:Eug%C3%A8ne_Delacroix_-_Le_28_Juillet._La_Libert%C3%A9_guidant_le_peuple.jpg

• Auteur : Erich Lessing Culture and Fine Arts Archives via artsy.net
• Description : Tableau d’Eugène Delacroix « La Liberté Guidant le Peuple », commémorant la révolution des Trois Glorieuses (27-28-29 juillet 1830) en France.
• Licence : Domaine public

Retrouvez-moi sur Mastodon : https://colter.social/@nicolasvivant

La proposition de CLIC est de s’auto-héberger (de faire fonctionner des services web libres sur son propre matériel) et de disposer de ses contenus et données localement, et/ou sur le grand Internet avec un système technique pré-configuré. Le dispositif s’adresse plutôt à des militant⋅es, des chercheur⋅euses, des formateur⋅ices… amené⋅es à se rendre sur le terrain, où la connexion Internet n’est pas toujours stable, voire est inexistante.

Depuis décembre 2022, un an après une première rencontre, la clique du projet CLIC s’est retrouvée deux fois :

1. à Paris au CICP et en ligne pour une nouvelle session de travail et d’échange avec des chercheur⋅ses de l’IRD.
2. à Montpellier au Mas Cobado dans une ambiance de fablab éphémère

À la fin de la session de novembre 2021, l’objectif pour 2022 était d’avoir testé le dispositif dans plusieurs contextes. Des CLICs ont ainsi été mis en place pour les labs d’innovation pédagogique, et pour les territoires d’expérimentation Colibris, des contenus accessibles hors ligne ont été ajoutés avec kiwix.

Une difficulté s’est cependant vite posée, liée à l’état de développement du dispositif : l’installation nécessitait alors un accompagnement humain qui manquait une fois de retour sur le terrain, si la CLIC ne fonctionnait plus. Pour les CLICs livré⋅es clé en main, la maintenance et parfois l’usage lui-même étaient donc dépendants des humain⋅es de la clique. Enfin, la pénurie de nano-ordinateurs comme les Raspberry Pi a empêché de s’approvisionner en matériel à déployer. Le projet a donc peu avancé, mais l’intérêt est resté présent.

Premiers retours d’usage

Une priorité pour les retrouvailles de décembre 2022 a donc été d’identifier la cause des problèmes surgissant à l’installation d’une part, et de rédiger un tutoriel pour accompagner l’installation pour les personnes souhaitant plonger dans le projet d’autre part.

Des premiers retours d’usages des chercheur⋅ses de l’IRD ont permis de soulever plusieurs questions :

• celle de l’usage d’un logiciel d’enquête non-libre en lien avec un CLIC,
• celle de la récupération de sauvegarde de ce qui a été travaillé localement en vue de le publier en ligne,
• celle de la compatibilité avec différentes bases de données.

Sur la question de l’usage de solutions techniques non-libres, le projet CLIC s’appuyant sur YunoHost, rapidement la réponse a été qu’on ne chercherait pas de compatibilité avec de telles solutions, préservant nos ressources pour la recherche sur des solutions libres.

Concernant la récupération « facile » des sauvegardes, la réponse reste à être identifiée et implémentée, car il n’y a pour le moment pas de solution clé en main le permettant, autre que l’outil de sauvegarde intégré à YunoHost. Si l’utilisateur⋅ice peut se passer d’une aide graphique, le transfert vers une autre CLIC ou vers un YesWiki devrait pouvoir se faire sans trop de difficultés.

Pour la compatibilité avec les bases de données, plusieurs sont supportées par le projet CLIC : MariaDB (ou MySQL), PostGreSQL. Pour des solutions personnalisées (par exemple à partir d’openHDS), des installations supplémentaires sont à envisager, mais pas impossibles.

Les discussions tout au long de 2022 ont mis en évidence un intérêt pour plusieurs cas d’usage :

• pour un usage pédagogique en classe, en formation (apprendre à administrer un serveur, se former à l’utilisation de logiciels…),
• pour réaliser un travail de terrain en Sciences Humaines et Sociales (anthropologie, démographie, linguistique, etc.) sans connexion,
• pour s’affranchir du recours à la 4G en cas de connexion Internet défaillante ou restreinte (réseaux d’université par exemple),
• pour mettre à disposition des contenus (supports pédagogiques, informations utiles dans un contexte précis, partages au sein d’une communauté…).

Si vous vous retrouvez dans ces cas, ou que vous en identifiez d’autres et que vous souhaitez participer aux tests du prototype du CLIC, contactez-nous sur contact AT projetclic.cc. Nous pouvons vous accompagner dans les premières étapes, et vos retours seront très utiles pour avancer ce projet.

Vous pouvez aussi regarder par vous-même, auquel cas vous aurez besoin :

• des images pour l’installation
• du tutoriel pour accompagner cette installation

Des améliorations logicielles et matérielles

Après ces deux rencontres, on compte cinq grosses améliorations :

• Un site a été créé pour le projet pour y retrouver actus, communauté, images à télécharger et tutoriels : https://projetclic.cc.
• Le hotspot wifi affiche une popup permettant de retrouver le portail sans connaitre son adresse url d’avance,
• L’installateur permet de choisir les applications qu’on veut utiliser parmi une sélection,
• Le portail de sélection de service a été travaillé graphiquement et une démo est disponible,
• Des images sont mises à disposition pour les modèle de nano-ordinateurs Odroid en plus des RaspberryPi.

Les améliorations matérielles ne sont pas en reste :

• Design et impressions 3D de boîtiers pour nano-ordinateur Odroid

• Travail sur la Chatravane avec des ateliers pédagogiques sur la consommation énergétique en autonomie avec des panneaux solaires.

Pour la suite, il est prévu :

• De continuer de travailler sur le système et son installation, notamment pour s’approcher au maximum d’une installation « en un clic ».
• D’ajouter une facilitation graphique au tutoriel, pour aider à la compréhension du fonctionnement d’une CLIC.
• De continuer les tests sur le terrain (et adapter la documentation en fonction des observations).
• De prévoir un hackathon axé sur le design et la communication.

Le projet CLIC avance doucement mais sûrement, grâce à du temps de travail bénévole et rémunéré (ritimo, Mouvement Colibris, YunoHost) et au soutien de Framasoft.

Nos prochaines retrouvailles seront aux Journées du Logicel Libre (JDLL) les 1^er et 2 avril 2023, où vous nous retrouverez en déambulation et de manière plus posée, au stand de nos ami·es de YunoHost.

Crédit photos : 12b Fabrice Bellamy et Mathieu Wostyn
Crédit vidéo : Mouvement Colibris
Licence CC BY SA

Fin novembre, des commoners (militant·e·s des communs), artistes, animateurs et animatrices de rues se sont retrouvé·e·s au Vigan (dans les Cévennes gardoises), pour travailler sur le #ProjetCLIC! (Contenus et Logiciels pour des Internets Conviviaux !), une plateforme numérique pour essaimer des pratiques numériques et coopératives, solidaires et émancipatrices grâce à des logiciels, ressources et formations librement partageables.

Que ce soit dans le secteur associatif, en entreprise, ou dans tout autre collectif, les besoins en outillage informatique sont prégnants. Les géants de l’Internet savent proposer des solutions qui paraissent convenir mais cela a un certain prix, que ce soit en termes monétaires ou d’abandon de notre vie privée. Heureusement, certaines initiatives, telles que celles portées par Framasoft et les CHATONS, permettent de répondre à ces besoins sans concession. Cependant, ces solutions nous font dépendre de tiers, qui doivent être de confiance, et elles sont limitées à la présence d’une connexion internet et à la capacité du tiers à maintenir son service en ligne. En outre, ces outils sont livrés « nus » : il nous faut alors les alimenter en contenus afin de partager nos savoirs et connaissances.

Comment permettre que ces contenus et outils soient facilement accessibles, utilisés et réutilisables dans tous les contextes, y compris les plus éloignés de l’Internet ?

C’est à cette fin que les Animacoop, Colibris, Framasoft, ritimo, le Réseau national des ressourceries, Yunohost et autres allié·es ont imaginé « CLIC! », pour essaimer des pratiques numériques coopératives, solidaires et émancipatrices.

La proposition de CLIC! est de s’auto-héberger (d’installer les services sur son matériel, chez soi) et d’avoir ses outils libres et contenus disponibles localement, et/ou sur le grand Internet avec un système technique pré-configuré. On vous explique.

L’interface de sélection des services dans CLIC!

Entre Chatons et PirateBox : CLIC!

CLIC! pourrait être vu comme un mix entre un CHATONS (hébergeur de logiciel et service libre) et une Piratebox (dispositif électronique accessible par wifi, permettant de partager des contenus libres) pour mettre l’auto-hébergement à la portée de toutes et tous.

Coté logiciel, CLIC! est une distribution Linux issue de Yunohost qui propose déjà des services et des contenus libres préinstallés. L’idée est de proposer en plus des contenus thématiques installables en un clic (fichiers multimédias, parcours pédagogiques, …)

Coté matériel, il pourrait s’installer sur différentes machines: le gros serveur dans un datacenter, un nano-ordinateur type Raspberry Pi, ou encore sur des « ordinosaures » (de vieilles tours d’ordinateurs ou d’anciens ordinateurs portables réutilisés).

Un schéma de Frédérique pour y voir plus clair (ou pas)

Une coding party pour faire avancer le projet

La semaine du 22 au 28 novembre 2021, un groupe éclectique de développeur·euses, facilitateur·rices, bricoleur·euses et artistes issu·es de divers horizons se sont retrouvé·es pour imaginer des usages, adapter l’ergonomie, travailler l’interface, réaliser des installations artistiques dans l’espace public et poursuivre les développements de la distribution CLIC!

Le groupe s’est retrouvé à la Fabrègue (la fabrique en occitan), un écolieu du Vigan associé à la ressourcerie locale.

Une vidéo timelapse pour voir l’ambiance et comment on collaborait

Appréhender ce que pourrait être un Internet low-tech

Qu’est-ce qu’un Internet low-tech ? Le simple fait de trouver une définition des concepts et de se mettre d’accord sur le degré d’autonomie souhaité est un vaste sujet !
De nombreuses personnes réfléchissent déjà au sujet. Notre approche est très concrète : comment faire du mieux avec les ressources à disposition près de chez nous (récupérer du vieux matos dans ses placards ou dans les ressourceries) et tester du matériel peu gourmand en énergie (comme un nano-ordinateur) pour s’auto-alimenter en électricité.
Voici les pistes explorées durant cette semaine au Vigan :

Alimentation autonome via panneaux solaires

Quelques tests ont été réalisés pour discuter des problématiques d’alimentation d’un petit ordinateur ARM avec une batterie lithium et un panneau solaire USB.

Une caractéristique importante des batteries est la puissance maximale qu’elles peuvent absorber quand on les charge. C’est ce qui permettra de déterminer s’il est possible de les recharger en une seule journée via un panneau solaire ou s’il faudra compter plusieurs jours de soleil pour une charge complète.

12b prend des mesures d’un Raspberry Pi sur batterie, avec un écran portable branché.

Toutes les informations à ce sujet sur https://wiki.distrilab.fr/?TestsBatteriesEtPanneauxSolairesUSB

Récupération de batteries lithium d’anciens ordinateurs portables

Un beau travail a été mené pour détailler les opérations nécessaires pour récupérer des batteries depuis des vieilles batteries d’ordinateurs portables. Toutes les opérations sont détaillées dans un tutoriel accessible sur le wiki du Distrilab.

Les piles lithium rondes que l’on peut trouver dans les batteries d’ordinateurs portables

Réemploi de vieux ordinateurs (ordinosaures)

La délégation partie faire ses courses à la Ressourcerie du Pont pour faire le plein d’ordinosaures qui deviendront autant de kiosques autonomes mettant à disposition autant de services numériques que des livres électroniques ou des MOOCs

Hack-design

Des plasticien·nes locaux ont fait parler leur imagination pour créer de nouveaux looks pour différents usages :

• Yeahman : un crieur de rue qui enregistrera des paroles publiques et les rediffusera, faisant office de jukebox actionnable par liens mp3 dans des QR-codes
• Mouche à facette: un Raspberry Pi volant, avec des ailes en boule à facettes
• Girafe rose : une statue de girafe en bois cachant un point d’accès wifi et un serveur CLIC!

Autre piste explorée : un lecteur d’annonces connecté au web par flux RSS, à base de raspberry pi zéro et écran e-ink (comme sur les liseuses d’e-book, l’écran noir et blanc continue d’afficher du contenu sans avoir besoin d’énergie)

Améliorer les outils pour permettre l’usage en local et déconnecté du grand internet

Nous avons profité de la présence d’éminents contributeur·ices Yunohost et Chatons, pour contribuer au code de projets libres. Ainsi :

• Ljf a pu corriger des bugs du hotspot wifi dans Yunohost et faire en sorte qu’il propose les services du serveur CLIC même sans connexion internet ✨
• Tobias a ajouté le support de Framemo dans le dépot d’applications de YunoHost. Il a également travaillé sur une app permettant de remonter des informations vers l’outil de statistiques des chatons
• 12b a créé des images Raspberry Pi et Odroid « clé en main » pour avoir un Yunohost avec des services installés, et une sélection de contenus de formations, de vidéos et de textes préinstallés, et accessibles en mode wifi « hotspot » local.
• Aleks a fait une interface de configuration initiale pour CLIC!, accessible depuis le navigateur web, basée sur ce qui existait déjà pour la brique internet.

L’interface d’installation de CLIC!

Penser les usages et les contenus pour être au plus proche des besoins des gens

Le temps nous a manqué pour réaliser tout ce que nous avions imaginé, en partie parce que nous avons pris du temps pour avoir des moments de restitution et d’échange avec les personnes en visite sur le lieu, ce qui fut riche !
Des graines de projets ont donc été semées et pousseront en 2022 :

• une rubrique « Participation citoyenne » est apparue dans CLIC!, pour permettre d’effectuer des votes, des sondages et d’autres échanges locaux ;
• initier les bénévoles de la ressourcerie à l’installation de ces kiosques sur des vieux ordinateurs et mettre la formation à disposition de toutes et tous ;
• faire des tests utilisateur·ices en direct sur un marché avec un nano-ordi nomade et un kiosque à la ressourcerie.

Une affiche de présentation des bornes Recy’clic par Uto de R(d)évolution

Expérimenter de nouvelles manières de travailler ensemble

Se voir en vrai, vivre ensemble, prendre soin des besoins de toutes et tous, s’amuser, passer du bon temps entre et avec des personnes inspirant·es… Cette rencontre a provoqué une envie de continuer à travailler ensemble sur ce projet. Voici quelques ingrédients, que nous pouvons partager, pour des rencontres réussies :

• Liberté de rythme et de présence : certains étaient là pour quelques jours, d’autres pour une semaine. Certains actifs tôt le matin, d’autres (et iels étaient nombreux⋅ses) tard dans la nuit.
• Un lieu inspirant et des hôtes accueillant·e·s, merci R(d)évolution du Vigan!
• Un cadre de travail mêlant grand repas auto-organisés, discussions enflammées, temps de travail collectif et présentation croisées des avancées
• Des animateur·ice·s soucieux·ses de l’inclusion des participant·es, de nombreux points de synchronisation
• Faire du commun, trouver du sens dans nos collaborations

Quelques liens pour creuser

• Une démo du prototype CLIC! est disponible sur https://colibox.colibris-outilslibres.org
• Visio de restitution vidéo du dernier jour : https://tube.distrilab.fr/w/97xvCSXvYCh4xxwVM1hJoa?start=8m7s
• Tous les contenus (photos, vidéos, dessins, tutos et liens ressources) sur le wiki distrilab https://wiki.distrilab.fr/?PagePrincipale
• Vous avez envie de participer au projet ? Vous pouvez nous contacter via notre formulaire de contact, et nous vous tiendrons informé·es de nos prochains petits pas, et rencontres!

Le mot de la fin

Comme d’habitude sur le framablog, un petit mot des participant·es pour conclure :

• ljf : Il reste de nombreux défis à relever pour proposer de l’auto-hébergement facile, itinérant et déconnectable, cette résidence était un pas de plus, longue vie au projet CLIC! et merci aux habitant⋅es de la Fabrègue et à leur énergie inspirante.
• 12b : De belles rencontres et un projet inspirant. On continue en 2022!
• Simon : Une chouette rencontre avec une belle diversité et plein d’idées, vivement la suite !
• Tobias : Une rencontre hors du temps qui crée autant de code que d’idées et de liens entre les personnes.
• Frédéric : Une belle parenthèse pour moi qui cours toujours après le temps et de super rencontres! Ce fut un vrai moment de bonheur de pouvoir participer au développement de cette solution. Merci à tous·tes
• Christian : un chouette moment d’échange, pour découvrir, expérimenter, tester et discuter. Un grand merci aux organisateurs.
• Lilian : Il y a encore du travail pour que cela soit accessible à tous·tes, mais un énorme potentiel pour permettre à chacun·e d’avoir facilement accès à des outils éthiques.
• Ulysse : Une très belle aventure, qui va essaimer, et pas forcément là où on l’imagine, et c’est ça qui est beau !
• Florian: merci Framasoft de nous avoir soutenus dans cette démarche et au plaisir de vous voir à notre prochain sprint IRL avec ce super groupe <3
• Mathieu : un dispositif dont ritimo rêvait depuis de nombreuses années, qui est en train d’aboutir avec les précieuses contributions de chouettes personnes, et un soutien extra de Framasoft : la recette pour créer du lien, de l’interconnaissance, de la confiance – et construire ensemble du commun !

Crédit photos et vidéos : 12b Fabrice Bellamy – licence CC BY SA

Allez, pour changer un peu des articles qui dénoncent les GAFAM, Gee va plutôt faire un peu de célébration aujourd’hui. Car oui, le noyau Linux fête ses 30 ans !

(Bon okay, il va quand même un peu causer GAFAM sur la fin mais c’est par principe…)

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

Et si le pair-à-pair devenait le modèle et le moteur d’une nouvelle organisation sociale ? – Deuxième volet de la réflexion de Michel Bauwens (si vous avez raté le début, c’est par ici).

Source : Blueprint for P2P Society par Michel Bauwens

Traduction Framalang : Fabrice, goofy, jums, CLC, avec l’aimable contribution de Maïa Dereva.

2. Les relations entre la communauté et la coalition d’entrepreneurs

Quelles sont les relations entre cette coalition d’entrepreneurs et les communs dont ces entrepreneurs retirent leur valeur ? La coalition subvient aux besoins vitaux des « commoners » et soutient parfois financièrement l’institution à but lucratif. IBM, par exemple, verse un salaire aux développeurs/commoners qui contribuent à l’environnement Linux ainsi que des aides à l’association à but non lucratif (la Fondation Linux). Ainsi, les coalitions entrepreneuriales co-produisent et financent les biens communs sur lesquels leur succès est bâti.

Il est vrai qu’en agissant de la sorte, ils font par ailleurs de Linux un « commun d’entreprises », comme l’a expliqué Doc Searls :

Le rédacteur en chef du Linux Journal explique que « Linux est devenue une entreprise économique commune (une joint venture) composée d’un certain nombre de sociétés, tout comme Visa est une entreprise commune à un certain nombre de sociétés financières. Comme le montre le rapport de la Fondation Linux, ces sociétés participent au projet pour des raisons commerciales diverses et variées ».

Dans un rapport de la Fondation Linux sur le noyau de Linux, il est dit clairement :

Plus de 70 % des développements du noyau sont visiblement réalisés par des développeurs qui sont rémunérés pour ce travail. Plus de 14 % vient de contributions de développeurs qui sont connus pour ne pas être rémunérés et être indépendants, et 13 % sont produits par des gens qui peuvent ou non être rémunérés, donc la contribution faite par des travailleurs rémunérés peut atteindre jusqu’à 85 %. Par conséquent, le noyau Linux est largement produit par des professionnels, et non par des bénévoles.

Mais ce n’est pas là toute l’histoire. Thimothy Lee explique que la transformation de Linux en entreprise n’a pas changé son modèle d’organisation sous-jacente:

… l’important est la manière dont les projets open source sont organisés en interne. Dans un projet logiciel traditionnel, il y a un responsable projet qui décide des fonctionnalités dont bénéficiera le produit, et affecte du personnel pour travailler sur ces différentes fonctionnalités. En revanche, personne ne dirige le développement général du noyau Linux. Oui, Linus Torvalds et ses lieutenants décident quels correctifs iront finalement dans le noyau, mais les employés de Red Hat, IBM et Novell qui travaillent sur le noyau Linux ne reçoivent pas d’ordre de leur part. Ils travaillent sur ce qu’ils (et leurs clients respectifs) pensent être le plus important, et la seule autorité que possède Torvalds est celle de décider si le correctif qu’ils soumettent est suffisamment bon pour être intégré au noyau.

Clay Shirky, auteur de « Here Comes Everybody: The Power of Organizing Without Organisations [NdT : Voici venir tout le monde: le pouvoir de s’organiser sans les organisations] souligne que les entreprises qui travaillent avec Linux, comme IBM, « ont abandonné le droit de gérer les projets pour lesquels ils payent, et que leurs concurrents ont accès immédiatement à tout ce qu’ils font. Ce n’est pas un produit IBM. »

C’est donc là où je veux en venir : même avec des sociétés d’actionnaires alliées à la production entre pairs, la création de valeur de la communauté reste toujours au cœur du processus, et la coalition entrepreneuriale, jusqu’à un certain point, suit déjà cette nouvelle logique, dans laquelle la communauté prime, et où le business est secondaire. Dans ce modèle, la logique d’entreprise doit s’accommoder de la logique sociale. En d’autres termes, c’est avant tout une « économie éthique ».

La production entre pairs repose aussi sur une infrastructure de coopération parfois coûteuse. Wikipédia n’existerait pas sans le financement de ses serveurs, pas non plus de logiciel libre ou de matériel ouvert sans mécanisme de support similaire. C’est pour cela que les communautés open source ont créé une nouvelle institution sociale : les associations à but lucratif.

Encore une fois, c’est une innovation sociale importante car, contrairement aux institutions à but non-lucratif ou non-gouvernementales, elles ne fonctionnent pas du point de vue de la rareté. Les ONG classiques fonctionnent encore comme d’autres institutions industrielles à l’instar de l’entreprise ou de l’état-marché, car elles estiment que les ressources doivent être mobilisées et gérées.

À l’inverse, celles qui ont un but lucratif ont uniquement un rôle actif qui permet et favorise la coopération au sein de la communauté, qui fournit les infrastructures, sans pour en diriger les processus de production. Ces associations existent dans le seul but de bénéficier à la communauté dont elles sont l’expression, et c’est la bonne nouvelle, elles sont souvent gérées de manière démocratique. Et elles doivent l’être, car une institution non démocratique découragerait les contributions de sa communauté de participants.

Maintenant, le hic est de savoir comment appeler une institution responsable du bien commun de tous les participants, en l’occurrence, pas les habitants d’un territoire, mais les personnes impliqués dans un projet similaire ? Je rétorquerais que ce type d’institution à but lucratif possède une fonction très similaire aux fonctions normalement dévolues à l’État.

Bien que la forme étatique soit toujours aussi une institution de classe qui défend un arrangement particulier de privilèges sociaux, elle ne peut jamais être un simple instrument de règle de privilégié à elle seule, mais doit aussi gérer le commun. Si l’on considère cette dernière option, la plupart des gens la verrait comme acceptable, voire bonne. En revanche, si l’on considère que l’État échoue dans cette gestion, alors il perd sa légitimité et il est vu de plus en plus comme une source d’oppression par une minorité.

En général, un État reflète l’équilibre des forces à l’œuvre dans une société donnée. L’État providence était une forme acceptable puisqu’il reposait sur un compromis et sur la force d’un puissant mouvement de travailleurs ouvriers, alors que « la peur de Dieu » était instillée dans les milieux privilégiés par la possibilité d’un modèle alternatif d’État qui aurait pu faire disparaître la loyauté de leurs citoyens.

Cette alternative s’est effondrée en 1989, et avec elle les mouvements sociaux occidentaux. Elle a d’autant plus été affaiblie par les choix sociaux, politiques et économiques de désindustrialiser le Nord depuis les années 1980. Depuis, l’État providence a peu à peu laissé sa place à l’État providence contemporain des multinationales (parfois appelé « l’État marché »), qui aide uniquement les privilégiés, détruit les mécanismes de solidarité sociaux, et appauvrit la majorité de la population, et a fortiori affaiblit fatalement la classe moyenne.

Malheureusement, un tel système ne peut avoir aucune une légitimité à long terme, et rompt tout contrat social qui peut garantir la paix sociale. Il est compliqué d’établir une loyauté sur la perspective d’une souffrance toujours plus grande !

Cela signifie que nous assistons non seulement à la mort réelle de l’État providence social, mais aussi à la mort et à l’impossibilité logique de l’État-marché. Nous pourrions ajouter que même l’État providence est devenu problématique. La raison principale en est que sa base sociale, la classe ouvrière occidentale et ses mouvements sociaux, sont devenues des minorités démographiques en Occident, et que ses mécanismes, même lorsqu’ils fonctionnaient, ne contribueraient pas beaucoup à aider la majorité sociale actuelle, c’est-à-dire les travailleurs de la connaissance et des services, souvent indépendants et précaires.

De plus, le fonctionnement paternaliste et bureaucratique de beaucoup d’États providence devient inacceptable face à la demande émergente d’autonomie sociale et personnelle qui est l’un des principaux désirs sociaux de la nouvelle classe des travailleurs de la connaissance. La plupart des autres fonctions sociales de l’État providence ont été affaiblies par les réformes néolibérales du « New Labour » qui tendent à introduire la logique du secteur privé dans le monde du secteur public.

L’open source est de plus en plus populaire et répandu parmi les développeurs. Grâce à des plate-formes comme GitHub, qui ont standardisé la manière de contribuer à un projet, l’open source est devenu plus accessible, au point de devenir une norme. Mais cette nouvelle configuration n’est pas sans poser certains problèmes.

Dans ce nouveau chapitre de son ouvrage Des Routes et des ponts (traduit chapitre après chapitre par l’équipe Framalang), Nadia Eghbal s’intéresse aux enjeux de la standardisation et de la démocratisation de l’open source – notamment à l’inflation parfois anarchique du nombre de projets et de contributeurs : pour elle, l’enjeu est d’éviter que l’écosystème numérique ne se transforme en un fragile château de cartes.

Pourquoi les problèmes de support des infrastructures numériques sont de plus en plus pressants

Traduction Framalang : goudron, Penguin, serici, goofy, Rozmador, xi, Lumibd, teromene, xi, Opsylac, et 3 anonymes.

L’open source, grâce à ses points forts cités plus tôt dans ce rapport, est rapidement en train de devenir un standard pour les projets d’infrastructure numérique et dans le développement logiciel en général. Black Duck, une entreprise qui aide ses clients à gérer des programmes open source, dirige une enquête annuelle qui interroge les entreprises sur leur utilisation de l’open source. (Cette enquête est l’un des rares projets de banque de données qui existe sur le sujet.) Dans leur étude de 2015, 78% des 1300 entreprises interrogées déclarent que les logiciels qu’elles ont créés pour leurs clients sont construits grâce à l’open source, soit presque le double du chiffre de 2010.

L’open source a vu sa popularité s’accroître de manière impressionnante ces cinq dernières années, pas seulement grâce à ses avantages évidents pour les développeurs et les consommateurs, mais également grâce à de nouveaux outils qui rendent la collaboration plus facile. Pour comprendre pourquoi les infrastructures numériques rencontrent des problèmes de support grandissants, nous devons comprendre la manière dont le développement de logiciels open source prolifère.

Github, un espace standardisé pour collaborer sur du code

On n’insistera jamais trop sur le rôle clé de GitHub dans la diffusion de l’open source auprès d’une audience grand public. L’open source a beau exister depuis près de 30 ans, jusqu’en 2008, contribuer à des projets open source n’était pas si facile. Le développeur motivé devait d’abord découvrir qui était le mainteneur du projet, trouver une manière de le contacter, puis proposer ses changements en utilisant le format choisi par le mainteneur (par exemple une liste courriel ou un forum). GitHub a standardisé ces méthodes de communication : les mainteneurs sont listés de façon transparente sur la page du projet, et les discussions sur les changements proposés ont lieu sur la plate-forme GitHub.

GitHub a aussi créé un vocabulaire qui est désormais standard parmi les contributeurs à l’open source, tels que la « pull request » (où un développeur soumet à l’examen de ses pairs une modification à un projet), et changé le sens du terme « fork » (historiquement, créer une copie d’un projet et le modifier pour le transformer en un nouveau projet) [littéralement « fork » signifie « bifurcation », Ndt.]. Avant GitHub, forker un projet revenait à dire qu’il y avait un différend irréconciliable au sujet de la direction qu’un projet devrait prendre. Forker était considéré comme une action grave : si un groupe de développeurs décidait de forker un projet, cela signifiait qu’il se scindait en deux factions idéologiques. Forker était aussi utilisé pour développer un nouveau projet qui pouvait avoir une utilisation radicalement différente du projet initial.

Ce type de « fork de projet » existe toujours, mais GitHub a décidé d’utiliser le terme « fork » pour encourager à davantage d’activité sur sa plate-forme. Un fork GitHub, contrairement à un fork de projet, est une copie temporaire d’un projet sur laquelle on effectue des modifications, et qui est généralement re-fusionnée au projet. Le fork en tant que pratique quotidienne sur GitHub a ajouté une connotation positive, légère au terme : c’est l’idée de prendre l’idée de quelqu’un et de l’améliorer.

GitHub a aussi aidé à standardiser l’utilisation d’un système de contrôle de version appelé Git. Les systèmes de contrôle de versions sont un outil qui permet de garder une trace de chaque contribution apportée sur un morceau de code précis. Par exemple, si le Développeur 1 et le Développeur 2 corrigent différentes parties du même code en même temps, enregistrer chaque changement dans un système de contrôle de version permet de faire en sorte que leurs changements n’entrent pas en conflit. Il existe plusieurs systèmes de contrôle de versions, par exemple Apache Subversion et Concurrent Versions System (CVS). Avant GitHub, Git était un système de contrôle de version assez méconnu. En 2010, Subversion était utilisé dans 60% des projets logiciels, contre 11%pour Git.

C’est Linus Torvalds, le créateur de Linux, qui a conçu Git en 2005. Son intention était de mettre à disposition un outil à la fois plus efficace et plus rapide, qui permette de gérer de multiples contributions apportées par de nombreux participants. Git était vraiment différent des systèmes de contrôle de version précédents, et donc pas forcément facile à adopter, mais son workflow décentralisé a résolu un vrai problème pour les développeurs.

GitHub a fourni une interface utilisateur intuitive pour les projets open source qui utilisent Git, ce qui rend l’apprentissage plus facile pour les développeurs. Plus les développeurs utilisent GitHub, plus cela les incite à continuer d’utiliser Git. Aujourd’hui, en 2016, Git est utilisé par 38% des projets de logiciels, tandis que la part de Subversion est tombée à 47%. Bien que Subversion soit encore le système de contrôle de version le plus populaire, son usage décline. L’adoption généralisée de Git rend plus facile pour un développeur la démarche de se joindre à un projet sur GitHub, car la méthode pour faire des modifications et pour les communiquer est la même sur tous les projets. Apprendre à contribuer sur un seul des projets vous permet d’acquérir les compétences pour contribuer à des centaines d’autres. Ce n’était pas le cas avant GitHub, où des systèmes de contrôle de versions différents étaient utilisés pour chaque projet.

Enfin, GitHub a créé un espace sociabilité, qui permet de discuter et de tisser des liens au-delà de la stricte collaboration sur du code. La plate-forme est devenue de facto une sorte de communauté pour les développeurs, qui l’utilisent pour communiquer ensemble et exposer leur travail. Ils peuvent y démontrer leur influence et présenter un portfolio de leur travail comme jamais auparavant.

Les usages de GitHub sont un reflet de son ascension vertigineuse. En 2011 il n’y avait que 2 millions de dépôts (« repository »). Aujourd’hui, GitHub a 14 millions d’utilisateurs et plus de 35 millions de dépôts (ce qui inclut aussi les dépôts forkés, le compte des dépôts uniques est plutôt aux environs de 17 millions.) Brian Doll, de chez GitHub, a noté qu’il a fallu 4 ans pour atteindre le million de dépôts, mais que passer de neuf millions à dix millions n’a pris que 48 jours.

En comparaison, SourceForge, la plate-forme qui était la plus populaire pour héberger du code open source avant l’apparition de GitHub, avait 150 000 projets en 2008. Environ 18 000 projets étaient actifs.

Stack Overflow, un espace standard pour s’entraider sur du code

L’une des autres plate-formes importantes de l’open source est Stack Overflow, un site de question/réponse populaire parmi les développeurs, créé en 2008 par Jeff Atwood (développeur déjà mentionné précédemment) et par le blogueur Joel Spolsky. En Avril 2014, Stack Overflow avait plus de 4 millions d’utilisateurs enregistrés et plus de 11 millions de questions résolues (à noter qu’il n’est pas nécessaire de s’enregistrer pour voir les questions ou leurs réponses).

Stack Overflow est devenu de facto une plate-forme d’entraide pour les développeurs, qui peuvent poser des questions de programmation, trouver des réponses à des problèmes de code spécifiques, ou juste échanger des conseils sur la meilleure façon de créer un aspect précis d’un logiciel. On pourrait définir la plate-forme comme un « support client » participatif pour les développeurs à travers le monde. Même si Stack Overflow n’est pas un endroit où l’on écrit directement du code, c’est un outil de collaboration essentiel pour les développeurs individuels, qui facilite grandement la résolution de problèmes et permet de coder plus efficacement. Cela signifie qu’un développeur individuel est capable de produire plus, en moins de temps, ce qui améliore le rendement global. Stack Overflow a également permis à certains utilisateurs d’apprendre de nouveaux concepts de développement (ou même de s’initier au code tout court), et a rendu le codage plus facile et plus accessible à tous.

Tendances macro dans un paysage en mutation constante

La popularité hors-normes de l’open source a amené à des changements significatifs dans la manière dont les développeurs d’aujourd’hui parlent, pensent et collaborent sur des logiciels.

Premièrement, les attentes et exigences en termes de licences ont changé, reflétant un monde qui considère désormais l’open source comme une norme, et pas l’exception : un triomphe sur l’univers propriétaire des années 1980. Les politiques de GitHub et de Stack Overflow reflètent toutes deux cette réalité.

Dès le départ, Stack Overflow a choisi d’utiliser une licence Creative Commons appelée CC-BY-SA pour tous les contenus postés sur son site. La licence était cependant limitante, car elle requérait des utilisateurs qu’ils mentionnent l’auteur de chaque morceau de code qu’ils utilisaient, et qu’ils placent leurs propres contributions sous la même licence.

Beaucoup d’utilisateurs choisissaient d’ignorer la licence ou n’étaient même pas au courant de ses restrictions, mais pour les développeurs travaillant avec des contraintes plus strictes (par exemple dans le cadre d’une entreprise), elle rendait Stack Overflow compliqué à utiliser. S’ils postaient une question demandant de l’aide sur leur code, et qu’une personne extérieure réglait le problème, alors légalement, ils devaient attribuer le code à cette personne.

En conséquence, les dirigeants de Stack Overflow ont annoncé leur volonté de déplacer toutes les nouvelles contributions de code sous la Licence MIT, qui est une licence open source comportant moins de restrictions. En Avril 2016, ils débattent encore activement et sollicitent des retours de leur communauté pour déterminer le meilleur moyen de mettre en œuvre un système plus permissif. Cette démarche est un encouragement à la fois pour la popularité de Stack Overflow et pour la prolifération de l’open source en général. Qu’un développeur travaillant dans une grosse entreprise de logiciel puisse légalement inclure le code d’une personne complètement extérieure dans un produit pour lequel il est rémunéré est en effet un accomplissement pour l’open source.

A l’inverse, GitHub fit initialement le choix de ne pas attribuer de licence par défaut aux projets postés sur sa plateforme, peut-être par crainte que cela ne freine son adoption par les utilisateurs et sa croissance. Ainsi, les projets postés sur GitHub accordent le droit de consulter et de forker le projet, mais sont à part ça sous copyright, sauf si le développeur spécifie qu’il s’agit d’une licence open source.

En 2013, GitHub décida enfin de prendre davantage position sur la question des licences, avec notamment la création et la promotion d’un micro-site, choosealicense.com (« choisissez-une-licence »), pour aider les utilisateurs à choisir une licence pour leur projet. Ils encouragent aussi désormais leurs utilisateurs à choisir une licence parmi une liste d’options au moment de créer un nouveau « repository » (dépôt).

Ce qui est intéressant, cependant, c’est que la plupart des développeurs ne se préoccupaient pas de la question des licences : soit ignoraient que leurs projets « open source » n’étaient pas légalement protégés, soit ils s’en fichaient. Une étude informelle réalisée en 2013 par le Software Freedom Law Center (Centre du Droit de la Liberté des Logiciels) sur un échantillon de 1,6 million de dépôts GitHub révéla que seuls 15% d’entre eux avaient spécifié une licence. Aussi, les entretiens avec des développeurs réalisés pour ce rapport suggèrent que beaucoup se fichent de spécifier une licence, ou se disent que si quelqu’un demande, ils pourront toujours en ajouter une plus tard.

Ce manque d’intérêt pour les licences a amené James Governor, cofondateur de la firme d’analyse de développeurs Red Monk, à constater en 2012 que « les jeunes dévs aujourd’hui font du POSS – Post open source software. Envoie chier les licences et la gestion, contribue juste à GitHub » [en anglais « commit to GitHub » signifie littéralement « s’engager dans GitHub » mais fait également référence à la commande « commit » qui permet de valider les modifications apportées à un projet, NdT.]. En d’autres termes, faire de l’information ouverte par défaut est devenu une telle évidence culturelle aujourd’hui que les développeurs ne s’imaginent plus faire les choses autrement – un contexte bien différent de celui des rebelles politisés du logiciel libre des années 1980. Ce retournement des valeurs, quoi qu’inspirant au niveau global, peut cependant amener à des complications légales pour les individus quand leurs projets gagnent en popularité ou sont utilisés à des fins commerciales.

Mais, en rendant le travail collaboratif sur le code aussi facile et standardisé, l’open source se retrouve aux prises avec une série d’externalités perverses.

L’open source a rendu le codage plus facile et plus accessible au monde. Cette accessibilité accrue, à son tour, a engendré une nouvelle catégorie de développeurs, moins expérimentés, mais qui savent comment utiliser les composants préfabriqués par d’autres pour construire ce dont ils ont besoin.

En 2012, Jeff Atwood, cofondateur de Stack Overflow, rédigea un article de blog intitulé ironiquement « Pitié n’apprenez pas à coder », où il se plaint de la mode des stages et des écoles de code. Tout en se félicitant du désir des personnes non-techniciennes de comprendre le code d’un point de vue conceptuel, Atwood met en garde contre l’idée qu’« introduire parmi la main-d’œuvre ces codeurs naïfs, novices, voire même-pas-vraiment-sûrs-d’aimer-ce-truc-de-programmeur, ait vraiment des effets positifs pour le monde ».

Dans ces circonstances, le modèle de développement de l’open source change de visage. Avant l’ascension de GitHub, il y avait moins de projets open source. Les développeurs étaient donc un groupe plus petit, mais en moyenne plus expérimenté : ceux qui utilisaient du code partagé par d’autres étaient susceptibles d’être également ceux qui contribuent en retour.

Aujourd’hui, l’intense développement de l’éducation au code implique que de nombreux développeurs inexpérimentés inondent le marché. Cette dernière génération de développeurs novices emprunte du code libre pour écrire ce dont elle a besoin, mais elle est rarement capable, en retour, d’apporter des contributions substantielles aux projets. Beaucoup sont également habitués à se considérer comme des « utilisateurs » de projets open source, davantage que comme les membres d’une communauté. Les outils open source étant désormais plus standardisés et faciles à utiliser, il est bien plus simple aujourd’hui pour un néophyte de débarquer sur un forum GitHub et d’y faire un commentaire désobligeant ou une requête exigeante – ce qui épuise et exaspère les mainteneurs.

Cette évolution démographique a aussi conduit à un réseau de logiciels bien plus fragmenté, avec de nombreux développeurs qui publient de nouveaux projets et qui créent un réseau embrouillé d’interdépendances. Se qualifiant lui-même de « développeur-pie en rémission » [« pie » est un surnom pour les développeurs-opportunistes, d’après le nom de l’oiseau, la pie réputée voleuse, NdT], Drew Hamlett a écrit en janvier 2016 un post de blog devenu très populaire intitulé « Le triste état du développement web ». L’article traite de l’évolution du développement web, se référant spécifiquement à l’écosystème Node.js :

« Les gens qui sont restés dans la communauté Node ont sans aucun doute créé l’écosystème le plus techniquement compliqué [sic] qui ait jamais existé. Personne n’arrive à y créer une bibliothèque qui fasse quoi que ce soit. Chaque projet qui émerge est encore plus ambitieux que le précédent… mais personne ne construit rien qui fonctionne concrètement. Je ne comprends vraiment pas. La seule explication que j’ai trouvée, c’est que les gens sont juste continuellement en train d’écrire et de réécrire en boucle des applis Node.js. »

Aujourd’hui, il y a tellement de projets qui s’élaborent et se publient qu’il est tout simplement impossible pour chacun d’eux de développer une communauté suffisamment importante et viable, avec des contributeurs réguliers qui discuteraient avec passion des modifications à apporter lors de débats approfondis sur des listes courriels. Au lieu de cela, beaucoup de projets sont maintenus par une ou deux personnes seulement, alors même que la demande des utilisateurs pour ces projets peut excéder le travail nécessaire à leur simple maintenance.

GitHub a rendu simples la création et la contribution à de nouveaux projets. Cela a été une bénédiction pour l’écosystème open source, car les projets se développent plus rapidement. Mais cela peut aussi parfois tourner à la malédiction pour les mainteneurs de projets, car davantage de personnes peuvent facilement signaler des problèmes ou réclamer de nouvelles fonctionnalités, sans pour autant contribuer elles-mêmes en retour. Ces interactions superficielles ne font qu’alourdir la charge de travail des mainteneurs, dont on attend qu’ils répondent à une quantité croissante de requêtes.

Il ne serait pas déraisonnable d’affirmer qu’un monde « post-open source » implique une réflexion non seulement autour des licences, ainsi que James Governor l’exprimait dans son commentaire originel, mais aussi autour du processus de développement lui-même.

Noah Kantrowitz, développeur Python de longue date et membre de la Python Software Foundation, a résumé ce changement dans un post de blog souvent cité :

« Dans les débuts du mouvement open source, il y avait assez peu de projets, et en général, la plupart des gens qui utilisaient un projet y contribuaient en retour d’une façon ou d’une autre. Ces deux choses ont changé à un point difficilement mesurable.
[…] Alors même que nous allons de plus en plus vers des outils de niche, il devient difficile de justifier l’investissement en temps requis pour devenir contributeur. « Combler son propre besoin » est toujours une excellente motivation, mais il est difficile de construire un écosystème là-dessus.
L’autre problème est le déséquilibre de plus en plus important entre producteurs et consommateurs. Avant, cela s’équilibrait à peu près. Tout le monde investissait du temps et des efforts dans les Communs et tout le monde en récoltait les bénéfices. Ces temps-ci, très peu de personnes font cet effort et la grande majorité ne fait que bénéficier du travail de ceux qui s’impliquent.
Ce déséquilibre s’est tellement enraciné qu’il est presque impensable pour une entreprise de rendre (en temps ou en argent) ne serait-ce qu’une petite fraction de la valeur qu’elle dérive des Communs. »

Cela ne veut pas dire qu’il n’existe plus de grands projets open source avec des communautés de contributeurs fortes (Node.js, dont on parlera plus tard dans ce rapport, est un exemple de projet qui est parvenu à ce statut.) Cela signifie qu’à côté de ces réussites, il y a une nouvelle catégorie de projets qui est défavorisée par les normes et les attentes actuelles de l’open source, et que le comportement qui dérive de ces nouvelles normes affecte même des projets plus gros et plus anciens.

Hynek Schlawack, Fellow de la Python Software Foundation et contributeur sur des projets d’infrastructure Python, exprime ses craintes au sujet d’un futur où il y aurait une demande plus forte, mais seulement une poignée de contributeurs solides :

« Ce qui me frustre le plus, c’est que nous n’avons jamais eu autant de développeurs Python et aussi peu de contributions de haute qualité. […] Dès que des développeurs clefs comme Armin Ronacher ralentissent leur travail, la communauté toute entière le ressent aussitôt. Le jour où Paul Kehrer arrête de travailler sur PyCA, on est très mal. Si Hawkowl arrête son travail de portage, Twisted ne sera jamais sur Python 3 et Git.
La communauté est en train de se faire saigner par des personnes qui créent plus de travail qu’elles n’en fournissent. […] En ce moment, tout le monde bénéficie de ce qui a été construit mais la situation se détériore à cause du manque de financements et de contributions. Ça m’inquiète, parce Python est peut-être très populaire en ce moment mais une fois que les conséquences se feront sentir, les opportunistes partiront aussi vite qu’ils étaient arrivés. »

Pour la plupart des développeurs, il n’y a guère que 5 ans peut-être que l’open source est devenu populaire. La large communauté des concepteurs de logiciel débat rarement de la pérennité à long terme de l’open source, et n’a parfois même pas conscience du problème. Avec l’explosion du nombre de nouveaux développeurs qui utilisent du code partagé sans contribuer en retour, nous construisons des palaces sur une infrastructure en ruines.

Nadia Eghbal a déjà évoqué plusieurs fois les liens entre l’argent et l’open source (si vous avez manqué des épisodes). Elle y revient dans ce chapitre, en insistant sur les questions fondamentales que pose l’argent aux communautés open source ainsi qu’à leurs membres.

Question de nature quasi-philosophique : l’open source peut-il perdre son âme à cause de l’argent ? Question de gouvernance : qui va décider de l’utilisation des fonds ? Et pour finir question éthique et politique : jusqu’à où peut-on, doit-on accepter les requêtes des financeurs ?

La relation compliquée de l’open source avec l’argent

Traduction Framalang : goudron, Penguin, serici, goofy, Rozmador, xi, Lumibd, teromene, xi, Diane, et 3 anonymes

L’argent est un sujet tabou dans les projets open source, et ce depuis les premiers jours du mouvement du logiciel libre qui émergea en réponse directe aux pratiques commerciales des logiciels propriétaires. Dans le contexte du mouvement du logiciel libre, l’aversion pour l’argent est tout à fait compréhensible. L’argent est ce qui permettait de commercialiser les logiciels dans les années 1980 et il a fallu des décennies pour revenir sur cet état d’esprit et promouvoir les avantages liés à l’élaboration de logiciels qui soient libres d’utilisation, de distribution et de modification. Même si de nos jours, nous prenons les logiciels libres pour acquis, dans les années 1980, c’était une véritable contre-culture, un état d’esprit révolutionnaire.

Au sein même des communautés open source, il existe une croyance répandue selon laquelle l’argent est de nature à corrompre l’open source. Et en effet, le nombre de projets nés d’un « travail-passion » est assez incroyable. Aujourd’hui, le développement de logiciel est considéré comme un domaine lucratif, dont les écoles de programmation appâtent leurs futurs étudiants avec des promesses de premiers salaires en dollars à six chiffres. Par contraste, il y a quelque chose de pur et d’admirable dans le fait de créer un logiciel simplement pour le plaisir.

D’un point de vue plus pratique, les projets open source se créent traditionnellement autour d’un besoin réel et identifiable. Quelqu’un estime qu’un projet pourrait être mieux fait, décide de le forker, effectue des améliorations, puis les diffuse pour qu’on en fasse usage. Le pragmatisme est au cœur de la culture open source, comme le prouve sa scission stratégique avec le mouvement du logiciel libre à la fin des années 1990. Certains contributeurs open source craignent, peut-être avec raison, que l’argent n’introduise un développement « artificiel » du système, avec des développeurs qui lancent de nouveaux projets simplement pour acquérir des financements, plutôt que pour répondre à un besoin réel.

David Heinemeier Hansson (aussi connu sous le pseudo de DHH), qui a créé le framework populaire Ruby on Rails, mettait en garde en 2013 contre les mélanges entre open source et argent :

Si l’open source est une incroyable force pour la qualité et pour la communauté, c’est précisément parce qu’elle n’a pas été définie en termes de marché. Dans le cadre du marché, la plupart des projets open source n’auraient jamais eu leur chance.

Prenez Ruby on Rails. […] C’est une réalisation colossale pour l’humanité ! Des milliers de gens, collaborant pendant une décennie entière pour produire une structure et un écosystème incroyablement aboutis, disponibles pour tous gratuitement. Prenez une seconde pour méditer sur l’ampleur de cette réussite. Pas seulement pour Rails, évidemment, mais pour de nombreux autres projets open source, encore plus grands, avec une filiation plus longue et encore plus de succès.

C’est en considérant ce fantastique succès, dû aux règles de vie d’une communauté, que nous devrions être extraordinairement prudents avant de laisser les lois du marché corrompre l’écosystème.

Structurellement, le meilleur atout de l’open source : son penchant pour la démocratie, est aussi sa faiblesse. Beaucoup de projets open source ne sont rien de plus qu’un dépôt numérique public où est stocké du code auquel un groupe de gens contribue régulièrement : l’équivalent d’une association officieuse sur un campus universitaire. Il n’y a pas de structure légale et il n’y a pas de propriétaire ou de chef clairement défini. Les  « mainteneurs » ou les contributeurs principaux émergent souvent de facto, en fonction de qui a créé le projet, ou de qui y a investi beaucoup de temps ou d’efforts. Cependant, même dans ces cas-là, dans certains projets on répugne à introduire une hiérarchie favorisant clairement un contributeur par rapport à un autre.

En avril 2008, Jeff Atwood, un développeur .NET bien connu et dont nous avons déjà parlé, a annoncé qu’il donnait 5 000 $ au projet open source : ScrewTurn Wiki. ScrewTurn Wiki est un projet de wiki développé par Dario Solara, un autre développeur .NET, et maintenu par des volontaires. Atwood a dit à Dario que le don était « sans condition » : Solara pouvait utiliser l’argent de la manière qu’il jugerait la plus utile au projet.
Plusieurs mois plus tard, Atwood demanda à Solara comment il avait décidé de dépenser l’argent. Solara lui répondit que l’argent de la donation était « encore intact. Ce n’est pas facile de l’utiliser… Que suggères-tu ? » Atwood a écrit que cette réponse l’avait « terriblement déçu ».

La nature décentralisée du monde open source en a fait ce qu’il est : des logiciels produits de façon participative, que n’importe qui peut élaborer, partager, et améliorer. Mais quand vient le moment de discuter des besoins organisationnels, ou de la viabilité, il peut être difficile de prendre des décisions faisant autorité.

Ces transitions vers une viabilité à long terme peuvent êtres interminables et douloureuses. Un des exemples les plus connus est le noyau Linux, un projet open source utilisé dans de nombreux systèmes d’exploitation à travers le monde, parmi lesquels Android et Chrome OS. Il a été créé en 1991 par Linus Torvalds, un étudiant en informatique .
Au fur et à mesure que le noyau Linux gagnait en popularité, Linus rechignait à discuter de l’organisation du développement du projet, préférant tout gérer tout seul.  L’inquiétude et aussi la colère à l’égard de Torvalds grandirent chez les développeurs du projet, déclenchant de « vraies grosses disputes » selon Torvalds. Le conflit a atteint son apogée en 2002, on évoqua même un possible schisme.

Torvalds attribua ces conflits internes à un manque d’organisation, plutôt qu’à un quelconque problème technique :

Nous avons eu de vraies grosses disputes aux alentours de 2002, quand j’appliquais des correctifs à droite à gauche, et que les choses ne fonctionnaient vraiment pas. C’était très douloureux pour tout le monde, et également beaucoup pour moi. Personne n’aime vraiment les critiques, et il y avait beaucoup de critiques virulentes, et comme ce n’était pas un problème strictement technique, on ne pouvait pas juste montrer un correctif et dire :  « Hé, regardez, ce patch améliore les performances de 15% » ou quoique ce soit de ce genre. Il n’y avait pas de solution technique. La solution a été d’utiliser de meilleurs outils, et d’avoir une organisation du travail qui nous permette de mieux distribuer les tâches.

La Fondation Linux a été créée en 2007 pour aider à protéger et à maintenir Linux et ses projets associés. Torvalds ne pilote pas la Fondation Linux lui-même, il a préféré recevoir un salaire régulier en tant que « Compagnon Linux », et travailler sur ses projets en tant qu’ingénieur.

Malgré le fait que le logiciel open source soit admirablement ancré dans une culture du volontariat et de la collaboration relativement peu touchée par des motivations extérieures, la réalité est que notre économie et notre société, depuis les sociétés multimillionnaires jusqu’aux sites web gouvernementaux, dépendent de l’open source.

Dans l’ensemble, c’est probablement une évolution positive pour la société. Cela signifie que les logiciels ne sont plus limités à un développement privé et propriétaire, comme cela a été le cas pendant des dizaines d’années. Le fait que le gouvernement des États-Unis, ou un réseau social possédant des milliards d’utilisateurs, intègrent des logiciels construits par une communauté, annonce un futur optimiste pour la démocratie.

De plus, de nombreux projets fonctionnent très bien de manière communautaire lorsqu’ils sont d’une des deux tailles extrêmes possibles, c’est-à-dire soit des petits projets qui ne demandent pas de maintenance significative (comme dans l’exemple de Arash Payan et Appirater), soit de très gros projets qui reçoivent un soutien important de la part d’entreprises (comme Linux).

Cependant, beaucoup de projets sont coincés quelque part entre les deux : assez grands pour avoir besoin d’une maintenance significative, mais pas d’une taille suffisante pour que des entreprises déclarent leur offrir un soutien. Ces projets sont ceux dont l’histoire passe inaperçue, ceux dont on ne parle pas. Des deux côtés, on dit aux développeurs de ces projets « moyens » qu’ils sont le problème : du côté des « petits projets », on pense qu’ils devraient simplement mieux s’organiser et du côté des « gros projets », on pense que si leur projet était « assez bon », il aurait déjà reçu l’attention des soutiens institutionnels.

Il existe aussi des intérêts politiques autour de la question du soutien financier qui rendent encore plus difficile la prospection d’une source de financement fiable. On peut imaginer qu’une entreprise seule ne souhaite pas sponsoriser le développement d’un travail qui pourrait également bénéficier à son concurrent, qui lui n’aurait rien payé. Un mécène privé peut exiger des privilèges spécifiques qui menacent la neutralité d’un projet. Par exemple, dans les projets en lien avec la sécurité, le fait d’exiger d’être le seul à qui sont révélées les potentielles failles (c’est-à-dire payer pour être le seul à connaître les failles de sécurité plutôt que de les rendre publiques) est un type de requête controversé. Des gouvernements peuvent également avoir des raisons politiques pour financer le développement d’un projet en particulier, ou pour demander des faveurs spéciales comme une « backdoor » (une porte dérobée, c’est-à-dire un accès secret qui permet d’outrepasser les authentifications de sécurité), même si le projet est utilisé dans le monde entier.

Les récents démêlés légaux entre le FBI et Apple sont un bon révélateur des tensions qui existent entre technologie et gouvernement, au-delà même des projets open source.
Le FBI a, de manière répétée, et à l’aide d’assignations en justice, demandé l’aide d’Apple pour déverrouiller des téléphones afin d’aider à résoudre des enquêtes criminelles. Apple a toujours refusé ces requêtes. En février 2016, le FBI a demandé l’aide d’Apple pour déverrouiller le téléphone d’un des tireurs d’une attaque terroriste récente à San Bernardino, en Californie. Apple a également refusé de les aider, et a publié une lettre sur son site, déclarant :

Tout en croyant que les intentions du FBI sont bonnes, nous pensons qu’il serait mauvais pour le gouvernement de nous forcer à ajouter une « backdoor » dans nos produits. Et finalement, nous avons peur que cette demande mette en danger les libertés que notre gouvernement est censé protéger.

En mars 2016, le FBI a trouvé une tierce partie pour l’aider à déverrouiller l’iPhone et a laissé tomber l’affaire.

Une des plus grandes forces de l’open source est que le code est considéré comme un bien public, et beaucoup de projets prennent la gestion de ces projets au sérieux.  Il est important à titre personnel, pour beaucoup de développeurs de projets, que personne ne puisse prendre seul le contrôle d’une chose que le public utilise et dont il bénéficie. Toutefois, cet engagement à rester neutre a un prix, puisque beaucoup de ressources disponibles pour les développeurs de nos jours (comme les capitaux-risques ou les donations d’entreprises) attendent en contrepartie d’influer sur le projet ou des retours sur investissement.

Le logiciel open source est créé et utilisé de nos jours à une vitesse jamais vue auparavant. Beaucoup de projets open source sont en train d’expérimenter la difficile transition d’une création désintéressée à une infrastructure publique essentielle.
Ces dépendances toujours plus nombreuses signifient que nous avons pour responsabilité partagée de garantir à ces projets le soutien dont ils ont besoin.