Démocratie

Ansel devrait être gouverné démocratiquement et de façon équitable envers toutes les personnes impliquées.

Définir une organisation coopérative au-delà du code open-source

On suppose que les développeurs et les utilisateurs qui arrivent ici partagent un intérêt commun : ils veulent être libres dans la manière dont ils retouchent leurs images, aujourd’hui comme à l’avenir. Cela signifie :

• disposer d’un contrôle technique suffisant sur le contenu et les propriétés de leurs images,
• être libres vis-à-vis des capitalistes qui peuvent :
  • augmenter le prix de leur application au seul bénéfice des actionnaires,
  • exploiter les photos des clients pour entraîner des modèles d’IA sans consentement,
  • faire disparaître des applications sans publier leur code source,
• avoir le droit de décider des contours et de la mise en oeuvre de cette liberté.

L’ADN d’Ansel est plus technique et plus fin que celui de la plupart des éditeurs photo RAW, tout en mettant l’accent sur la facilité d’utilisation quand c’est possible, principalement pour les tâches typiques d’un ordinateur de bureau (interactions avec les périphériques d’entrée et les fichiers, paradigmes d’interface graphique, etc.). Ansel n’est ni Darktable  ni ART  parce que sa vision de ce que devrait être un bon logiciel de retouche d’image est assez différente.

Ansel est publié sous licence GNU/GPL , ce qui en fait un logiciel libre/open-source. Même si cela donne un sentiment, erroné, de disponibilité à long terme, la réalité est que cette disponibilité dépend uniquement de la volonté et de la capacité de quelques développeurs à assurer la maintenance quotidienne, fastidieuse, pour qu’il continue de fonctionner, prenne en charge les nouveaux appareils photo, etc., une tâche sous-estimée parce qu’elle ne produit ni notes de version spectaculaires ni keynotes.

Pire encore, la soi-disant « liberté » accordée par la licence GNU/GPL ne concerne que le code source : c’est une liberté d’ingénieur. Les licences open-source lèvent essentiellement la propriété intellectuelle sur le code, ce qui signifie que les ingénieurs peuvent l’étudier et le modifier, puis partager leurs modifications. Sachant que moins de 6 % de la population mondiale¹ sait réellement écrire du code, il s’agit d’un droit réservé à une minorité privilégiée. Quant aux utilisateurs, la licence GPL est très claire :

Ce programme est distribué dans l’espoir qu’il sera utile, mais SANS AUCUNE GARANTIE ;

Cette déclaration exclut en pratique les utilisateurs finaux de la transaction : ils n’ont aucun autre droit que d’exécuter le code en l’état, en particulier aucun droit au support ni aux corrections de bugs, encore moins à voir le logiciel évoluer selon leurs besoins. Si un support est malgré tout fourni, c’est à la discrétion des développeurs et les utilisateurs devraient lui être éternellement reconnaissants. Cet argument est utilisé abusivement dans les soi-disant « communautés open-source » (c’est-à-dire des forums logiciels) pour faire taire et invalider toute plainte d’utilisateur : ils ne pourraient tout simplement pas se plaindre puisqu’ils utilisent du travail gratuit, même si le marketing des projets open-source se montre souvent lyrique au sujet du caractère « professionnel » de ces applications. Mais… des promesses ont été faites, le mot « pro » a été prononcé sans être tenu, donc il y a quelque part une incohérence trompeuse.

Même en se dégageant de toute responsabilité envers les utilisateurs, beaucoup de projets essaient tout de même d’en faire, sinon des clients, au moins des donateurs. Or ils se heurtent à un triste état de fait : 350 ans de capitalisme ont pourri nos cerveaux au point de nous faire croire que les applications open-source étaient les concurrentes bon marché des logiciels propriétaires. Les utilisateurs restent simplement assis à attendre que les projets livrent un produit avant de décider s’ils prendront la peine de donner. C’est comme commencer à financer la NASA après le lancement de la première fusée pour prouver que le projet peut effectivement tenir ses promesses : cela ne peut pas marcher. Il faut payer le travail avant même qu’il n’y ait un produit à vendre. Et quand le produit sort enfin, des projets comme Wikipédia peinent encore à obtenir moins de 3 $ par an de 2 % de leur base d’utilisateurs.

