L'ésoterisme du bazar, et la pomme empoisonnée démystifiée

L'ésotérisme du bazar, et la pomme empoisonnée démystifiée


Copyright (c) 2002 Nicolas Boiteux
Permission vous est donnée de copier, distribuer et/ou modifier ce document selon les termes de la Licence GNU Free Documentation License, Version 1.1 ou ultérieure publiée par la Free Software Foundation. Une copie de cette Licence est incluse dans la section GNU Free Documentation License.

Historique
Ce document a été écrit par Nicolas Boiteux le 04/07/2002, et corrigé par Jean-Claude Stiegler le 11/12/2002. La version originale est disponible à cette adresse.

Ce document étudie les mythes sur la commercialisation du logiciel libre. Je propose une analyse logique en me référant à deux ouvrages d'Eric Raymond, et explore quelques points occultés.

- la cathédrale et le bazar
- le chaudron magique

1 - Démystifier la communauté du logiciel libre

Le bazar tel que décrit par E.Raymond justifie la mystification du commerce autour du logiciel libre, et Open Source. Comme nous le verrons par la suite, les arcanes du mode bazar se construisent en même temps sur le secret et la transparence, et se concrétisent par le mythe de la pomme empoisonnée.

Pour aborder l'organisation d'une communauté, il faut en étudier le commun. Dans ce cas précis, il s'agit du logiciel libre.

Pour une meilleur compréhension du texte, je rappelle les critères reconnus par l'ensemble des membres de la communauté auxquels doit répondre un logiciel pour être libre :

- liberté d'exécuter un programme, pour n'importe quel but,
- liberté d'étudier le fonctionnement d'un programme et de l'adapter a vos besoins,
- liberté de redistribuer des copies,
- liberté d'améliorer un programme et de diffuser vos améliorations au public pour en faire bénéficier toute la communauté

La richesse de cette communauté provient de l'hétérogénéité de ses membres qui adhèrent, et se regroupent autour de ces principes communs, et ouverts du logiciel libre.

Chaque membre de la communauté peut donc être animé par des motivations différentes, accomplir ses objectifs (intellectuel, technique, culturel, lucratif, politique, éducatif, religieux...) , et contribuer au développement de la communauté en jouissant, et en véhiculant l'ensemble des libertés que leur confèrent les programmes à l'intérieur, et l'extérieur de cette communauté.

Le terme "Free" en anglais signifie "Gratuit" ou "libre". Tous les contributeurs s'entendent sur le fait que le terme Free ne signifie pas gratuit. Cette perception du logiciel libre hérite fortement de l'ésotérisme du bazar, que nous étudierons par la suite.

L'argument qui semble le plus tangible, et pertinent émane de la culture du logiciel libre, qui pense que l'aspect "gratuité" ne doit pas occulter les libertés cruciales que le programme confère aux contributeurs. Ces libertés fondamentales tissent les liens entre tous les contributeurs, et structurent la communauté.

Cependant, d'autres personnes, plus intéressées par l'aspect mercantile, préfèrent utiliser les termes open source pour lever l'ambiguïté. Mais, cela ne fait qu'accroître les incohérences autour du logiciel libre, en divisant une partie de la communauté, et en sous-entendant que la seule liberté d'avoir accès aux sources d'un programme, suffit à ce qu'un programme soit libre. Cela, induit également faussement qu'un programme libre est payant.

Par rapport au logiciel libre, les utilisateurs, les développeurs, les entreprises jouissent des mêmes libertés que le propriétaire du programme, qui conserve son droit de propriété. Ce concept postule qu'un logiciel libre pour délivrer ses libertés à tous les membres de la communauté est par essence gratuit. L'usage des termes open source ne se justifie donc pas (sauf quand on désigne une caractéristique du logiciel libre), pas plus que les termes de domaine public (qui signifient qu'il n'y a pas de propriétaire).

Nous parlons donc tout simplement de logiciel libre quand l'on évoque le libre, pour ne pas occulter l'aspect lucratif (distribution de logiciel libre, vente), l'aspect communautaire (don, partage), et propriétaire (le programme appartient à son auteur grâce au copyright et délègue des libertés aux contributeurs via le copyleft et la licence).

2 - La culture du don contre don, et la reconnaissance des pairs :

