À propos du syndicalisme logiciel

natacha
October 24, 2021

À propos du syndicalisme logiciel

par @spacekookie

(traduction de On software syndicalism)

Résumé

Les organisations, groupes et projets sous le capitalisme ont tendance à la centralisation. Cela est dû à la fois à des incitations monétaires (il peut être plus économique d’avoir un modèle de quelque chose au lieu de plusieurs), ainsi qu’à des enjeux d’autorité ; il est plus facile de contrôler une organisation structurée hiérarchiquement.

La façon dont nous organisons les projets de logiciels libres est influencée par ce cadre sociétal, qui reproduit un grand nombre de problèmes auxquels les organisations, les projets et les entreprises sous le capitalisme sont également confrontés. Il n’est peut-être pas surprenant que nos solutions à ces problèmes soient aussi largement similaires : centrées sur un concept de la personnalité et de nature hiérarchique.

Les projets utilisent souvent les mêmes critères de réussite que la société capitaliste : la croissance, la portée et l’attrait du public. Cela reproduit le phénomène des systèmes démocratiques représentatifs et des créateurs de technologies propriétaires, qui se plient à
la majorité et laissent les besoins des minorités largement sans réponse.

Dans cet essai, nous proposons une structure organisationnelle pour les projets logiciels et techniques qui supprime la notion d’« upstream » et introduit une approche de propriété collective des logiciels et des connaissances techniques. La liberté d’idées (la base fondamentale du logiciel libre) est une condition essentielle de cette approche.

En outre, nous souhaitons mettre cette théorie en pratique en créant un syndicat de logiciels autour du projet DREAM[1], une collection d’outils de collaboration P2P développés par diverses personnes.

Ce texte ne peut espérer résoudre tous les problèmes liés à cette idée, mais il vise à lancer une discussion sur les mérites et les avantages de l’organisation en communautés décentralisées à petite échelle. Notre espoir est que cela suscite la conversation, l’intérêt et la motivation d’autres personnes pour former leurs propres syndicats de logiciels, afin de posséder, développer et maintenir collectivement les technologies sur lesquelles nos vies sont construites.

Domaine du problème

Le développement et la maintenance de logiciels représentent un travail considérable, et sont en grande partie un exercice social, plutôt que technique. Si certains individus sont capables de créer un projet par eux-mêmes grâce à leur passion et leur détermination, il est peu probable que les projets sans communauté survivent à la période d’engagement concentrée du créateur initial.

En amont

Cette relation entre créateurs et consommateurs est formalisée par le concept d’« upstream ». Le développement de logiciels est considéré comme une rivière dont la source est originelle et qui peut se diviser en différents ruisseaux et rivières pour s’adapter à son environnement.

Bien qu’il s’agisse d’une métaphore pertinente de la manière dont les logiciels sont développés à partir d’une source centralisée, elle s’accompagne d’un grand nombre de contraintes et de défis. Une source empoisonnée peut détruire l’écosystème d’une rivière, et de la même manière, une équipe de développement en amont malhonnête[2][3] peut condamner les usagers dépendant de l’écosystème en aval de ce projet.

Les forks s’écartent parfois complètement de l’amont original, mais c’est un engagement que très peu sont capables de maintenir sans un engagement substantiel de la communauté (et une réaction publique).

Forks

Maintenir un logiciel en fork[4] représente beaucoup de travail. Bien qu’il soit difficile d’obtenir des statistiques exactes, notre hypothèse est que la plupart des forks de logiciels échouent en raison du manque d’engagement de la communauté[5][6][7]. Cette dynamique sociale dissuade les gens de faire bifurquer des projets logiciels qui se développeraient dans une direction qu’ils n’approuvent plus, ou qui ne représentent plus leurs souhaits et leurs valeurs : alors qu’en théorie, il est toujours possible de faire bifurquer le logiciel ou la technologie, il faut reconnaître que la réalité de la situation est hors de portée de la plupart des gens.

Organisation