Les applications open-source sont concurrentes des applications propriétaires comme les hôpitaux publics sont concurrents des cliniques privées : elles ne le sont pas. D’un côté, nous avons un projet socialiste fondé sur la conviction que tout le monde a droit aux soins et que, si certaines personnes n’en ont pas les moyens, nous nous organiserons pour trouver de l’argent supplémentaire dans la collectivité. De l’autre, nous avons des actionnaires qui cherchent à faire du profit, en embauchant des chirurgiens qui essaient de payer leur villa à Malibu et leur collection de Porsche. En quoi seraient-ils concurrents ? Un service public est un moyen de garantir aux gens les ressources nécessaires pour exercer leurs droits, parce que la liberté n’est que théorique tant qu’on n’a pas les moyens concrets d’en faire usage. Une entreprise privée qui vend des biens ou des services est un moyen de tirer de l’argent d’investissements. La différence est politique. Elle est aussi économique, puisque l’absence d’actionnaires à rémunérer rend de toute façon le produit final plus abordable.

L’angle mort du mouvement du « logiciel libre » a été d’éviter de penser le contexte et la structure de travail dans lesquels ce type de logiciel naît, est développé et maintenu. On peut remonter cela à la culture hacker , individualiste par nature et compatible avec le capitalisme par ricochet, via la technophilie  et le technosolutionnisme . « Partager tel quel » (son travail, son code, ses bidouilles) a été confondu avec « prendre soin de » (des besoins, des limites, des difficultés d’autrui) et entretenu par des récits quasi hagiographiques. Quand on a un marteau, tout ressemble à un clou : quand tout ce qu’on connaît, c’est le code, le code devient la solution à tout, et essayer d’enrober cela de philosophie et de politique, non révolutionnaire, pour définir une « liberté du code » passe encore à côté du tableau d’ensemble, à savoir l’exploitation du travail de tout le monde par une petite classe sociale puissante, auto-reproductrice. Si 6 % de la population mondiale savaient écrire du code en 2021, la proportion de celles et ceux qui pouvaient seulement se payer un ordinateur personnel dans les années 1980, quand le mouvement du logiciel libre a commencé, était bien plus faible. Les minorités privilégiées sont toujours aveugles à leurs privilèges : c’est à cela qu’on les reconnaît. Elles n’ont pas vu que le logiciel libre n’était rien d’autre que l’enfant de ces privilèges. C’est une liberté réservée à celles et ceux qui peuvent se l’offrir. Et le fait que l’étiquette du prix ne porte pas de signe dollar la rend perverse. Il y a quand même un prix.

Le mouvement du logiciel libre a été conçu pour s’insérer dans ce capitalisme individualiste, entrepreneurial et de libre marché, et il a fait croire à tout le monde qu’il suffisait de laisser chacun lancer son propre projet ou forker celui des autres. Ensuite, le darwinisme social  ferait le tri. Oui, mais… qui paie le travail ? Pire encore, puisque le capitalisme ne donne de valeur au travail que lorsque son produit est vendu sur un marché libéral, et que cette valeur est indexée sur la rareté du produit, comment sommes-nous censés convaincre les utilisateurs qu’une chose dématérialisée, téléchargeable à l’infini et gratuitement, a une quelconque valeur ? Beaucoup de projets open-source ont essayé de nombreuses stratégies pour financer leur travail ; elles restent toutes précaires et boiteuses parce qu’elles veulent encore faire entrer une structure de travail communiste par nature dans un cadre capitaliste (j’y reviens plus bas).