L'étude la communauté du logiciel libre, et Open Source, dans "le chaudron magique", se construit autour d'une relation de don multilatérale. L'acte de donner induit qu'en retour d'un don, le donateur devra lui aussi recevoir quelque chose.

Dans cette étude, E. Raymond explique qu'un contributeur en recevant la reconnaissance de ses pairs, augmentera son statut au sein de cette même communauté.

Cette relation, par rapport au gain, et conception culturelle, mercantile du don soulèvent de nombreuses questions sur la motivation des hackeurs.

Dans la vision d'E. Raymond, le don ne permet pas aux autres d'élever leur statut, mais d'élever et faire prévaloir son propre statut par rapport aux autres. Par induction, la qualité, la fiabilité, et l'ingéniosité des logiciels ne sont pas reconnus en tant que tel au sein de la communauté, tant qu'ils n'ont pas été approuvés par les pairs.

La culture du don sous cette forme atrophie le développement du logiciel libre, et exclut systématiquement des contributeurs qui adhèrent pourtant aux principes de la communauté.

De nombreux exemples, tels que la naissance de Linux ont démontré que la reconnaissance des pairs et la culture du don multilatéral n'étaient pas les motivations des hackeurs, et qu'elles n'étaient pas le moteur du développement du logiciel libre.

Jacques Derrida, philosophe contemporain a bouleversé l'éthique du don, en écrivant que le don pour être don doit échapper à toute logique. Conceptualiser le don, comme un échange "don contre don", en revient à le considérer comme une contraction de dette. Il ajoute, que le don ne peut être qu'inaperçu, des autres, de dieu, et de soi-même pour échapper à cette logique de rétribution.

Concevoir le don de telle façon, l'écarte de l'altruisme, et de l'égoïsme, qui dans les deux cas sont des logiques calculatrices. La communauté du logiciel libre est issue en partie de cette culture. De nombreux programmes sont utilisés sans reconnaissance, et sans que le don soit aperçu et pourtant ils contribuent au fonctionnement, et au développement de la communauté.

Cependant, quand la communauté grandit, elle se confronte à des phénomènes de régulation, et de hiérarchisation.

Des initiateurs de projets conservent leur pouvoir, pour contrôler le développement du programme sous l'autorité de principes extérieurs à ceux de la communauté, et jouir de la notériété en faisant valoir la logique du don contre don. Bien que ceux-ci puissent déléguer leur travail à des personnes de confiance, ils préfèrent mettre en avant des principes comme la sélection Darwinienne, ou d'intelligence formalisée.

Dans ce mode de pensée, la responsabilité engagée des développeurs à l'égard des utilisateurs est plus grande, quand le projet croît. Cela aboutit à des situations de non-sens, où l'on détermine des exigences qualitatives, la valeur d'un logiciel, proportionnellement au nombre d'utilisateurs.

Le concept de la culture du don, tel que le décrit E. Raymond s'intègre comme un régulateur dans une communauté d'organisation pyramidale. Le contributeur poursuit un but unique : la reconnaissance au sein de cette communauté, quantifié non pas par les valeurs intrinsèques du programme qu'il a réalisé, ou sa propre perception, mais par la part de responsabilité qu'engage l'utilisation de son programme au sein de cette communauté.

Cette description de la communauté du logiciel libre est réductrice, et ne sert qu'à défendre les intérêts de la pomme empoisonnée.

En réalité, la communauté du logiciel libre se structure simplement autour des principes de liberté du logiciel libre. A l'intérieur de celle-ci, s'exprime un melting-pot de différentes cultures, économie, ce qui rend l'analyse sociologique complexe, et qui ne peut trouver son entière explication dans un témoignage très précis de la culture du don. Dans cet ordre, le code source ouverte n'impose pas les dogmes des pairs à l'ensemble des contributeurs, mais incite à les améliorer, les modifier, et à les remettre en question si nécessaire. Des contributeurs assujettis à un dictat peuvent de leur plein gré, créer une nouvelle branche de programmes qui conviendra à leurs convictions, et jouir ainsi de leur liberté.

La description du mode bazar intègre plusieurs principes fortement hérités de la culture du logiciel propriétaire :
- une communauté hiérarchisée
- une culture du don, qui rend l'acte profitable
- la normalisation à la culture, en vue de la reconnaissance des pairs
- un développement dont le pouvoir de décision est centralisé