Les méthodes d’organisation utilisées par les projets logiciels et techniques sont souvent axées sur des points d’autorité centraux, de la même manière que le code (ou les fichiers de conception) eux-même sont traités. Il s’agit d’une limitation due à la nature de l’organisation autour d’une plate-forme unique, et elle découle de la façon dont de nombreux outils sont construits pour répondre aux besoins des entreprises capitalistes où la centralisation est un effet désiré.

S’il est possible pour un petit groupe de prendre des décisions très efficacement en privé, cela signifie également que toutes les voix de la communauté ne peuvent être prises en compte.

Toutefois, les processus de décision décentralisés et ouverts sont réputés pour être leur taille maximale, au-delà de laquelle ils échouent en raison de l’impossibilites de prendre en compte la quantité des réactions, des trolls, ou des deux. Une communauté importante qui
a récemment rencontré ce problème est le projet de langage Rust, ce qui a entraîné la création d’un groupe de travail en 2019 pour traiter ces questions[8][9][10].

Principes

Cette section présente les différents modes de collaboration sur les projets, leurs points forts et la manière dont ils peuvent interagir et s’intégrer les uns aux autres. Ces idées constituent la base sur laquelle le syndicalisme logiciel est construit.

La cabale du projet

Un modèle d’organisation commun qui existe (bien qu’il ne porte pas de nom exact et soit très souvent caché) est ce que nous appelons la « cabale de projet ». Il s’agit d’un groupe de personnes, comprenant souvent le ou les auteurs originaux, qui travaillent sur les fonctionnalités de base et l’expansion d’un projet. Leurs connaissances et leur engagement font avancer l’essentiel du projet, et iels permettent que de nombreuses demandes d’usagers et de programmeurs périphériques soient implémentées.

Si de nombreux projets ont une cabale, peu parlent ouvertement de cette dynamique. Pourtant, ce n’est pas nécessairement une mauvaise dynamique, si elle est discutée et adoptée ouvertement. Visualiser les communautés comme une collection de cercles concentriques partant de la cabale permet aux usagers d’être conscients de la dynamique sociale qui intervient dans la prise de décision, et du chemin par lequel une idée peut être adoptée par le projet.

Le concept de « ponts de connaissances »[11], représente cette relation qui permet aux usagers et aux programmeurs moins expérimentés de communiquer leurs idées à la cabale d’un projet, sans avoir à devenir d’abord des experts dans le domaine du projet.

Distribution et outils

Si les systèmes de contrôle des sources tels que git sont déjà décentralisés, de nombreux outils organisationnels construits autour de ce système ne le sont pas. GitHub, Gitlab et de nombreux autres projets qui s’en inspirent[12][13] suivent les mêmes schémas d’un dépôt
upstream, associé à un endroit central pour suivre les contributions et les problèmes ouverts.

En outre, cette approche affecte également la manière dont les logiciels sont distribués aux usagers finaux.

Une tendance nouvelle et croissante consiste à confier aux programmeurs eux-mêmes l’empaquetage de leurs logiciels[14][15]. Cette démarche vise à simplifier (centraliser) le processus de publication et à réduire le délai entre la création de nouvelles fonctionnalités
et la possibilité pour les usagers de les utiliser.

Adopter l’idée d’une collaboration décentralisée au sein de petites communautés ouvre de nouvelles possibilités d’appropriation de la technologie que nous utilisons. Et bien que les projets visant à décentraliser ces outils de collaboration[16] autour d’un protocole pair
-à-pair tel que ActivityPub [17] ne soient pas strictement nécessaires pour mettre en pratique l’une de ces théories, ils offrent la possibilité de concevoir de nouveaux modes de collaboration qui ne reflètent pas les plateformes centralisées existantes.

Upstream vs Mainline

La plupart des problèmes auxquels nous sommes confrontés lors de la création de réseaux de collaboration distribués sont de nature organisationnelle et non technique. Au fur et à mesure que le processus de développement d’un projet s’éparpille entre différents groupes, il devient important de cataloguer et de suivre les modifications apportées par les différents groupes afin de permettre aux autres de les récupérer facilement et de les intégrer dans leurs propres arborescences.

