Bazar ou cathédrale ?

Quelques extraits de la traduction en français

Le style de développement de Linus Torvalds
 distribuez vite et souvent,
 déléguez tout ce que vous pouvez déléguer,
 soyez ouvert jusqu’à la promiscuité

est venu comme une surprise. À l’opposé de la construction de cathédrales, silencieuse et pleine de vénération, la communauté Linux paraissait plutôt ressembler à un bazar, grouillant de rituels et d’approches différentes très justement symbolisé par les sites d’archives de Linux, qui acceptaient des contributions de n’importe qui, à partir duquel un système stable et cohérent ne pourrait apparemment émerger que par une succession de miracles.

Le fait que ce style du bazar semblait fonctionner, et bien fonctionner, fut un choc supplémentaire. Alors que j’apprenais à m’y retrouver, je travaillais dur, non seulement sur des projets particuliers, mais encore à essayer de comprendre pourquoi le monde Linux, au lieu de se disloquer dans la confusion la plus totale, paraissait au contraire avancer à pas de géant, à une vitesse inimaginable pour les bâtisseurs de cathédrales.

1. Tout bon logiciel commence par gratter un développeur là où ça le démange.

Ceci est peut-être une évidence, il est bien connu, et depuis longtemps, que Nécessité est mère d’Invention, mais trop souvent on voit des développeurs de logiciels passer leurs journées à se morfondre à produire des programmes dont ils n’ont pas besoin et qu’ils n’aiment pas. Ce n’est pas le cas dans le monde Linux — ce qui peut expliquer pourquoi la plupart des programmes issus de la communauté Linux sont de si bonne facture.

2. Les bons programmeurs savent quoi écrire. Les grands programmeurs savent quoi réécrire (et réutiliser).

N’ayant pas la prétention de me compter parmi les grands programmeurs, j’essaie seulement de les imiter. Une caractéristique importante des grands programmeurs est la paresse constructive. Ils savent qu’on n’obtient pas 20/20 pour les efforts fournis, mais pour le résultat obtenu, et qu’il est pratiquement toujours plus facile de partir d’une bonne solution partielle que de rien du tout.

pragmatique et/ou théorique

3. Prévoyez d’en jeter un, car de toute manière, vous le ferez. (Fred Brooks, The Mythical Man-Month, chapitre 11)

Good cooking fakes time. If you are made to wait, it is to serve you better, and to please you. MENU OF RESTAURANT ANTOINE. ...

On ne comprend souvent vraiment bien un problème qu’après avoir implanté une première solution. La deuxième fois, on en sait parfois assez pour le résoudre correctement. Ainsi, si vous voulez faire du bon travail, soyez prêt à recommencer au moins une fois.

4. Si vous avez la bonne attitude, les problèmes intéressants viendront à vous.

5. Quand un programme ne vous intéresse plus, votre dernier devoir à son égard est de le confier à un successeur compétent.

6. Traiter vos utilisateurs en tant que co-développeurs est le chemin le moins semé d’embûches vers une amélioration rapide du code et un débogage efficace. Il est merveilleux de disposer d’utilisateurs, et pas seulement parce qu’ils vous rappellent que vous remplissez un besoin et que vous avez fait une bonne chose. Éduqués de façon appropriée, ils peuvent devenir vos co-développeurs. Linus Torvald dit de lui-même, je suis tout simplement une personne très paresseuse, qui aime se faire remercier pour le travail effectué par d’autres. Paresseux comme un renard.

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

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.

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.

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.

9. Il vaut mieux avoir des structures de données intelligentes et un code stupide que le contraire.

Développement de fetchmail
 J’ai distribué tôt et mis à jour souvent (au moins tous les dix jours ; pendant les périodes de développement effréné, une fois par jour).
 J’ai agrandi ma liste de bêta-testeurs en y ajoutant tout ceux qui me contactaient et me parlaient de fetchmail.
 À chaque mise à jour, j’envoyais un petit palabre sur la liste bêta, encourageant les gens à participer.
 Et j’ai écouté mes bêta-testeurs, en les sondant sur les choix de conception et en les caressant dans le sens du poil à chaque fois qu’ils m’envoyaient leur avis ou des corrections.

10. Si vous traitez vos bêta-testeurs comme ce que vous avez de plus cher au monde, ils réagiront en devenant effectivement ce que vous avez de plus cher au monde.

11. Il est presque aussi important de savoir reconnaître les bonnes idées de vos utilisateurs que d’avoir de bonnes idées vous-même. C’est même préférable, parfois.

Mais on doit retenir deux autres leçons essentielles, apolitiques, valables pour toutes sortes de conceptions de procédés nouveaux :

