Page suivante Page précédente Table des matières

4. Distribuez tôt, mettez à jour souvent

Un élément essentiel du système de développement de Linux est la mise à jour rapide et fréquente des nouvelles versions. La plupart des développeurs (moi y compris) pensait que ce n'était pas une bonne méthode pour des projets de taille non triviale, parce que des versions prématurées sont quasiment, par définition, des versions boguées, et qu'il n'est pas dans votre intérêt d'abuser de la patience des utilisateurs.

C'est cette croyance qui a consolidé l'attachement général au style de développement de type cathédrale. Si l'objectif premier était de présenter aux utilisateurs une version aussi dépouillée de bogues que possible, alors vous ne faisiez une mise à jour que tous les six mois (voire moins souvent encore), et vous travailliez d'arrache-pied au débogage entre les mises à jour. C'est de cette manière qu'a été mis au point le coeur d'Emacs, écrit en C. Ce ne fut pas le cas, en pratique, de la bibliothèque Lisp -- parce qu'il existait des archives Lisp ``vivantes'' hors de portée de la FSF, et où on pouvait trouver de nouvelles versions de code de développement indépendamment du cycle de mises à jour d'Emacs.

La plus importante de ces archives, l'archive elisp de l'État de l'Ohio, était en avance sur son temps et avait déjà deviné l'esprit et la plupart des spécificités des archives Linux actuelles. Mais bien peu d'entre nous réfléchissaient vraiment beaucoup sur ce que nous faisions ou sur les problèmes liés au développement de style cathédrale adoptés par la FSF que l'existence même de cette archive pouvait suggérer. J'ai vraiment tenté, une fois, vers 1992, de faire passer de manière formelle, un bon morceau du code d'Ohio dans la bibliothèque Lisp officielle d'Emacs. Je n'ai rencontré que des guerres d'opinions et je suis rentré bredouille dans les grandes longueurs.

Mais un an plus tard, alors que Linux devenait de plus en plus apparent, il était clair que quelque chose de différent, de plus sain, était en train de se produire. La politique de développement ouvert de Linus était l'antithèse même du modèle des cathédrales. Les archives de sunsite et de tsx-11 bourgeonnaient, de multiples distributions étaient mises à l'eau. Et tout cela était rythmé par une fréquence de mise à jour du coeur même du système jusqu'alors inégalée.

Linus traitait ses utilisateurs comme des développeurs de la manière la plus efficace:

7. Distribuez tôt. Mettez à jour souvent. Et soyez à l'écoute de vos clients.

La grande innovation de Linus ne fut pas tant de faire cela (c'était une tradition du monde Unix depuis un bon moment, en tout cas sous une forme proche), que de donner à cette idée un niveau d'intensité correspondant à la complexité de ce qu'il développait. En ces temps reculés (autour de 1991), il lui arrivait de mettre à jour son noyau plusieurs fois par jour ! Comme il cultivait sa base de co-développeurs et recherchait des collaborations sur Internet plus que quiconque jusque là, cela a marché.

Mais comment cela a-t-il marché ? Et, était-ce quelque chose que je pouvais dupliquer, ou cela reposait-il uniquement sur quelque trait de génie propre à Linus Torvalds ?

Je ne le pensais pas. Je vous l'accorde, Linus est un bidouilleur sacrément bon (combien parmi nous pourraient mettre au point l'intégralité du noyau d'un système d'exploitation prêt à être mis en production  ?). Mais Linux ne constituait pas vraiment un réel progrès conceptuel. Linus n'est pas (en tout cas, pas encore) un génie de l'innovation dans la conception comme peuvent l'être Richard Stallman ou James Gosling (de NeWS et Java). Au contraire, Linus est à mes yeux un génie de l'ingéniérie, doué d'un sixième sens qui lui permet d'éviter les bogues et les impasses de développement et surtout d'un authentique talent pour trouver le chemin de moindre effort reliant A à B. En effet, la conception de Linux dans son intégralité est imprégnée de cette qualité et reflète l'approche conservatrice et simplificatrice qu'a Linus de la conception.

Ainsi, si la rapidité des mises à jour et l'extraction de la substantifique moelle de l'Internet en tant que moyen de communication n'étaient pas des hasards, mais faisaient partie intégrante du côté visionnaire génial de Linus vers le chemin le plus facile à suivre, qu'est-ce donc qu'il maximisait ? Qu'est-ce donc qu'il tirait de toute cette machinerie ?

Posée de cette manière, la question contient sa propre réponse. Linus stimulait et récompensait ses utilisateurs/bidouilleurs en permanence -- il les stimulait par la perspective auto-gratifiante de prendre part à l'action, et il les récompensait par la vue constante (et même quotidienne) des améliorations de leur travail.

Linus cherchait directement à maximiser le nombre de personnes-heures jetées dans la bataille du débogage et du développement, au prix éventuel d'une certaine instabilité dans le code et de l'extinction de sa base d'utilisateurs si un quelconque bogue sérieux se révélait insurmontable. Linus se comportait comme s'il croyait en quelque chose comme:

8. Étant donné un ensemble de bêta-testeurs et de co-développeurs suffisamment grand, chaque problème sera rapidement isolé, et sa solution semblera évidente à quelqu'un.

Ou, moins formellement, ``Étant donnés suffisamment d'observateurs, tous les bogues sautent aux yeux.'' C'est ce que j'appelle: ``La Loi de Linus''.