Pour que ce processus fonctionne, la source originale d’un projet (actuellement appelée « upstream ») doit être remplacée dans l’esprit des programmeurs et des usagers par l’idée d’une implémentation de référence. C’est pourquoi nous proposons et utilisons le terme « mainline » pour décrire cette communauté de projets.

Bien qu’il s’agisse d’une différence subtile, la langue joue un rôle important dans la façon dont les gens se rapportent aux structures et aux processus. Le terme et le concept sont tirés de la manière dont le noyau Linux est développé. Tous les trois mois, un nouveau kernel « mainline » est publié[18] dans le monde, prêt à être utilisé par quiconque s’y intéresse.

Cependant, la plupart des gens n’utilisent pas le noyau principal. Il s’agit d’une configuration de référence destinée à plaire à un public cible très spécifique. La plupart des distributions Linux appliquent leurs propres correctifs sur cette version, suppriment les fonctionnalités qu’elles jugent incompatibles avec leurs idéaux (les microprogrammes propriétaires, par exemple) et redistribuent cette version à leurs usagers. Les projets gagnent à être conscients de leur public cible et aucun projet ne peut espérer plaire à tous les usagers
du monde.

Syndicalisme

Avant de discuter de la façon de construire des syndicats de logiciels, nous devons définir ce qu’est un syndicat, et comment la coopération syndicaliste fonctionne en pratique. Une définition du syndicalisme est « un mouvement politique radical qui préconise de placer l’industrie et le gouvernement sous le contrôle de fédérations de syndicats par l’utilisation de l’action directe »[19]. Le terme est aussi souvent utilisé en relation avec « l’anarcho-syndicalisme »[20] qui met cette théorie en pratique de différentes manières.

Une grande partie de l’activisme politique se fait via des structures syndicalistes. Elles offrent un moyen pour les gens de collaborer les uns avec les autres, sans devoir appartenir à la même organisation à grande échelle, ou suivre exactement le même plan. L’alignement sur les idéaux et les principes des uns et des autres est fondamental pour que ce mode de collaboration fonctionne, tout en évitant bon nombre des problèmes décrits dans les sections précédentes.

La technologie est intrinsèquement politique dans la manière dont elle est créée, entretenue et utilisée, et les programmeurs de logiciels véhiculent leurs propres idéologies dans leur travail, qu’ils en soient conscients ou non. Les barrières culturelles créées par ces idéologies rendent plus difficile la participation des personnes étrangères à l’idéologie (par exemple, parce qu’elles ont un contexte politique différent ou qu’elles viennent d’une autre région du monde).

Le syndicalisme tel qu’il est proposé embrasse l’idéologie politique autour du travail que nous faisons et demande à tous ceux qui participent à ce travail de réfléchir à leurs propres préjugés, hypothèses et comportements. Cela n’exige pas l’uniformité politique (souvent
appelée « unité »). Il s’agit de rendre la collaboration sociale plus transparente et plus facile à comprendre, et d’inciter les programmeurs et les usagers à comprendre leurs propres préjugés et hypothèses sur la base du retour d’information qu’ils reçoivent des autres communautés.

Différents syndicats peuvent également aborder différemment la collaboration de groupe et la prise de décision, tout en travaillant sur la même vision globale d’un projet ou d’une idée.

Nous utilisons ce terme pour évoquer un sentiment d’appartenance, de communauté et de conscience politique des technologies que nous construisons et du travail sur lequel nous collaborons. Le syndicalisme logiciel est l’acte de s’organiser en syndicats et l’applique au développement et à la maintenance de logiciels.

Opportunités

Proximité et silos de connaissances

