La cathédrale, le bazar et le conseil municipal

Auteur : Alan Cox
Traducteurs : Géraud Canet & Emmanuel Fleury
Édition : Sébastien Blondeel

octobre 1998


Ce document contient certaines de mes réflexions à propos du modèle du bazar qui, à mon sens, valent la peine d'être partagées. C'est aussi un guide qui explique comment faire capoter complètement un projet de logiciel libre. J'ai choisi un exemple classique de ce que l'on pourrait appeler l'exemple du « conseil municipal » (bien que les conseillers municipaux puissent penser différemment).

1. La vie, les développeurs et le reste

Il faut savoir certaines choses à propos des développeurs. La première est que les excellents programmeurs sont rares. Mais en plus de cela, la différence entre un « vrai programmeur » et la masse des autres est beaucoup plus grande que l'écart entre les « excellents » et les « moyens » dans de nombreuses autres professions. Des études font ressortir un rapport de 30 à 1 entre la productivité des meilleurs programmeurs et celle des autres.

Vous devez comprendre, en deuxième lieu, qu'un grand nombre de programmeurs débutants sont très forts en gueule. La plupart d'entre eux contractent la maladie de la technophilie galopante, ou bien considèrent leur spécialité comme la « seule solution envisageable ». Sur l'Internet le blabla abonde.

La troisième partie de tout projet de programmation est ce que l'on appelle « la masse ». Cela va de l'utilisateur non programmeur mais qui contribue massivement dans d'autres domaines - documentation, aide aux utilisateurs et esthétique, à ceux qui pensent qu'il faudrait rendre obligatoire une sorte de permis de se connecter à l'Internet.

2. Un projet ambitieux

Le projet dont je tire mon exemple de capotage se proposait de réaliser une version de Linux destinée aux processeurs 8086. Porter un sous-ensemble de Linux sur un 8086 est l'un des exercices les plus inintéressants qui soit ; c'est aussi une idée qui avait commencé comme une plaisanterie et qui était finalement sur le point de se concrétiser.

Il existe un très petit nombre de vrais programmeurs qui ont à la fois le temps et l'esprit correctement tourné (ou suffisamment tordu) pour contribuer à un projet dont la seule valeur réelle est l'art du code. Le projet rassemble donc, à tout moment, deux ou trois contributeurs assidus.

3. Un départ difficile

Malheureusement, un grand nombre de gens pensèrent que faire tourner Linux sur un 8086 serait sympa et se sentirent obligés de « prendre part » au projet. La plupart d'entre eux, dans ce cas, appartenaient à la catégorie des programmeurs débutants, alors que la masse se tenait à l'écart du projet en arguant de son côté « stupide ».

L'arrivée d'un grand nombre de personnes (pour la plupart de bonne volonté) dangereusement incompétentes mais productrices d'opinions - pas de code, mais bien d'opinions - posa un problème. Ils en savaient assez pour conseiller comment cela devait être écrit mais la plupart n'avaient jamais réalisé un programme « hello world » en C. Ils commencèrent à discuter pendant des semaines à propos du projet, ils votèrent afin de décider du compilateur à utiliser, ou, à défaut, s'il fallait en écrire un -- une année après que le projet ait commencé avec un compilateur parfaitement adéquat. Ils s'attachèrent ensuite à débattre de la façon de générer des binaires à modèle mémoire « large » (capables d'utiliser plus d'un Mo de mémoire vive) mais négligeaient l'architecture du gestionnaire de mémoire virtuelle employé par le noyau.

4. Le retour de la cabale

Linux 8086 continua à progresser, les vrais développeurs avaient mis beaucoup de noms dans leur liste noire (kill file) afin pouvoir communiquer via la lidie, mais il y avait tout simplement trop de personnes incompétentes qui s'y agitaient en vain. Cela cessa, donc, d'être un modèle bazar, et l'équipe de développement se transforma en un noyau dur, ce qui, pour un grand nombre de personnes, est un mot poli pour une « cabale ». Cette position défensive est inévitable dans ce genre de circonstances.

Dans le cas de Linux, la base d'utilisateurs/programmeurs a augmenté lentement, à commencer par ceux qui ont contribué au code et qui, soit faisaient partie de la communauté qui bidouillait le Minix original, soit de ceux qui ont appris « à la dure », c'est-à-dire redémarrage après redémarrage. Lorsque le projet devint plus important, ceux qui auraient pu créer un « Comité d'Administration et de Planification attaché à l'évolution du noyau Linux » se retrouvèrent plongés dans un milieu où l'on attendait d'eux des résultats et où l'échec n'était pas perçu comme un problème. Pour citer Linus : « Show me the source! »

« Montre moi le code source ! »
.

Si quelqu'un était bloqué faute de connaissances il postait des questions et il y avait (et c'est toujours le cas) un nombre de participants suffisamment élevé pour que normalement quelqu'un ait à la fois le temps et la connaissance nécessaires pour y répondre.

Dans le cas de Linux 8086 les développeurs pouvaient attendre longtemps depuis qu'ils s'étaient emmurés eux-mêmes. Une plus grande proportion de développeurs actifs par rapport aux développeurs débutants (potentiellement utiles) aurait pu transformer rapidement une partie du bruit en utiles considérations. Le projet aurait gagné d'autres programmeurs chevronnés qui, à leur tour, auraient parlé du projet à d'autres. De la même façon qu'avec n'importe quel exercice d'apprentissage vous êtes plus productifs avec peu de personnes inexpérimentées.

Certaines personnes émettent une hypothèse selon laquelle vous ne pouvez transformer des programmeurs médiocres en vrais programmeurs. De par mon expérience personnelle dans le projet Linux, je sais qu'il y a un très grand nombre de gens qui poussés par un peu d'aide et un poil de confiance, peuvent se hisser parmi les meilleurs. Beaucoup n'y arriveront pas, mais il y en aura toujours suffisamment

Pour illustrer ces propos, l'auteur du code original d'IPv6 pour Linux avait pour habitude de faire de l'IRC à partir du Portugal en parlant de quelques concepts de bases et en posant des questions. Après que nous l'ayons aidé à comprendre quelques particularités du noyau il a écrit probablement 75 % de la pile IPv6 pour Linux et aux dernières nouvelles, il travaillait aux USA pour CISCO.
.

Le projet Linux 8086 a presqu'entièrement été sauvé de sa « gangrène » et c'est actuellement un petit projet tranquille utilisant CVS et dirigé par Alastair Riddoch, qui fait un excellent travail. Depuis que les conseillers municipaux ont vidé la place, il est maintenant possible de poser des questions, rejoignez-nous et participez au projet.

5. Dura lex, sed lex

Les leçons à tirer de ce projet, et des autres qui ont suivi le même chemin (et qui, pour certains, en sont morts - rappelez-vous les récents projets de traitement de texte sous Linux) sont à peu près claires :

Donc, la prochaine fois que quelqu'un désirera voter sur un projet, ou discuter des différentes possibilités pendant un mois et ensuite l'implémenter -- prenez garde. Ils peuvent aboutir à la bonne solution. Cependant, vous mettez les chances de votre côté si vous continuez sans y prêter attention. Demandez juste d'envoyer un patch lorsque cela marchera.

Prenez garde à ne pas attendre que les autres fassent le travail à votre place et apprenez à vous impliquer dans le projet pour que les choses progressent.