Ma première formulation de cette loi était que chaque problème ``semblera clair comme de l'eau de roche à quelqu'un''. Linus a objecté qu'il n'était pas nécessaire, et que d'ailleurs ce n'était pas le cas en général, que la personne qui comprenne un problème soit la personne qui l'ait d'abord identifié. ``Quelqu'un trouve le problème,'' dit-il, ``et c'est quelqu'un d'autre qui le comprend. Je pousserai le bouchon jusqu'à dire que le plus difficile est de trouver le problème.'' Mais le principal est que ces deux événements se produisent en général vite.

C'est là, je pense, la différence fondamentale sous-jacente aux styles de la cathédrale et du bazar. Dans la programmation du point de vue de la cathédrale, les bogues et les problèmes de développement représentent des phénomènes difficiles, ennuyeux, insidieux, profonds. Il faut à une poignée de passionnés des mois d'observations minutieuses avant de bien vouloir se laisser convaincre que tous les bogues ont été éliminés. D'où les longs intervalles séparant les mises à jour, et l'inévitable déception quand on se rend compte que la mise à jour tant attendue n'est pas parfaite.

Dans le point de vue bazar, d'un autre côté, vous supposez qu'en général, les bogues sont un phénomène de surface -- ou, en tout cas, qu'ils sautent rapidement aux yeux lorsqu'un millier de co-développeurs avides se précipitent sur toute nouvelle mise à jour. C'est pourquoi vous mettez à jour souvent afin de disposer de plus de corrections, et un effet de bord bénéfique est que vous avez moins à perdre si de temps en temps, un gros bogue vous échappe.

Et voilà. C'est tout. Si la ``Loi de Linus'' est fausse, alors tout système aussi complexe que le noyau Linux, subissant les bidouilles simultanées d'autant de mains que ce fut le cas du noyau Linux, aurait dû à un certain moment s'effondrer sous le poids des interactions néfastes et imprévues, sous le poids de bogues ``profonds'' non découverts. D'un autre côté, si elle est juste, elle suffit à expliquer l'absence relative de bogues dans Linux.

Et peut-être bien, après tout, que cela ne devrait pas être aussi surprenant. Il y a des années que les sociologues ont découvert que l'opinion moyenne d'un grand nombre d'observateurs (tous aussi experts, ou tous aussi ignorants) est d'un indicateur beaucoup plus fiable que l'opinion de l'un des observateurs, choisi au hasard. Ils ont appelé ce phénomène l'``effet de (l'oracle de) Delphes''. Il apparaît que Linus a fait la preuve que cela s'applique même au débogage d'un système d'exploitation -- que l'effet de Delphes peut apprivoiser la complexité du développement même au niveau de complexité atteint par le noyau d'un système d'exploitation.

Je dois à Jeff Dutky <dutky@wam.umd.edu> la remarque qu'on peut reformuler la Loi de Linus sous la forme ``On peut paralléliser le débogage''. Jeff fait remarquer que, même si le débogage requiert que les débogueurs communiquent avec un développeur chargé de la coordination, une réelle coordination entre débogueurs n'étant pas indispensable. Ainsi, le débogage n'est pas la proie de cette augmentation quadratique de la complexité et des coûts d'organisation qui rend problématique l'ajout de nouveaux développeurs.

En pratique, le monde Linux n'est quasiment pas affecté par la perte théorique d'efficacité qui découle du fait que plusieurs débogueurs travaillent sur la même chose au même moment. L'une des conséquences de la politique du ``distribuez tôt, mettez à jour souvent'' est de minimiser les pertes de ce type en propageant au plus vite les corrections qui sont revenues au coordinateur.

Brooks a même fait une observation annexe proche de celle de Jeff: ``Le coût total de maintenance d'un programme largement utilisé est typiquement de 40 pour cent ou plus de son coût de développement. De façon surprenante, ce coût dépend énormément du nombre d'utilisateurs. Un plus grand nombre d'utilisateurs trouve un plus grand nombre de bogues.'' (l'emphase est de mon fait).

Plus d'utilisateurs trouvent plus de bogues parce que l'ajout de nouveaux utilisateurs introduit de nouvelles manières de pousser le programme dans ses derniers retranchements. Cet effet est amplifié quand les utilisateurs se trouvent être des co-développeurs. Chacun d'entre eux a une approche personnelle de la traque des bogues, en utilisant une perception du problème, des outils d'analyse, un angle d'attaque qui lui sont propres. L'``effet de Delphes'' semble précisément fonctionner grâce à cette variabilité. Dans le contexte spécifique du débogage, la diversité tend aussi à réduire la duplication des efforts.

Ainsi, introduire de nouveaux bêta-testeurs ne va sans doute pas réduire la complexité du bogue le plus ``profond'' du point de vue du développeur, mais cela augmente la probabilité que la trousse à outils d'un bêta-testeur sera adaptée au problème de telle sorte que le bogue saute aux yeux de cette personne.

Mais Linus assure ses arrières. Au cas où il y aurait des bogues sérieux, les versions du noyau Linux sont numérotées de telle sorte que des utilisateurs potentiels peuvent faire le choix d'utiliser la dernière version désignée comme étant ``stable'', ou de surfer à la pointe de la technique courant le risque que quelques bogues accompagnent les nouvelles fonctionnalités. Cette tactique n'est pas encore formellement imitée par la plupart des bidouilleurs Linux, mais c'est sans doute un tort; le fait d'avoir une alternative rend les deux choix séduisants.


Page suivante Page précédente Table des matières