Les communautés logicielles centralisées ont tendance à recréer des structures de pouvoir colonialistes à travers la distribution des programmeurs et le choix du public cible. Cela crée des silos de connaissances[21] dans ces pays, ce qui est préjudiciable à la responsabilisation et à l’autonomie des programmeurs et des usagers des différents pays. Il existe des différences plus subtiles (par exemple entre le nord et le sud, et l’Europe occidentale et orientale), mais elles sont plus marquées dans les communautés européennes et américaines blanches, par rapport au reste du monde.

L’une des opportunités de créer des syndicats autour de la création et de la maintenance de projets logiciels est de briser cette relation. Pour comprendre comment cela fonctionne, nous devons également discuter du concept de proximité sociale.[22]

Les communautés auxquelles nous appartenons sont basées sur les relations sociales que nous avons avec les gens, et vice versa. Il s’agit de mécanismes de rétroaction bidirectionnels. Grâce à l’internet, la proximité (ou localité) peut exister à la fois dans le monde physique et dans un sentiment méta-physique d’appartenance.

Les usagers et les programmeurs de projets peuvent se trouver à différentes distances de différents syndicats de logiciels, ce qui réduit la barrière d’entrée et offre aux usagers et aux programmeurs plus de choix de points de contact pour un projet de logiciel. Si le syndicat principal autour d’un projet est considéré comme hostile à la collaboration en dehors d’un certain groupe de pairs, d’autres syndicats permettront à des communautés alternatives de voir le jour.

Il est important de noter que rien de tout cela n’est impossible dans le cadre de la vision actuelle du développement logiciel. Une équipe de développement en amont hostile ou malveillante peut être contournée en bifurquant le projet. Cela s’accompagne toutefois d’un grand nombre de responsabilités sociales inexplorées dont beaucoup de gens ont peur. Le fork, puis le maintien d’une communauté autour du fork, représentent un travail considérable qui n’est souvent pas considéré comme faisable.

La création d’un syndicat de logiciel n’est pas nécessairement plus facile en soi, mais elle s’accompagne de l’idée d’une solidarité inter-projets et internationale. Aucun syndicat n’a l’ambition de parler au nom de l’ensemble du projet, ni de satisfaire tous les usagers.
La collaboration est donc essentielle.

Identification

La proximité et la communauté sont des questions d’appartenance et d’identification, qui induisent l’auto-identification des usagers et des programmeurs, et demandent l’exploration des communautés existantes. Les êtres humains sont complexes, tant sur le plan individuel que sur celui des relations qu’ils entretiennent les uns avec les autres. Les labels d’identification sont un outil important à cet égard, mais ne doivent pas être utilisés au fin d’éviter de s’auto-identifier.

Comme tout ce pour quoi les humains ont créé un langage, les étiquettes d’identité sont vagues et ont une certaine flexibilité. Un syndicat de logiciels peut exister pour un groupe d’usagers ayant des besoins spécifiques, ou pour un groupe de programmeurs (et donc d’usagers) basés dans un autre pays, opérant dans une autre langue.

Les syndicats doivent autoréguler leurs membres, mais en même temps, l’identification avec le public cible d’un syndicat devrait suffire pour qu’une personne appartienne au groupe d’usagers de ce syndicat.

La formation de nouveaux syndicats à partir de syndicats existants, si le besoin d’une identification plus granulaire se fait sentir, doit être encouragée et non entravée. Les grandes communautés (comme analysé précédemment) ne sont pas évolutives, et en gardant des syndicats petits et ciblés, beaucoup de ces problèmes peuvent être évités.

Les modèles de décision peuvent être alignés sur deux axes : la connaissance et la confiance.[23] Les relations de connaissance sont basées sur un accord au sujet de principes techniques, elles sont couramment mise en pratique dans les systèmes dits: « méritocratiques ». Les relations de confiance sont fondées sur la compréhension mutuelle des principes qui président à la prise de décision et au développement d’un logiciel.
Ces deux relations peuvent interagir de manière intéressante.

                  confiance élevée
                          ^
                          |
                          |
        CONSENSUS         |          UNANIMITÉ
                          |
                          |
                          |                   accord
   <----------------------------------------------->
   désaccord              |
                          |
                          |          ACCORD
        DISSENSION        |          TECHNIQUE
                          |
                          v
                   peu de confiance