Si les organisations à but non lucratif peuvent fonctionner pour des projets humanitaires, où les donateurs ne seront jamais les destinataires du travail, pour les projets logiciels les dons sont intéressés parce que les donateurs sont aussi des utilisateurs. Cela entretient un comportement de consommateur, où des consommateurs passifs, et dans une certaine mesure opprimés, attendent des biens livrés par une minorité élitaire de membres du conseil d’administration qui décident de tout. Ces organisations à but non lucratif restent dirigées de manière privée, et le public n’a pas d’autre droit que d’arrêter de donner s’il ne se sent pas entendu. Le conseil d’administration de la Linux Foundation  est composé presque exclusivement de dirigeants de fabricants de matériel et des GAFAM , celui de la Free Software Foundation  est composé de scientifiques et de techniciens informatiques. Les utilisateurs n’y sont pas représentés ; on y retrouve des structures hiérarchiques verticales des « sachants » au-dessus de « ceux qui ont besoin », perpétuant le même type de domination que le capitalisme, sans les profits.

Cela se justifie par le fait que les licences open-source déchargent les développeurs de toute forme de responsabilité, de garantie, envers les utilisateurs, ce qui en fait une transaction à sens unique donnant en apparence tout le pouvoir de décision aux développeurs. Mais tout cela est évidemment une construction, pas une fatalité. À l’autre bout de la chaîne, parce que le dogme capitaliste est si profondément imprégné dans le cerveau des utilisateurs, le code source place un logiciel sur un marché libre, dématérialisé et non rare, qui annule toute notion de valeur capitaliste, ce qui rend acceptable pour les utilisateurs de profiter du produit du travail sans contribution : une autre transaction à sens unique. Pendant ce temps, certains développeurs s’épuisent et font des burn-out pour assurer un support utilisateur raisonnable, sans tirer de revenu raisonnable de leur travail exploité, peut-être dans l’espoir que cela finira par payer à long terme, une fois qu’ils auront « percé ». Ou bien les développeurs acceptent la règle implicite de l’open-source, qui voudrait que cela ne soit qu’un hobby ou une activité à temps partiel, ce qui condamne inévitablement l’open-source à rester le parent pauvre du logiciel propriétaire. Ou encore, enfin, certaines entreprises open-source comme Automattic  ou RedHat  deviennent avec le temps toujours plus agressivement avides, en affrontant le retour de bâton de leurs communautés. Rien de tout cela n’est durable, pour aucune des parties impliquées.

Nous devons transformer ces deux transactions parallèles à sens unique en cercle. Voici comment :

1. Aucune technologie ne peut exister en dehors de la société qui la produit. La technologie a besoin de science. La science a besoin de recherche. La recherche a besoin de structures dans lesquelles elle peut être menée librement. La société est l’environnement où tout cela se produit, ainsi que le système de soutien qui le rend possible.
2. Aucune technologie ne peut exister sans travail. Si le produit de ce travail échappe au système capitaliste, fondé sur la rareté et la concurrence de marché, alors le travail qui le produit doit lui aussi lui échapper.
3. Aucune technologie détenue par des intérêts privés ne servira le bien commun et l’intérêt public. Les technologies, et pas seulement les appareils, devraient appartenir à leurs utilisateurs, pas seulement à leurs fabricants.
4. Le travail est la seule richesse. Les travailleurs devraient bénéficier de leur travail, qu’il soit vendu sur un marché libéral ou non : il doit être rémunéré quoi qu’il arrive. Le travail devrait se faire dans un environnement sûr et équitable. C’est une responsabilité collective et sociale de le rendre possible, parce que le produit du travail sert le bien commun et l’intérêt public. Le travail qui ne sert ni l’un ni l’autre devrait simplement être arrêté.
5. Des technologies possédées par leurs utilisateurs ouvrent la voie à un nouveau type de production : la collaboration entre fabricants et utilisateurs, au lieu de la concurrence entre fabricants et des guerres d’entreprises pour conquérir des marchés en persuadant les clients de la supériorité d’un produit, ce qui fait en fin de compte payer la publicité par les utilisateurs… Mais le capitalisme ne sait pas vendre le produit de la coopération, parce qu’il n’y a plus d’acheteur ni de vendeur séparés, seulement une communauté de personnes qui travaillent ensemble vers quelque chose : satisfaire leurs besoins, transformer leurs droits théoriques en liberté effective en créant le contexte permettant de les exercer.
6. Il existe une responsabilité mutuelle des producteurs envers les utilisateurs, satisfaire leurs besoins par et avec la technologie, et des utilisateurs envers les producteurs, leur donner un environnement de travail sûr et juste ainsi que des conditions matérielles d’existence. C’est la base même d’une communauté²…
7. L’open-source menant à une véritable liberté ne peut advenir qu’au sein d’une structure coopérative . Il s’agit d’un communisme ancien, éprouvé et déjà fonctionnel, où l’entreprise, et donc le projet open-source au sens large, appartient à ses clients et à ses travailleurs, qui se partagent le pouvoir de vote. Cela va bien au-delà d’une simple renonciation à la propriété intellectuelle, licence open-source ou libre.

