Crowdsourcing (4) - le bazar, de fond en comble

Dans nos précédents articles sur le crowdsourcing, j’ai exposé les principes et les bonnes pratiques de cette démarche de mobilisation d'intelligence collective. Cet article est une occasion d’approfondir notre recherche opérationnelle des leviers d'efficacité des projets qui s'incrivent dans cet esprit. Je recommande vivement à l'internaute intéressé la lecture de la série d'articles dans l'ordre de leur parution.

J’ai déjà fait référence à l’essai « La Cathédrale et le Bazar » (titre original : « The Cathedral and the Bazaar » - éditions O'Reilly) de Eric RAYMOND sur le mode de développement des outils Open Source en crowdsourcing. Il y expose un vivant retour d'expérience sur le développement d'un outil de messagerie électronique (Fetchmail) dont il a été l'initiateur (project leader).
De cette expérience d’intelligence collective de premier plan, E. RAYMOND tire des enseignements valides pour tout développement de logiciel libre en Open Source. 

"Le style de développement de Linus TROVALDS (...) est arrivé 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. "

E.S. RAYMOND se fixa donc pour objectif d' "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."

Préalable : le style "littéraire" de E. RAYMOND est très américain - direct et proche du langage parlé. J'ai conservé cette tournure de phrases. D'abord par respect pour l'auteur. Ensuite pour l'éventuelle vertu "pédagogique" de cette écriture.

Crowdsourcing (Open Source) - le retour d'expérience d'un project leader

1.    Tout bon projet commence par gratter un leader 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 managers passer leurs temps à se morfondre à gérer des projets dont ils n'ont pas besoin et qu'ils n'aiment pas.

2. Les bons leaders savent quoi lancer. Les grands leaders savent quoi relancer (et réutiliser).

Une caractéristique importante des grands leaders 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.

De telle sorte que passer du temps à chercher le ``presqu'assez bon'' de quelqu'un d'autre a plus de chances de donner de bons résultats dans le monde Linux que nulle part ailleurs.

3. ``Prévoyez d'en mettre un à la poubelle, car de toute manière, vous le ferez.''

Ou, dit autrement, 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 une idée, un projet ou un produit ne vous intéresse plus, votre dernier devoir à son égard est de le confier à un successeur compétent.

 Il est merveilleux de disposer de personnes qui font usage de vos productions , et pas seulement parce qu'elles vous rappellent que vous remplissez un besoin et que vous avez fait une bonne chose. Employées de façon appropriée, elles peuvent devenir de précieux contributeurs.

De plus, la libre disponibilité de l’information sur l’objet même de votre activité (code source, références documentaires, …)  en fait des contributeurs efficaces. Ceci peut se révéler incroyablement utile pour réduire les délais de résolution de problème (bugs, erreurs de raisonnement, erreur de conception d’un produit,…) . Avec un peu d'encouragement (ils n'en réclament pas beaucoup), vos contributeurs diagnostiqueront les problèmes, suggéreront des corrections, et vous aideront à améliorer votre production bien plus rapidement que vous n'auriez pu le faire, si vous étiez laissé à vous même.

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.

7… Et soyez à l'écoute de vos clients.

Mais comment cela a-t-il marché ?

 

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.

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.

``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.

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.

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.

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.

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.

12. Bien souvent, les solutions les plus innovantes, les plus frappantes, apparaissent lorsque vous réalisez que votre approche du problème était mauvaise.

13. ``La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever.''

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.

On peut tester, déboguer et améliorer un programme dans le style bazar, mais il sera très difficile de faire démarrer un projet dans le mode bazar. Il faut que votre communauté naissante de développeurs ait quelque chose qui tourne, qu'on puisse tester, avec quoi elle puisse jouer.

Quand vous initiez un travail de développement en communauté, il vous faut être capable de présenter une promesse plausible. Votre programme ne doit pas nécessairement fonctionner très bien. Il peut être grossier, bogué, incomplet, et mal documenté. Mais il ne doit pas manquer de convaincre des co-développeurs potentiels qu'il peut évoluer en quelque chose de vraiment bien dans un futur pas trop lointain.

Je pense qu'il n'est pas critique que le coordinateur soit capable de produire des conceptions exceptionnellement brillantes. En revanche, il est absolument critique que le coordinateur soit capable de reconnaître les bonnes idées de conception des autres.

Mais le problème avec l'intelligence et l'originalité dans la conception de logiciels, c'est que ça devient une habitude -- presque par réflexe, vous commencez à faire dans l'esthétique et le compliqué alors qu'il faudrait rester simple et robuste. Certains de mes projets n'ont jamais abouti à cause de cette erreur,

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.

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

19. 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.

Erwan BUREL
HAUTE PERFORMANCE Conseil Formation Accompagnement
www.haute-performance.fr

contact : erwan.burel@haute-performance.fr