La collaboration est possible dans trois de ces quadrants, bien que seuls deux d’entre eux soient idéaux. Lorsque deux groupes s’accordent sur les détails d’une solution mais ne se font pas confiance, une relation technique peut être établie. Cela implique généralement une
spécification qui est ensuite respectée par les deux groupes (et par d’autres qui se joignent à la relation à un moment ultérieur).

D’autre part, lorsque deux groupes ont une forte relation de confiance, cela permet une collaboration par consensus. La prise de décision par consensus[24] consiste à prendre en compte le point de vue de chaque individu et à prendre une décision sur la base de ces informations. Cela signifie que les individus peuvent être en désaccord sur des points précis, mais trouver un terrain d’entente « acceptable » pour chacun. Cela signifie que les décisions sont basées sur les limites de confort de tous les participants. Il n’y a pas de vote, qui imposerait le point de vue de la majorité sur toute minorité, et chaque partie prenante du système peut exercer un droit de veto pour arrêter une décision.

Ces processus ne fonctionnent qu’en petits groupes, c’est pourquoi les syndicats sont également encouragés à former des relations purement techniques.

Les quadrants « UNANIMITÉ » et « DISSENSION » sont à éviter car ils entraînent un effet de chambre d’écho où la prise de décision monolithique ne permet pas une collaboration efficace.

Défis

Si les sections précédentes ont souligné les possibilités de résoudre (et d’améliorer) le domaine de problèmes existants, cette idée n’est pas exempte de défis. Ce texte propose des solutions pour certains d’entre eux, mais ne peut bien sûr pas espérer être exhaustif.

Fragmentation technique

Il y a des exemple de projets existants qui utilisent une approche similaire[25] qui peuvent souffrir de « fragmentation » ou de « fracturation » (communément appelée « balkanisation »). Il s’agit du processus par lequel des communautés divergent de manière si importante qu’elles ne sont plus compatibles entre elles. Dans le cas de Freifunk, la conséquence est que le logiciel de base continue d’être développé en commun par tous les « chapitres », mais que les configurations et les réseaux sont si différents que le passage d’un réseau à l’autre nécessite de reconfigurer fondamentalement les dispositifs d’infrastructure.

La création de petites communautés syndicales autour de toutes sortes de projets logiciels peut engendrer des problèmes similaires si elle n’est pas gérée en conséquence. Il faut pour cela que les plates-formes de collaboration se développent et évoluent d’une manière qu’elles n’ont pas actuellement, ou que les syndicats fonctionnent selon des principes compatibles, ce qui sera difficile à assurer et à vérifier.

Ça n’a pas été inventé ici!

Un thème commun dans le développement de logiciels est le syndrome du « ça n’a pas été inventé ici » (NIH[26]) qui incite les entreprises à réécrire des projets techniques créés par d’autres parties parce qu’elles n’aiment pas ou ne comprennent pas la solution existante
(et disponible).

Comme les logiciels libres n’existent pas dans une bulle, la configuration d’un nouveau projet affecte également les projets existants. La fragmentation des communautés, les différences sociales et techniques de compréhension, et d’autres facteurs peuvent contribuer à une augmentation du syndrome NIH parmi les syndicats. C’est un problème sans réelle solution. Il peut potentiellement être évité par une meilleure communication.

D’un autre côté, il est important de considérer que ce n’est pas parce que quelque chose a été écrit une fois qu’il n’existe pas d’autres implémentations possibles ou souhaitables. Il est possible de trouver des erreurs dans les spécifications grâce à des implémentations alternatives [27].

Fragmentation politique