Une coopérative permet de briser cette dichotomie entre « nous » et « eux », fabricants contre utilisateurs, qui nourrit le ressentiment mutuel : les développeurs seraient des dictateurs transformant l’application en terrain de jeu personnel, auxquels les utilisateurs devraient toujours être reconnaissants, peu importe les dégâts, tandis que les utilisateurs seraient des sangsues pénibles qui ne cessent d’ouvrir des tickets obscurs et de demander des fonctionnalités, tout en donnant trop peu.

Dans une coopérative, producteurs et utilisateurs sont tous membres-associés. Ils possèdent tous le projet et disposent chacun d’une voix à l’assemblée générale. Le projet consiste à rendre la retouche photo libre pour un avenir prévisible, selon une vision commune de ce qu’est la retouche photo, plus ou moins technique et fine, plus ou moins simple et accessible. Pour atteindre cet objectif, de nombreux moyens entrent en jeu, comme l’éducation, le plaidoyer, la documentation et, bien sûr, une application logicielle. Le projet est plus qu’un produit final, qui peut mettre du temps à apparaître et à être prêt : le projet, c’est tout ce qu’il y a au-dessus et autour, c’est un but et tous les moyens de le rendre réel.

La responsabilité des membres est de garantir un budget annuel couvrant l’ensemble des coûts du projet, très probablement grâce à des cotisations annuelles. À partir de ce budget, un certain volume d’heures de travail, à un certain taux horaire, est décidé en assemblée générale. La manière dont ce budget sera dépensé, types de tâches, matériel, outils, etc., est elle aussi décidée en assemblée générale. Pour les tâches techniques, comme le développement logiciel, il s’agira d’orientations de haut niveau, par exemple améliorer les masques ou les flux de travail en lot, et non de détails d’implémentation ou du design proprement dit, qui se prêtent mal aux processus démocratiques. Les développeurs peuvent pousser des tâches orientées backend, comme la réécriture ou le refactoring de dette technique pour réduire les coûts de maintenance à long terme, tandis que les utilisateurs peuvent pousser des tâches orientées fonctionnalités, comme la prise en charge de nouvelles fonctions d’appareil photo ou de nouveaux formats d’image : le rôle de l’assemblée générale est de délibérer et de hiérarchiser les priorités.

Les tâches retenues seront ensuite prises en charge par des travailleurs rémunérés, dans l’ordre des priorités, jusqu’à épuisement du budget de travail. Cela ne se limite pas au travail technologique ni au développement, mais s’applique à tout type de travail préalablement approuvé. Lorsque le budget est consommé, les travailleurs rendront compte de l’endroit où ils se sont arrêtés dans la liste des tâches, de ce qu’ils ont pu terminer, de ce qu’ils n’ont pas pu terminer et des ressources qui ont manqué pour aller au bout. L’assemblée générale décidera alors s’il est possible et souhaitable d’investir davantage de ressources pour finir, ou de repousser les tâches restantes au budget annuel suivant. Cela donne aux travailleurs de la visibilité sur leur revenu annuel sans encourager le surengagement ni le burn-out.

Les utilisateurs peuvent former des groupes pour travailler avec les développeurs à comprendre les problèmes réellement rencontrés, tester et valider des solutions dans le cadre d’un processus de design. Tout utilisateur peut devenir travailleur et commencer à percevoir un revenu pour son travail sur des tâches approuvées, avec l’accord de l’assemblée générale.

