Quelques réflexions dans divers domaines qui m’intéressent
Cliquez sur le type votre communauté (ou le type de communauté que vous souhaiteriez créer) et téléchargez un document de 40 pages avec des questions et des conseils (un peu comme les livres dont vous êtes le héros) :
Bonjour et bienvenue sur ce site.Vous y trouverez quelques réflexions dans des domaines très variés tels que la coopération, Internet, la complexité, l’économie, etc. Tous ces sujets peuvent sembler bien distincts mais ils se croisent parfois pour apporter des éclairages nouveaux et intéressants. Je vais transférer progressivement les contenus déjà existants de mon site et de mon Wiki.
Paradoxe : La loi de Brooks
Dans le cadre des projets de développement logiciels, la difficulté de faire travailler un grand nombre de personne sur un même projet est appelée la loi de Brooks [BRO] : » Le fait d’ajouter des gens à un projet logiciel en retard, le retarde encore d’avantage « . Plus précisément, si le travail réalisé est plus ou moins proportionnel au nombre de personnes impliquées, la complexité augmente, quant à elle, comme le nombre d’échanges et donc comme le carré du nombre de personnes. Cela est du au fait que les liens entre les différents acteurs augmentent bien plus vite que le nombre des acteurs.
La loi de Brooks ne s’applique plus si les liens ne sont pas critiques
Une solution semble avoir été trouvée dans le cas du logiciel libre avec le développement de logiciels complexes sur une base très différente. Cette solution est décrite très en détail par Eric S. Raymond dans » La Cathédrale et le Bazar » [RAY1]. Suivons la chaîne de développement d’un produit pour comprendre ce qui permet de sortir de la loi de Brooks. Une fois la première version mise sur le marché, les corrections et améliorations se font en trois étapes :
Le lien qui s’établit entre les divers contributeurs est l’aspect clé. Le développement des liens est une très bonne chose pour développer la confiance entre les membres et l’émergence d’un esprit de communauté. Mais ces liens ne doivent absolument pas être critiques. Si le travail est parallélisé plutôt qu’en séquence, alors la défaillance d’une personne n’entraîne pas de conséquence sur le travail des autres. Chaque contributeur doit envoyer sa contribution directement au coordinateur qui choisi alors de l’intégrer ou non. Ainsi la complexité s’établit comme le nombre de personnes et non comme le nombre de liens comme le décrit la loi de Brooks.
Contrairement aux apparences, le coordinateur risque moins d’être submergé s’il doit intégrer chaque contribution que s’il doit intervenir sur les liens opérationnels entre les tâches réalisées par les différents contributeurs. D’une part, il y a généralement beaucoup moins de contributions que de membres de la communauté. D’autre part, même si 10% des liens entre les tâches étaient à suivre (les problèmes sont en général bien plus nombreux dans la réalité), ce nombre devient plus grand que le nombre de tâches dès qu’il y a plus de dix contributions !
| L’exemple de l’Internet Fiesta |
| Dans l’Internet Fiesta 2000 [INT], nous avions prévu au départ d’assurer 3 jours non-stop d’émission de télévision sur Internet pour mettre en valeur tous les événements réalisés dans le monde. Cela laissait peu le droit à l’erreur : Un trou dans la grille et nous n’aurions pas rempli nos objectifs. Un participant défaillant suffit à faire échouer le projet. Finalement, nous avons opté pour une formule où nous avons mis en ligne le plus possible de vidéos présentant les événements. A certains moments, il n’y avait rien et à d’autres des personnes travaillaient sur plusieurs émissions en même temps. Dans ce cas, personne n’est indispensable. Certaines émissions n’ont pas abouti mais toute personne qui a apporté un programme vidéo supplémentaire a enrichi le projet… et a gagné en estime en fonction de la qualité de ce qu’il a apporté. Pour que le projet réussisse, il suffisait qu’un certain nombre d’émissions aboutissent, sans qu’aucune ne soit critique pour le projet. |
Première Règle : Des contributions courtes, simples et autonomes
Le premier critère est d’avoir des tâches parallélisables pour que les contributeurs puissent s’impliquer sur des tâches les plus courtes possibles sans imposer de liens entre elles. En fait, il s’agit bien plus souvent qu’on ne le pense d’une façon de découper le projet que du type de projet lui-même. Les tâches courtes avec un résultat clairement identifié sont bien plus adaptées aux projets coopératifs : un ensemble de documents courts (FAQ, check-lists, listes de liens) sera obtenu plus facilement qu’un rapport monolithique sur le même sujet. Si la façon de réaliser le projet est déjà prédéfini, elle risque non seulement de tuer les opportunités, mais également d’ajouter des contraintes pas forcément utiles pour le projet.
Plus les tâches sur lesquelles les utilisateurs pourront contribuer seront petites, courtes, simples et autonomes, plus il leur sera facile de s’impliquer. Pour prendre une comparaison avec les techniques informatiques, il faut passer d’une programmation monolithique à une programmation objet.
Deuxième règle : le seul lien opérationnel est avec le coordinateur
Pour éviter de subir la loi de Brooks, il faut que les tâches ne soient pas liées entre elles. Le coordinateur doit dans ce cas être le point central qui intègre chaque contribution autonome.
Cela ne veut pas dire qu’il ne doit pas y avoir de lien entre les contributeurs. Mais ceux-ci ne doivent pas être ceux d’une chaîne de tâches à accomplir comme Taylor l’a proposé. Les liens doivent plutôt se développer autour de l’émulation sur les idées et le développement des sentiments d’appartenance et de confiance qui renforcent la communauté.
En d’autres termes, il s’agit de remplacer une chaîne fragile comme le plus faible de ses maillons, par une corde solide comme la somme de ses brins les plus solides.
Cela peut sembler étonnant de proposer une telle centralisation dans une approche distribuée et coopérative. Mais la véritable décentralisation n’est pas dans le projet lui même mais dans la multiplication des projets et la possibilité de participer à plusieurs d’entre eux.
| Exemple : Les ordinateurs s’y mettent aussi |
| En informatique, nous dirions que plutôt que de remplacer un serveur centralisé unique par un ensemble d’ordinateurs personnels, la méthode la plus efficace est de le remplacer par un réseau permettant d’accéder à tous les serveurs imaginables. Les nouvelles architectures « peer to peer » utilisées par Napster, Gnutella ou le projet freenet ne suppriment pas les serveurs, au contraire, elles rendent chaque machine serveur pour d’autres, chacun pouvant choisir ses propres serveurs. Ce n’est pas la fin des serveurs mais leur multiplication qui caractérise les systèmes distribués. |
Troisième règle : Réduire le nombre de tâches critiques et les conserver
Pour rendre un projet le plus résistant possible, il faut non seulement que les contributeurs effectuent des petites tâches autonomes pour les soumettre directement au coordinateur, mais il faut également qu’aucune de ces tâches prises individuellement ne soit critique pour le projet.
Si le coordinateur dispose pour développer son projet d’un très grand nombre de personnes, les statistiques jouent en sa faveur et de bonnes idées auront toutes les chances d’en émerger. Mais toute tâche critique devient alors un maillon sensible du projet.
Il est presque toujours possible de réduire le nombre de tâches critiques d’un projet en le réorganisant, comme cela a été le cas dans l’exemple de l’Internet Fiesta 2000. L’art du coordinateur du projet est justement de savoir réduire au minimum ces tâches. Il devra ensuite en conserver la maîtrise.
Ainsi la grande différence entre le coordinateur et les contributeurs d’un projet est que le coordinateur exécute les quelques tâches critiques qui mettraient le projet en péril si elles étaient mal faites alors que les contributeurs effectuent un grand nombre de tâches non critiques qui démultiplient et enrichissent le projet.
Quatrième Règle : Le projet doit se suffire d’un minimum de contributions
Le système doit être le plus résistant possible à la non-coopération. Plutôt que d’espérer que 100 % des utilisateurs seront des contributeurs actifs, faites en sorte que le minimum indispensable soit le plus bas possible.
Par exemple les mécanismes de votes classiques peuvent être pervertis si le taux d’abstention est grand ou si les votants sont faiblement informés. Dans les techniques du « rough consensus » [IET], au contraire, tout le monde reçoit l’information, mais seuls ceux qui sont fortement opposés s’expriment. Le projet s’affine jusqu’à ce que plus personne ne s’oppose. On atteint alors un consensus approximatif suffisamment acceptable pour tous. Dans ce cas, l’abstention n’est pas un inconvénient mais une position qui signifie « je ne m’oppose pas au choix tel qu’il est proposé ».
Pour garantir de bonnes chances de succès, considérez toujours qu’il suffit d’un minimum de personnes qui contribuent. Ce minimum critique doit être facilement atteint (éventuellement juste le coordinateur pourrait suffire). Tout contributeur supplémentaire sera alors un plus pour le projet.
|
Les tâches confiées au contributeurs doivent être autonomes et non critiques pour sortir du cadre de la loi de Brooks, minimiser les risques pour le projet et maximiser les effets démultiplicateurs.
|
L’autorisation a priori
Dans l’économie d’échange traditionnelle, le droit d’usage et éventuellement le droit de modification s’obtiennent par un achat d’un produit ou par une demande d’autorisation préalable (dans le cas du droit d’auteur par exemple). Dans un système coopératif, nous souhaitons que les utilisateurs puissent le plus facilement possible devenir contributeurs pour proposer des améliorations sur un produit.
Une solution a été proposée dans les années 1980 par Richard M. Stallman, dans le cadre du logiciel. Il s’agit de donner » a priori » l’autorisation d’utiliser et de modifier un programme grâce à une licence : La Licence Publique Générale GNU [GNU]. Le fait que le propriétaire des droits donne » a priori » l’autorisation d’utiliser et même de modifier un produit simplifie grandement sa réutilisation et l’émergence de contributeurs venus de partout. Les modèles économiques utilisés pour ces logiciels « libres » sont ceux dont nous avons parlé avec des besoins différents pour le distributeur, le coordinateur ou les contributeurs.
Le mouvement « Open Source »
Il existe de nombreuses licences pour les produits » libres « . Devant certaines déviations de l’idée de base, un mouvement s’est mis en place pour définir le concept de » source ouvert « . Un des aspects les plus importants du logiciel libre est de permettre de faire soi même des modifications, ce n’est pas la possibilité de l’obtenir gratuitement (ce qui n’est d’ailleurs pas toujours le cas). Pour faciliter les modifications, le logiciel est fourni non seulement avec une licence mais également avec » le texte source » qui décrit dans un langage compréhensible par un humain les instructions destinées à la machine. La Définition de l’ » Open Source » [OPE], recense trois grands critères sur les droits qu’une licence doit octroyer à un utilisateur :
L’invention du « copyleft »
La solution proposée utilise le droit d’auteur pour simplifier les échanges (ou la notion de copyright aux Etats-Unis) : Le propriétaire d’une oeuvre peut choisir à qui il donne des droits et peut même décider a priori qu’il donne certains droits à tout le monde et l’inscrire dans un document qui est joint à l’oeuvre. Cette approche est parfois nommée par un jeu de mot : » copyleft » ou » gauche d’auteur « .
L’utilisateur n’a besoin de faire aucune démarche pour obtenir ces droits. Il est donc aisé même pour une petite société ou un particulier de récupérer un produit libre (souvent disponible en ligne ou dans des CD ROM distribués avec les revues). Il peut l’utiliser et éventuellement au fur et à mesure qu’il acquiert du savoir-faire, devenir contributeur.
Le danger de la scission en de multiples versions
Eric S. Raymond [RAY2], a noté que ces licences posaient cependant un problème particulier. Toute personne pouvant modifier et redistribuer un produit libre, le nombre de versions concurrentes devrait exploser. Les utilisateurs-contributeurs devraient alors faire des choix difficiles et beaucoup de développements ultérieurs devraient être réalisés en double. Le coordinateur initial se sentirait lésé car, même s’il a souhaité ouvrir au maximum son produit, la reconnaissance se dilue dans le nombre de versions. Deux orientations permettent de résoudre ce problème :
Que faire d’une version que l’on a modifiée ?
Toute la question tourne autour de l’association de deux des droits accordés par les licences : Le droit de modification et le droit de redistribution. Combinés ensembles, ils peuvent mener à la scission. En fait, il existe trois types de gestion des modifications :
C’est cette dernière option qui pose problème. L’usage développé en particulier dans le domaine du logiciel libre rend » tabou » les modifications nuisibles et les scissions sans les empêcher totalement. Ne permettre que les scissions » nuisibles » indispensables est un domaine qui nécessitera sans doute d’autres réflexions pour éviter les déviations.
Les brevets
La problématique des brevets est assez proche. A l’origine, la notion de brevet a été créée pour inciter les inventeurs à publier leurs découvertes plutôt qu’à les cacher. En contrepartie, les propriétaires de brevets touchaient des droits sur l’utilisation de leur invention pendant une durée limitée. Cette notion a connu des déviations en particulier aux Etats-Unis. Les grosses sociétés déposent un très grand nombre de brevets parfois sur des mécanismes de base évidents. Il devient alors impossible de développer un produit sans violer un ou plusieurs brevets. Les grandes sociétés se violant mutuellement les brevets, elles signent alors des accords de réciprocité à grand renfort de services juridiques. Il n’en va pas de même des petites sociétés ou même des individus qui voudraient devenir contributeurs ou coordinateurs.
Le système des brevets tel qu’il est souvent appliqué réduit le nombre des acteurs possibles à quelques grosses sociétés. Cela va à l’encontre de la multiplication des contributeurs et même de la multiplication des projets conduits par des coordinateurs. Le brevet, créé pour diffuser le savoir humain comporte aujourd’hui le risque de tuer les projets coopératifs. L’Europe débat actuellement de la possibilité d’élargir sa notion plus stricte des brevets pour rejoindre l’orientation prise par les Etats-Unis. Des mouvements tels que freepatents.org cherchent à conserver la liberté des utilisateurs et la multiplicité des acteurs [FRE].
Que veut dire être propriétaire ?
Le coordinateur est » propriétaire » de son projet car il est normalement le seul à avoir le droit de redistribuer les versions modifiées. Bien que la notion de propriété existe, elle est très différente de celle que nous avons vue dans la » tragédie des biens communs » [HAR]. Une des différences majeures est que les autres personnes peuvent utiliser sans limite les ressources proposées. Chacun peut ainsi aller dans autant de propriétés qu’il le souhaite profiter de leurs avantages. La richesse du coordinateur n’est pas dans le projet lui-même mais dans les utilisateurs qu’il attire et la reconnaissance qu’il reçoit d’eux. Le coordinateur-propriétaire impose sa loi uniquement sur les évolutions, non sur l’utilisation.
Attirer l’attention vaut mieux que ce que l’on possède dans une économie d’abondance
Bruce Sterling décrit dans » Libre comme l’air, libre comme l’eau, libre comme la connaissance » [STE], un des textes fondateurs du logiciel libre, la relative importance de la propriété : » Le point crucial c’est l’accès, pas la propriété. Et ce n’est en vérité pas l’accès lui-même, mais les indications qui disent à quoi il faut accéder, à quoi il vous faut prêter attention. Dans l’économie de l’information, tout est surabondant sauf l’attention « .
Pour un propriétaire de projet, attirer l’attention sur lui peut se faire par une promotion lourde ou par le bouche à oreille et la reconnaissance des autres, mais si son projet est ouvert et permet facilement d’entrer et de sortir de sa » propriété « , il ne pourra conserver ses utilisateurs et ses contributeurs que s’ils y trouvent ce qu’ils recherchent.
A la conquête de nouveaux territoires
Eric S. Raymond [RAY3] nomme ce territoire des « projets possibles » où chacun peut prendre un morceau de propriété » l’ergosphère « . Il est différent de l’espace des idées appelé la » Noosphère » par Teillard de Chardin, où la propriété n’existe pas. Plusieurs projets peuvent se construire sur une même idée. En fait ce territoire des projets ressemble plus au cyberespace où des personnes s’approprient des morceaux de territoire dans un espace sans limites.
Eric S. Raymond décrit trois façons de devenir propriétaire d’un projet. Sa vision est très orientée vers la notion anglo-américaine lockéenne de conquête de la propriété (celle que l’on retrouve dans la « conquête vers l’Ouest ») :
L’objectif, en obtenant la légitimité de la coordination d’un projet, est de réduire les sources de conflit et de maximiser la coopération.
Quel nouveau projet lancer ?
Il existe deux cas de figure pour choisir un nouveau projet :
|
Un propriétaire peut choisir à qui il donne les droits d’usage, de modification et de redistribution
Le coordinateur d’un projet en est propriétaire, mais cela ne lui donne l’exclusivité que du droit de rediffuser les versions modifiées. Sa véritable richesse est dans les utilisateurs et contributeurs qu’il attire. Les différentes façons de devenir propriétaire d’un projet sont :
|
« > 4 commentaires | Lu 7881 fois |