Le mythe du bazar siégerait-il au sein de la cathédrale ?

3 - La tragédie des communs

La fable de Hardin sur la tragédie des communs, nous interroge sur le droit de propriété et sur le mode coopératif de développement d'un programme libre.

extrait tiré de l'ouvrage "le chaudron magique chap 5" : " Hardin nous demande d'imaginer un pré, propriété collective d'un village de paysans, qui y font paître leur bétail. Mais les animaux dégradent les communs, en arrachant l'herbe et en laissant des portions boueuses derrière eux, qui ne recouvreront que lentement leur couverture végétale. En l'absence de politique consentie (et appliquée, fût-ce par la force) pour allouer des droits et des limites à chacun, l'intérêt de chacune des parties est d'y mener un maximum de têtes le plus vite possible, pour en extraire toute la valeur avant que les communs ne soient réduits à une mer de boue."

A cette fable, E. Raymond propose, par analogie fort douteuse où les herbes sont des programmes et le bétail des utilisateurs, trois issues :

- la quantité de programmes tend vers zéro, quand tous les utilisateurs utilisent tous les programmes sans politique d'attribution.
- Une personne usant de son pouvoir coercitif, alloue des domaines de développement au nom de la communauté, et les utilisateurs de programmes sont alloués dans chaque domaine.
- Chaque personne peut breveter son domaine, et le faire valoir auprès des autres. Les utilisateurs sont enfermés dans un domaine.

Aucune d'elles n'est valide dans le développement empirique du logiciel libre.

Selon E.Raymond, cette constatation trouve son explication, par le fait qu'un programme ne perd pas de valeur, quand il est utilisé. Et que plus un programme est utilisé, plus il a de la valeur.

Cette idéologie découle de sa conception sur la culture du don. Si un programme ne peut pas être vendu, en le donnant, il pourra générer indirectement une source de revenu, telle que la vente de produits propriétaire, de publicité etc [..]

Dans cette optique, la motivation du développement du logiciel libre est un mécanisme qui rend l'acte de don profitable. L'utilisateur quantifie par sa présence, la reconnaissance que doit recevoir le développeur par la communauté.

En fait, la fable de Hardin écarte la 4 ème issue, et la véritable problématique, en posant une question qui ne concerne pas le domaine des logiciels libres, mais la vente de logiciel propriétaire, et du support physique de ces logiciels :

Est-ce que l'on peut parler de raréfaction des biens à propos du logiciel libre ?

Reformulons le problème soulevé par la fable par analogie :
"Comme tous les utilisateurs ont accès à tous les programmes, ils peuvent utiliser comme bon leur semble les programmes. Mais il n'y aura plus de programmes quand ils auront utilisé tous les programmes."

Posé ainsi, le problème est absurde. Un programme ne peut se raréfier, car il a déjà été utilisé. Un programme ne s'use pas. Il y aura donc toujours autant de programmes quand les utilisateurs les auront utilisés, même si des utilisateurs plus pressés que d'autres se jettent dessus.

Comme cet exemple ne correspond pas au développement du logiciel libre, E. Raymond nous demande de transposer plutôt l'utilisateur comme un passager clandestin. La soute du bateau n'étant pas pleine, si il y a un passager clandestin cela n'entrave en rien le fonctionnement du bateau. Il est facile de comprendre que quand la soute du bateau est pleine, les passagers clandestins, n'ont plus de place, et ne peuvent plus voyager.

Des exemples maladroits comme celui-ci ne peuvent pas illustrer le développement du logiciel source libre, ni son utilisation.
Le débat sur le bien virtuel abondant a été abordé, et a convaincu il y a quelques années le peu d'exploitant de logiciel désireux de s'implanter en position de monopole de faire du code source fermé [..]

4 -Que protège le code source fermé ?

Le débat entre le logiciel libre, et propriétaire a dès le départ dépassé la dimension technique. Il n'y a pas de différence entre le même programme qui est compilé, et celui qui est sous forme de sources ouvertes. Débattre pendant des heures sur la qualité, la fiabilité, la sécurité d'un programme, ne fait que nier, ou remettre en cause les compétences des développeurs des différents modèles de développement.