Cela fait de chacun la personne responsable de s’assurer que les ressources nécessaires pour avancer sont réunies, et de donner aux travailleurs ce dont ils ont besoin pour travailler correctement, en sécurité, sans être exploités. Aucun travail ne devrait être gratuit, quelle que soit la tâche. Le travail ne doit pas se limiter à la programmation ou à d’autres tâches techniques.

Les limites de la démocratie

La démocratie par le vote consiste essentiellement à exprimer la volonté de la majorité, dont on sait qu’elle peut opprimer les minorités. Elle n’est donc pas parfaite. Les minorités peuvent soulever des préoccupations raisonnables et légitimes, qui ne seront simplement pas partagées par la majorité. On pense ici aux personnes handicapées : certains détails de conception peuvent rendre l’application entièrement inutilisable pour elles, même si elles ne sont pas assez nombreuses pour imposer leur point de vue par un vote. À l’inverse, il n’est pas possible d’accommoder les besoins particuliers de tout le monde sans créer des monstres. Cela doit être évalué et arbitré avec soin.

La responsabilité de la majorité est donc d’identifier quelles sont les minorités structurelles, c’est-à-dire quelles propriétés relient ces minorités entre elles, état de santé, origine sociale, niveau d’éducation, niveau de revenu, etc. Si une minorité soulève un problème qui lui est bloquant à cause de l’une des propriétés qui la définissent, il devrait exister un moyen de contourner ou de rééquilibrer le vote majoritaire. Cela reste à définir, mais la manière la plus simple d’en tenir compte passe par les délibérations, ce qui repose sur l’empathie et la compréhension de la majorité.

Un autre problème de tout groupe social est la pensée de groupe , parce que tout groupe social tend avec le temps à se dégrader en club. La pensée de groupe apparaît lorsque les individus ne se sentent plus libres de soulever des objections qui vont contre le consensus supposé du groupe, par peur des répercussions sur leur place et sur la manière dont ils seront perçus dans le groupe. Ces répercussions peuvent être très subtiles tout en étant bien réelles. Cela devient nuisible lorsque des individus commencent à soutenir, au sein du groupe, des décisions qu’ils n’auraient pas soutenues seuls : c’est le point de bascule où la rationalité individuelle se perd. Pour éviter cela, on peut utiliser le vote anonyme, mais cela ne s’applique pas aux délibérations où il y a nécessairement une personne qui prend la parole. Il y a donc une culture du désaccord sain à construire, entretenir et encourager. Une façon de traiter ce problème consiste à désigner aléatoirement un « avocat du diable » pour chaque séance, dont le rôle serait de contredire en permanence et d’exposer les arguments correspondants.

Toute communauté fondée sur un intérêt commun pour la photographie et le logiciel libre sera vraisemblablement biaisée en faveur d’hommes aisés, instruits, à l’aise avec l’informatique et anglophones. Il faudra un effort conscient pour essayer d’inclure les femmes, les personnes moins diplômées, les citoyens non occidentaux, etc. Combiné à la démocratie par le vote et à la pensée de groupe, il peut être très dommageable de partir d’un groupe aussi homogène socialement si cela n’est pas géré avec précaution. Ce sera un défi quotidien dont tout le monde devra avoir conscience. Cela alimentera aussi le biais du survivant , où les exclus ne sont plus là pour expliquer pourquoi ils n’ont pas rejoint, participé ou se sont sentis bienvenus, et où les personnes marginalisées auront besoin d’un effort particulier pour être atteintes et accueillies.³ Aucun racisme ni sexisme ne peut être toléré dans un tel environnement, même sur le ton de la plaisanterie, parce que cela reviendrait à faire rire la majorité aux dépens des minorités dans un contexte où elles sont déjà filtrées à l’entrée.

La démocratie est aussi un processus lent. Certaines situations peuvent exiger une décision rapide, comme une faille de sécurité sur le serveur du projet ou sur ses comptes de réseaux sociaux, ou encore un problème juridique urgent. Il faudrait donc élire quelqu’un pour des mandats courts afin de pouvoir prendre rapidement ces décisions au nom de la communauté.

