Equipotentialité

= principe de base qui sous-tend l'émergence d'une dynamique sociale de pair à pair

Définition et commentaire

Michel Bauwens : selon moi, les processus de production par les pairs sont caractérisés par l'adoption de l'équipotentialité comme principe d'organisation. Cela signifie que chacun peut potentiellement coopérer à un projet, qu'aucune autorité ne peut préjuger de la capacité à coopérer, mais que la qualité de la coopération est alors jugée par la communauté de pairs, c'est-à-dire par une Validation Communautaire. Dans les projets équipotentiels, les participants s'auto-sélectionnent eux-mêmes pour le module auquel ils se sentent capables de contribuer. Un terme connexe, utilisé par Jimmy Wales du projet Wikipedia, est "Anti-Crédentialisme", qui fait référence au fait qu'aucune accréditation n'est demandée à l'avance, contrairement au processus d'examen par les pairs.

Pourquoi l'autosélection équipotentielle fonctionne ?

Charles Leadbeater, dans We Think résume l'explication de Yochai Benkler :

"L'explication de Benkler sur la façon dont les communautés open source se coordonnent fonctionne comme ceci. La matière première de ces collaborations est le talent créatif. Mais le talent créatif est très variable. Les gens sont bons à différentes choses et de différentes façons. Il est très difficile de dire de l'extérieur qui est le travailleur créatif le plus efficace. Il est très difficile de rédiger des descriptions de poste et des contrats détaillés pour la créativité, en précisant quelles nouvelles idées doivent être créées et à quel moment. La créativité ne peut pas être livrée "à la demande".

Les communautés open source résolvent les difficultés d'évaluation de la créativité et de la qualité en décentralisant la prise de décision vers les individus et les petits groupes. Ils décident sur quoi travailler, en fonction de ce qui doit être fait et de leurs compétences. Il y a peu de sens à travailler sur un projet qui est déjà bien doté en participants et où votre contribution n'ajoutera pas grand-chose. Il est très difficile de leurrer vos pairs : ils remarqueront vite si les contributions que vous faites ne sont pas vraiment à la hauteur. Cela permet aux gens de ne travailler que sur une partie du puzzle.

De bonnes règles de conception centrale permettent d'additionner le tout. Le travail dans les communautés open source se fait lorsque les personnes créatives se répartissent elles-mêmes les différentes tâches, soumettent leur travail à un examen ouvert par les pairs pour maintenir la qualité, et le produit a une conception modulaire de sorte que les contributions individuelles peuvent être assemblées ensemble facilement." (http://wethink.wikia.com/wiki/Chapter_8_part_3)

Exemples de pratiques équipotentielles

Les projets diffèrent également en ce qui concerne les membres, et le degré d'adhésion au sein d'un projet donné peut également varier. Outre les fonctions officiellement attribuées, comme être membre de l'équipe de base ou mainteneur, l'accès en écriture aux systèmes de gestion du code source (SCM) est une caractéristique distinctive, car il permet aux contributeurs de travailler de manière autonome. Les projets traitent l'octroi de ces droits de manière très différente.

Debian exige la réussite d'une série de tests pour prouver la capacité technique mais aussi pour montrer l'adhésion au contrat social Debian - une sorte de charte constitutionnelle du projet qui a beaucoup à dire sur la liberté du logiciel. Ce n'est que lorsque ces tests ont été passés avec succès - ce qui peut prendre un mois ou plus d'un an - qu'un statut officiel de développeur Debian est attribué. Cette forme d'admission - qui est à la limite d'un processus formel d'initiation - semble plutôt unique..... On suppose généralement que l'attribution et la répartition des postes sont fondées sur la réputation. Une telle réputation, cependant, n'est pas seulement acquise de façon méritocratique en écrivant un bon code ; l'idée d'anciens (où le fondateur du projet est assigné d'une manière ou d'une autre le rôle de leader) est également très importante.

Les structures organisationnelles des projets FLOSS ne sont pas conçues à la planche à dessin ; elles sont le fruit du hasard, des conventions ("c'est ce qui se fait dans les projets FLOSS") et de la négociation.