Le code source fermé garantit avant tout l'exclusivité de l'exploitation du programme par son auteur, dont il est le seul à avoir accès aux méthodes de production. Sous sa forme compilée, le logiciel est un produit fini, périssable, destiné à une consommation immédiate, et ciblée. Dans la majeure partie des cas, il ne peut pas être copié, ou reproduit, et il peut être assujetti à des licences d'utilisation par ordinateur (achat de quinze licences, si vous avez quinze ordinateurs), ou des brevets.

Cela conduit à trois phénomènes :
- L'auteur jouit entièrement des bénéfices de l'exploitation du programme dont il est le propriétaire.
- L'utilisateur dépend totalement du logiciel propriétaire que seul l'auteur et propriétaire peut développer, réparer, modifier, distribuer.
- L'anéantissement de la concurrence.


L'usage d'un produit propriétaire se soumet donc aux :
- cycle de vie du produit,
- une économie d'échelle,
- les droits exclusifs d'exploitation par son propriétaire,
- son support physique.

Plus les utilisateurs sont nombreux, plus les coûts de production diminuent, plus les marges sur la vente du produit augmentent. Le ratio âge du programme/nombres d'utilisateurs permet de calculer la valeur financière d'un programme. Quand le nombre d'utilisateurs du programme tombe à zéro, le produit est arrivé en fin de vie, et n'a plus aucune valeur.

Dans le logiciel propriétaire, la dépendance à l'égard du produit est tellement importante, que lorsque celui-ci n'est plus vendu, il reste des utilisateurs que l'on pourrait qualifier de "collectionneurs emprisonnés". Ces utilisateurs ne peuvent pas changer de solutions, ils sont contraints de conserver les anciennes, en espérant être délivré (ce qui les amènent à adopter un logiciel libre).

Ces personnes payent le prix fort pour la maintenance d'un programme qui propriétairement ne vaut plus rien, et qui coûte souvent beaucoup d'argent à ses propriétaires.

L'industrie de l'informatique essuie le revers de la médaille du programme fermé qui devient trop coûteux à maintenir. Les programmes fermés tendent à imposer des standards, qu'ils abandonnent quand il n'y a plus de demande. Il faut alors faire appel à de la sous-traitance, et du personnel qualifié, pour maintenir une solution qui ne pourra que se dégrader du fait de son interportabilité, et voir son coût d'entretien augmenté.

Dans ce monde, le client doit consommer, remplacer régulièrement ses programmes, ses supports pour ne pas devenir un "collectionneur emprisonné". Ceci constitue le moteur financier de l'évolution de l'industrie informatique du logiciel propriétaire, et des supports physiques. Le client accorde sa confiance, et croit à tort, qu'en achetant un produit d'une grosse société celui-ci sera maintenu et standard.

Au contraire, les raisons qui peuvent mener à l'abandon total et rapide du produit par le propriétaire se multiplient :
La faillite de la société, rachat de la société, la rentabilité, les nouveaux standards propriétaires, la concurrence etc [..]

Selon cette logique, la vente de programme propriétaire sera rapidement remplacée par de la location, qui permettra de renouveler rapidement les programmes. Ce qui semble être le modèle le plus profitable, financièrement, économiquement pour les entreprises propriétaires, et pour le collectionneur emprisonné. Dès lors, le client peut s'engager sur des périodes déterminées avec des paiements de mensualités fixes.

Le programme libre diffère en tous ces points du logiciel propriétaire, le nombre d'utilisateurs n'affecte pas sa valeur, et n'interfère pas sur son développement. L'exploitation du programme n'est pas exclusive, car celui-ci peut être maintenu par n'importe quelle entreprise, ou contributeurs.

Un programme non compilé, n'est pas périssable contrairement à son support. Celui-ci peut être utilisé, transformé, et réutilisé, et n'est pas affecté par l'économie d'échelle.

"Un programme libre n'est donc pas par définition un produit, mais une matière première virtuelle abondante. L'élement rare, et la valeur est la spécificité qu'attend le contributeur du programme".

5 - Vers le système corporatif, et la réduction du coût de développement

Dans ce chapitre nous distinguerons deux éléments, le développement corporatif des entreprises, et le développement des contributeurs.