Les limites des experts face aux profanes

Tout comme les médecins ou les avocats, les développeurs disposent de compétences et d’une expérience spécialisées qui leur confèrent une certaine forme de pouvoir, voire de charisme, sur les profanes. Ce pouvoir peut être utilisé abusivement pour opprimer la majorité en exploitant son manque de connaissances au bénéfice de l’oppresseur. Cette relation sera toujours asymétrique, et il faut le reconnaître. De plus, les développeurs devront être consultés lors des délibérations en assemblée générale afin d’évaluer la faisabilité des tâches et les ressources nécessaires avant que les votes n’aient lieu.

Tout comme les médecins, les avocats, etc., les développeurs devraient respecter une forme de code de déontologie à la hauteur de leur pouvoir symbolique, comprenant notamment :

1. un devoir d’informer honnêtement, au mieux de leurs connaissances, et d’expliquer simplement ce qui peut l’être,
2. un devoir de rigueur dans la méthode et de diligence lors de la recherche et du développement des solutions,
3. un engagement à travailler dans l’intérêt supérieur de la communauté.

À l’inverse, les développeurs, ou tout autre expert, peuvent être perçus par les profanes comme des sorciers omniscients et tout-puissants, qui peuvent alors exiger trop d’eux. Bien que le logiciel soit un médium assez malléable, il existe malgré tout des contraintes techniques non négociables, et tout ce qui est techniquement possible ne l’est pas forcément dans les circonstances actuelles avec les ressources actuelles.

Ces deux positions devront être comprises afin d’éviter que le ressentiment mutuel ne s’installe.

Les limites de la collaboration

Tout le monde est designer.

Tout métier que l’on ne connaît pas semble facile à faire. Concevoir et fabriquer des objets techniques en fait partie. Il est même enthousiasmant d’y contribuer. Mais un logiciel qui sera utilisé comme outil par des milliers d’utilisateurs autres que soi n’est pas la même chose que sa propre table de chevet.

Les utilisateurs devraient être invités à participer à la définition du problème : partir d’un ou de plusieurs utilisateurs rencontrant un problème particulier dans un flux de travail particulier, voir si cela ne peut pas déjà être résolu avec les outils actuels et peut-être un peu de pédagogie, et sinon essayer d’évaluer combien d’utilisateurs partagent le même problème. Si le problème n’est pas exactement le même pour tout le monde, il faut essayer d’en trouver une formulation commune qui permette de le généraliser.

Une fois le problème défini commence le processus de design, qui suit des étapes formelles pour éviter de se précipiter vers la première solution venue, et très probablement non optimale, parce que, encore une fois, l’intuition humaine est meilleure pour construire des tables de chevet que des outils utilisés par des milliers de personnes. Mais suivre le processus ne suffit pas.

La psychologie et les sciences cognitives convergent vers un consensus : la meilleure taille pour une équipe de travail se situe entre 4 et 7 membres. À partir de 8 membres, la productivité commence à chuter brutalement.⁴⁵⁶ Pour une équipe de 4 personnes, il existe 6 canaux de communication interpersonnelle, alors que pour 8 personnes, il y en a 28. Cela rend difficile, sur le plan cognitif, le suivi de toutes les personnes impliquées, de qui est responsable de quoi et le traitement des signaux non verbaux, ce qui crée une surcharge de communication. Au-delà de 9 membres, des clans commencent à se former, la politique s’immisce dans le processus et la paresse sociale  s’installe.⁴⁵

Cela signifie que le travail devrait être réparti en équipes ne comptant chacune pas plus de 6 à 7 membres, même si cela peut être stimulant pour l’ensemble de la communauté de s’intéresser à tout. Le point de bascule ici, c’est la communication : il en faut juste ce qu’il faut, ni plus ni moins, sinon elle sature cognitivement les membres de l’équipe et finit par gêner la communication elle-même. Et c’est alors le travail en tant que tel qui en pâtit.