De même que les différences d’opinions techniques peuvent fragmenter un projet, on peut dire la même chose des idéologies politiques. Il est réducteur de supposer que l’idéologie en soi est le problème (après tout, ne pas croire aux idéologies est en soi une idéologie). Les étiquettes existent dans le langage pour cataloguer et décrire les choses naturelles et culturelles.

L’important est de reconnaître que différentes étiquettes peuvent exister pour les mêmes principes, et que des conclusions politiques similaires construites sur les mêmes principes sont toujours compatibles entre elles.

Perspectives

Pour conclure cet essai, nous nous tournons vers l’avenir. La manière dont nous construisons des systèmes et dont nous nous organisons en communautés est issue du système capitaliste auquel nous voulons échapper. En outre, il ne s’agit pas simplement de développer des logiciels (et d’autres technologies), mais de donner aux usagers et aux programmeurs une autonomie sur les outils qu’ils construisent et utilisent.

Il est temps de revoir notre mode d’organisation et de prendre conscience des systèmes que nous reproduisons dans notre façon de développer les technologies qui, nous l’espérons, transformeront le monde. Nous en avons cruellement besoin, car boycotter la technologie n’est pas la solution à l’appareil de surveillance sans cesse croissant créé par les systèmes capitalistes.

En définitive, le syndicalisme logiciel consiste à réduire la distance entre la création et la maintenance de la technologie et ses usagers.

  1. https://dream.public.cat ↩︎

  2. https://web.archive.org/web/20210705123342/https://www.techradar.com/uk/news/audacity-fans-are-absolutely-furious-right-now-heres-why ↩︎

  3. https://www.linuxuprising.com/2018/12/jellyfin-free-software-emby-media.html ↩︎

  4. NdE : le terme anglais fork signifie fourche, fourchette ; le verbe to fork peut être traduit, pour nos besoins, par bifurquer. L’on préférera toutefois utiliser le nom anglais dans son sens informatique. ↩︎

  5. https://glimpse-editor.org/posts/a-project-on-hiatus/ ↩︎

  6. https://en.wikipedia.org/wiki/List_of_software_forks ↩︎

  7. Il existe des recherches qui indiquent le contraire de cette affirmation. Cependant, un biais de survivance peut exister dans la façon dont les projets sont annoncés, évalués et identifiés. Des recherches supplémentaires dans ce domaine sont certainement nécessaires.
    https://sci-hub.st/10.1007/978-3-642-33442-9 ↩︎

  8. https://blog.rust-lang.org/2019/04/23/roadmap.html#governance ↩︎

  9. https://boats.gitlab.io/blog/post/rust-2019/ ↩︎

  10. https://spacekookie.de/blog/rust-2019-how-we-make-decisions/ ↩︎

  11. Binding Chaos, Heather Marsh, 2014 – ISBN: 9781989783009 ↩︎

  12. https://github.com/go-gitea/gitea ↩︎

  13. https://sourcehut.org ↩︎

  14. https://flatpak.org ↩︎

  15. https://snapcraft.io/ ↩︎

  16. https://forgefed.peers.community/ ↩︎

  17. https://activitypub.rocks ↩︎

  18. https://en.wikipedia.org/wiki/Linux_kernel_version_history ↩︎

  19. https://www.wordnik.com/words/syndicalism ↩︎

  20. https://fr.wikipedia.org/wiki/Anarcho-syndicalisme#Pratiques_et_idéologie_de_l’anarcho-syndicalisme ↩︎

  21. https://en.wikipedia.org/wiki/Information_silo ↩︎

  22. https://en.wikipedia.org/wiki/Proximity_principle ↩︎

  23. https://media.ccc.de/v/36c3-10858-infrastructures_in_a_horizontal_farmers_community#t=593 ↩︎

  24. https://en.wikipedia.org/wiki/Consensus_decision-making ↩︎

  25. https://en.wikipedia.org/wiki/Freifunk ↩︎

  26. https://en.wikipedia.org/wiki/Not_invented_here ↩︎

  27. https://blogs.oracle.com/developers/building-a-container-runtime-in-rust ↩︎