title: Communs négatifs slug: communs-negatifs date: 2018-06-25 chapo: Analyse à la lumière de l’Open-Source. lang: fr
Summary in English

Some thoughts about negative commons and Open-Source.

> Dans un premier sens, les « communs négatifs » désigneraient donc l’action de prendre soin d’une ressource « négative », ce qui provoque déjà en soi un élargissement par rapport à la théorie classique des Communs (les Commons Pool Resources d’Elinor Ostrom étaient toutes des ressources positives). Mais avec le Zéro Déchet, il me semble que le sens des « communs négatifs » va plus loin encore, car il ne s’agit plus seulement de prendre en charge des ressources négatives, mais carrément de ne plus considérer les déchets comme des ressources potentielles, en évitant qu’ils soient produits à la source. **Il s’agit donc pour les groupes humains de s’organiser pour éviter qu’une chose devienne une ressource, ce qui tranche fortement par rapport à l’approche traditionnelle des Communs.** > > *[Le Zéro Déchet et l’émergence des « Communs négatifs »](https://scinfolex.com/2018/06/10/le-zero-dechet-et-lemergence-des-communs-negatifs/)* ([cache](/david/cache/89521732caf2c8f2e20e55429c397337/)) Je voudrais revenir sur cette notion importante de *commun négatif* à la lumière de ce que j’ai pu constater dans les communautés produisant de l’Open-Source. ## Chronologie Premièrement, il faut bien voir que ces communs négatifs sont rarement pensés comme étant des communs *avant* de devenir négatifs. Dans le cadre d’un projet Open-Source, il s’agit bien souvent de l’initiative d’une seule personne qui se résout à proposer une gouvernance/maintenance réellement commune une fois débordée par son propre produit. L’informatique ne fait encore une fois qu’accélérer et étendre un phénomène qui est comparable à l’exemple sus-cité de la centrale nucléaire : initialement construite par un exploitant puis « transmise » à la communauté faute de pouvoir gérer sa maintenance à long terme. Ainsi **ces communs ont la particularité d’être victime de leur propre toxicité** de par la rapidité de leur obsolescence mais aussi de la perte brutale de valeur en raison des externalités nocives qui leurs sont associées. Je ne suis pas sûr que la clé soit d’*« éviter qu’une chose devienne une ressource »* mais plutôt de miser sur des objets techniques éprouvés tout en réduisant le périmètre de production et les dépendances associées. C’est par exemple ce que l’on tente de faire avec les [pyrates](https://github.com/pyrates) en envisageant notamment le code en tant que commun dès le début afin de conserver sa polarité positive. Ou au moins essayer. ## Popularité Un produit Open-Source devient généralement anxiogène lorsqu’il dépasse une certaine popularité, la masse critique faisant alors peser de tout son poids la responsabilité induite sur cette dépendance. De la même manière qu’une centrale nucléaire est trop puissante pour être contrôlée, on en arrive à tenter de **résorber la culpabilité associée à un outil en s’appuyant sur la communauté** pour qu’elle s’en sorte par elle-même. Il y a aussi une transition de la posture de l’égo : de « c’est *moi* qui l’ai fait » à « *nous* devons me protéger de ma propre création ». Il y a ici une acceptation, quasiment un deuil, à faire vis-à-vis d’une création auto-destructive. Je ne sais pas quels garde-fous sont à mettre en place pour se protéger d’un passage à l’échelle qui inverse la polarité du commun. Il est probable qu’en limitant le périmètre et en étant explicite sur ce qui ne sera pas fait cela stimulerait l’essaimage (?) ## Relationnel Enfin, les communs négatifs semblent être des catalyseurs de conflits car ils sont chargés d’une dimension affective. Les relations initialement positives laissent progressivement place à des ressentis négatifs faute de communication transparente. **Les intervenants évoluent au cours de la vie du produit**, leurs affinités avec la problématique, leur compréhension des impacts de ce qui est produit, leurs objectifs personnels, tout change sans que cela soit forcément explicitement documenté. La personne qui a fait le coffrage du réacteur nucléaire il y a 30 ans n’avait probablement pas conscience des conséquences de ses actes. Vieillir, c’est se retenir de juger le passé car on l’a vécu. Et que l’on doit continuer à (sur)vivre avec cette culpabilité. Comment éviter de transformer un commun négatif en lynchage public ? ## Évitement J’ai exploré plusieurs pistes pour éviter la toxicité d’un commun négatif sous forme de code : 1. *Ne plus rien publier.* C’est assez radical mais c’est extrêmement reposant. Il y a néanmoins la frustration de ne pas publier du code qui pourrait être utile à d’autres (comme ce site). 2. *Participer ponctuellement ailleurs.* Avec le sentiment de papillonner d’un côté et d’être utile de l’autre. Ce n’est pas totalement satisfaisant car il manque l’euphorie de la création initiale. 3. *Au nom du collectif.* Que ce soit [Etalab](https://github.com/etalab/), [OpenDataTeam](https://github.com/opendatateam/) ou [BetaGouv](https://github.com/betagouv/), cela permet de se protéger des attaques personnelles. La responsabilité diluée ne permet pas de prendre soin de tous les projets par contre. Mes pistes actuelles se situent du côté des [pyrates](https://github.com/pyrates) et aussi de ce que l’on pourrait mettre en place avec [Agile France](http://agile-france.org/) mais je manque de recul pour en parler davantage. **L’enjeu d’une approche positive ET soutenable est loin d’être anodin car il remet en perspective le pourquoi d’une mise en commun.** De nombreux communs périclitent et continuent de consommer de l’énergie faute de prise de recul et de franchise suffisantes pour rebondir dans d’autres directions. C’est peut-être l’enjeu derrière ces communs négatifs : comment se donner les moyens de mettre un terme à un commun ? *Note : je parle intentionnellement d’Open-Source ici et non de Logiciel Libre, la dimension politique/éthique ne me semblant pas aussi formelle dans le cadre d’un commun j’ai préféré réduire au périmètre explicite.*