Le système corporatif permet à plusieurs entreprises qui poursuivent des buts différents, ou identiques, et qui ont besoin des mêmes outils de se réunir autour d'un même projet pour réduire leurs coûts de développement. La transparence du code source, permet à ces entreprises de clairement évaluer la progression du projet, des différents éléments à apporter ou à débattre, mais incite aussi d'autres entreprises à s'intégrer dans les phases de développement.

Nous sommes donc à la genèse d'un nouveau système de production, où le coût de développement se partage entre les différents intervenants, et permet avec des moyens beaucoup moins importants, de proposer des logiciels de grande qualité.

Maladroitement, il n'y a aucune différenciation entre les intérêts des entreprises, et ceux des contributeurs.

Des ouvrages élèvent des mythes, tels que celui-ci :

"les contributeurs, et les entreprises tendent vers les même intérêts, les contributeurs développent les produits des entreprises pour la simple reconnaissance de leurs pairs, et de la communauté."

Il ne faut pas se leurrer, une entreprise n'oeuvre pas pour la reconnaissance des pairs, ni celui de la communauté.

Il ne faut pas confondre les intérêts lucratifs d'une entreprise avec ceux qui ne le sont pas. Un contributeur peut contribuer au développement d'une société en lui fournissant des programmes tiers libres, mais il ne faut pas tomber sous le joug de l'exploitation en développant les programmes d'une société, dont elle sera la seule à jouir des bénéfices. Beaucoup de développeurs travaillent encore sur des produits d'entreprise sans être rémunérés, en pensant oeuvrer pour le bien de la communauté, et nient totalement par la même occasion les droits du travail, d'être rémunéré, la libre concurrence entre les entreprises.

Cela conduit à des abus, et finalement à oeuvrer contre la communauté en elle-même, en permettant à des sociétés de s'imposer avec un minimun de coût de main-d'oeuvre, et de production en position de monopole sur un marché.

En réalité, la contribution quand celle-ci n'est pas exploitée, devient garante de la libre concurrence, et du succès des entreprises. Les contributeurs développent des logiciels libres, et les entreprises contribuent à leur développement, si elles-mêmes désirent se développer.

La matière première non périssable, transformable, et abondante est accessible à tous, et contribue au développement de tous.

6 - Commercialisons du logiciel libre, l'union fait la force

Pour pouvoir discuter de la commercialisation du logiciel libre, il faut aborder des points douloureux, devenus tabous. Il faut tout d'abord prendre conscience que lutter contre le logiciel propriétaire, avec les méthodes du logiciel propriétaire, c'est développer le logiciel propriétaire au sein de la communauté du logiciel libre.

Grossièrement, il y a deux théories qui s'opposent :
- l'une qui tend à diminuer les inégalités entre une petite entreprise et une multinationale, et qui permet aux deux d'exploiter pleinement le marché ;
- l'autre qui tend à accroître les inégalités pour permettre à la multinationale d'absorber, et d'exploiter mal le marché de la petite.


Dans ce chapitre nous étudierons seulement la première des théories, la deuxième étant largement développée dans"le chaudron magique".

"Un produit doit répondre aux exigences de tous, un programme répond à des besoins spécifiques"

Le code source ouverte est l'un des principaux facteurs qui permet à toutes les petites entreprises de travailler ensemble, et d'exploiter leur marché en servant les intérêts spécifiques de leurs clients. Le code source ouverte, est l'axiome de l'interportabilité, de la transportabilité, et de l'adaptation.

Les logiciels à distribuer, vente de services :
Concrètement, une petite entreprise a un panel énorme de logiciels à sa disposition, qu'elle peut proposer aux clients via la vente de service, mais aussi à la vente, et assemblage de machine, de matériel, ou par simple contribution. Elle peut déterminer ses prix, se montrer compétitive, coller aux spécificités du marché, et l'aider à se développer.

Logiciel qui répond à un besoin spécifique :
L'entreprise peut modifier un logiciel libre déjà existant pour qu'il réponde mieux aux besoins du client. Les corrections, améliorations du logiciel peuvent être facturées au client, et renvoyées à l'auteur du programme, en signe de contribution, mais peuvent être aussi encouragées sous forme de rétributions financières, matérielles (en quelque sorte une prime d'intéressement).