12. Bien souvent, les solutions les plus innovantes, les plus frappantes, apparaissent lorsque vous réalisez que votre approche du problème était mauvaise : Quand vous vous heurtez à un mur au cours du développement d’un projet — quand vous avez du mal à réfléchir au-delà de la prochaine génération de corrections — c’est souvent le bon moment pour vous demander, non pas si vous apportez la bonne réponse, mais plutôt si vous posez la bonne question. Il se peut qu’il faille recadrer le problème.

La morale ? N’hésitez pas à jeter aux orties des fonctionnalités dépassées quand vous le pouvez sans perdre en efficacité. Antoine de Saint-Exupéry (qui, lorsqu’il n’écrivait pas des classiques pour enfants, pilotait et construisait des avions), a dit :

13. La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever. C’est quand votre code devient meilleur et plus simple, que vous savez qu’il est bon.

14. Tout outil doit être utile par rapport aux utilisations qu’il a été prévu d’en faire. Mais on reconnaît un outil vraiment excellent au fait qu’il se prête à des usages totalement insoupçonnés.

15. Quand vous écrivez un logiciel jouant le rôle d’une passerelle quelconque, prenez soin de perturber le moins possible le flot de données — et ne perdez *jamais* d’éléments d’information, à moins que la machine destinataire vous y oblige !

Quelques utilisateurs européens m’ont ennuyé jusqu’à ce que j’ajoute une option pour limiter le nombre de messages transférés à chaque session (pour qu’ils puissent contrôler le prix de la communication téléphonique, sur leur onéreux réseau). J’ai mis du temps à m’y résoudre, et aujourd’hui encore je n’en suis pas très content. Mais quand vous êtes au service du monde entier, il vous faut écouter vos consommateurs — le fait qu’ils ne vous paient pas en monnaie sonnante et trébuchante ne change rien à l’affaire.

16. Quand votre langage est loin d’être Turing équivalent, un peu de sucre syntaxique ne peut qu’aider.

17. Un système de sécurité n’est pas plus sûr que le secret (la clé) qui le garde. Gare aux pseudo secrets !

Pré-requis nécessaire : le chef, ou coordinateur, d’un projet dans le style bazar doit être bon en relations humaines et avoir un bon contact. Cela devrait être évident. Pour construire une communauté de développement, il vous faut séduire les gens, les intéresser à ce que vous faites, et les encourager pour les petits bout du travail qu’ils réalisent. De bonnes compétences techniques sont essentielles, mais elles sont loin de suffire. La personnalité que vous projetez compte aussi. Le chef, ou coordinateur, d’un projet dans le style bazar doit être bon en relations humaines et avoir un bon contact. Cela devrait être évident. Cela n’est pas une coïncidence que Linus soit un chic type qu’on apprécie volontiers et qu’on a envie d’aider. Cela n’est pas fortuit non plus que je sois un extraverti énergique qui aime animer les foules et qui se comporte et réagit comme un comique de théâtre. Pour que le modèle du bazar fonctionne, une petite touche de charme et de charisme aide énormément.

18. Pour résoudre un problème intéressant, commencez par trouver un problème qui vous intéresse.

 La loi de Brooks  : Dans The Mythical man-month, Fred Brooks observa qu’on ne peut pas diviser et répartir le temps du programmeur ; si un projet a du retard, lui ajouter des développeurs ne fera qu’accroître son retard. Il explique que les coûts de communication et de complexité d’un projet augmentent de manière quadratique avec le nombre de développeurs, alors que le travail réalisé n’augmente que linéairement.

 La correction de Weinberg (in La psychologie de la programmation sur ordinateur) : la programmation non égoïste. Dans les boîtes où les programmeurs ne marquent pas le territoire de leur code, et encouragent les autres à y chercher les bogues et les améliorations potentielles, les améliorations sont drastiquement plus rapides qu’ailleurs.

Linux fut le premier projet qui fit un effort conscient et abouti pour utiliser le monde entier comme réservoir de talent. Il y avait aussi un autre facteur vital : le développement d’un style de direction de projet et d’un ensemble de coutumes de coopération qui permettaient aux développeurs d’attirer des co-développeurs et de rentabiliser au maximum ce nouveau média. Quel est donc ce style de direction, quelles sont donc ces coutumes ? Ils ne peuvent pas être fondés sur des rapports de force. Linus, en se positionnant avec succès comme gardien des clés d’un projet où le développement est surtout fait par les autres, et en y injectant de l’intérêt jusqu’à ce qu’il devienne auto-suffisant a montré une intelligence profonde du principe de bonne intelligence de Kropotkine. Cette vision quasi-économique du monde de Linux nous permet de comprendre comment cette bonne intelligence est mise en oeuvre.

19. C’est pourquoi je propose la contrepartie suivante à la loi de Brooks :
pour peu que le coordinateur du développement dispose d’un moyen de communication au moins aussi bon que l’Internet, et pour peu qu’il sache comment mener ses troupes sans coercition, il est inévitable qu’il y ait plus de choses dans plusieurs têtes que dans une seule.