Développement :
Bien plus, encore une entreprise peut développer un logiciel spécifique pour son client, facturer le coût de développement, le client en devient alors le propriétaire. L'entreprise peut proposer au client de diffuser le logiciel en tant que logiciel libre. Les avantages pour le client, et l'entreprise sont multiples.

D'une part, cela évite d'avoir à redévelopper entièrement un programme pour un autre client, cela permet à d'autres entreprises d'exploiter le programme, et d'apporter leurs améliorations, voire de contribuer financièrement en rétribuant le client.

L'entreprise pourra toujours vendre le développement d'une nouvelle extension de programme libre qui répondra à un besoin spécifique pour un autre client, et dont le premier client pourra bénéficier sous forme de contribution par la même occasion.

Le client peut utiliser autant de fois qu'il le souhaite, et redistribuer son programme sans restriction de licence.

Ainsi, "le pot commun" tend à se développer. Les petites entreprises gagnent de l'argent, en assurant le développement de nouvelles extensions, ou en distribuant et maintenant du logiciel libre. Le client a participé au développement d'une partie du programme libre, ou est propriétaire de l'intégralité du programme, qui répond à ses besoins spécifiques.

Les clients sont libérés des contraintes liées aux cycles de vie d'un produit, de la dépendance envers les entreprises.

Les grosses entreprises jouent le même rôle que les petites à une autre échelle, en les consolidant , elles peuvent délivrer aux petites entreprises des logiciels libres, ou vendre à un groupe de plusieurs entreprises une application, ou des outils de développement libre que les entreprises rétribueront pour les faire évoluer.

7 - le développement du logiciel libre dans l'avenir

Le développement du logiciel libre bouleverse l'organisation de l'industrie de l'informatique. Les contributeurs ne sont plus en compétition entre eux, mais "compétitionnent" ensemble contre des challenges techniques. Chaque entreprise en distribuant ce type de logiciel, peut exploiter mieux son marché, et rétribuer les projets audacieux qui lui permettront de se développer.

Les agents économiques ne suscitent plus des besoins, mais répondent aux besoins de leurs clients. Les clients ne sont plus des locataires de logiciel propriétaire mais des propriétaires de logiciel libre.

Pourquoi une entreprise devrait vendre des produits d'une société qui à plus ou moins longue échéance, détruira son commerce ?

Un client a-t-il des raisons d'acheter un produit qui ne le satisfait pas pleinement, et qui deviendra rapidement obsolète ?

Depuis 1998, de grosses sociétés évaluent l'impact de Linux, et des composants Gnu sur leurs parts de marché. Celles-ci tentent d'imposer, et de mystifier la commercialisation du logiciel libre, dans une lutte de pouvoir, et de monopole en éloignant les petites entreprises de la distribution des programmes libres, et en faisant participer les contributeurs au développement de leurs produits.

La culture du logiciel propriétaire ne peut pas s'appliquer au logiciel libre.

Pire encore, ces sociétés n'ayant que peu d'emprise sur les logiciels libres, tentent d'imposer de nouveaux standards, parallèlement à ces logiciels pour que les utilisateurs soient à nouveau dépendants de leurs produits, et raréfient la matière première par le biais du support. Les états qui voient en elles des armes économiques internationales encouragent à tort le développement de ces solutions, au détriment du développement du commerce local, et des emplois.

La vente de programmes, et de méthodes propriétaires sous la dénomination de logiciel source ouverte fluctuent, mais à terme sans doute, s'épuiseront car celles-ci doivent se conformer à l'économie d'échelles, et subir le contrecoup de leur structure.

Les investissements engagés restent disproportionnés par rapport à la taille des marchés, qui ne peuvent être exploités que localement. Cela est potentiellement inquiétant, car la grosse industrie informatique se fragilise, tandis que la petite ne se développe pas.

Conclusion

J'espère que ce document aura soulevé des questions judicieuses sur la commercialisation, et le développement du logiciel libre, et contribuera à une plus grande compréhension de l'ésotérisme du bazar par les non initiés.
Il me semblait important de démystifier la pomme empoisonnée, qui ne pouvait que nuire à la perception du logiciel libre.
Nicolas

"Sous l'apparence d'un fruit rare et juteux, se cachait le pire des poisons, une pomme empoisonnée."