Le modèle du bazar

Dès 1997, Eric Raymond s'est intéressé à la gestion de projets libres. Il oppose deux styles de gestion de projets :

• Le style "cathédrale", plus classique et fortement centralisé, suivi par la majeure partie de l'industrie du logiciel, mais aussi par la Free Software Foundation
• Le style "bazar", plus récent et fortement décentralisé, suivi par Linus Torvald, le créateur de Linux, et une part croissante du monde libre

Eric Raymond, auteur et coordonnateur du projet fetchmail, a analysé la gestion d'un projet réel de style bazar. Il a mis en évidence 19 points importants :

1. Tout bon logiciel commence par gratter un développeur là où ça le démange.
2. Les bons programmeurs savent quoi écrire. Les grands programmeurs savent quoi réécrire (et réutiliser).
3. Prévoyez de jeter un projet, car de toute façon, vous le ferez.
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. Traitez 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éboguage efficace.
7. Distribuez tôt. Mettez à jour souvent. Et soyez à l'écoute de vos clients.
8. Etant 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 ("Loi de Linus").
9. Il vaut mieux avoir des structures de données intelligentes et un code stupide que le contraire.
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 à retirer.
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 de 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 ne vous y oblige !
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 !
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.

Choisir son modèle économique

Eric Raymond distingue deux modèles de financement :

1. Le financement par la valeur d'utilisation, avec comme stratégies :
   
2. Le financement par la valeur d'acquisition indirecte, avec comme stratégies :

Le premier modèle correspond aux stratégies suivantes :

• Le partage des coûts - Le serveur web Apache a été développé par un groupe de webmestres reliés par Internet.
• L'étalement des risques - Le système de files d'impression à l'intention du réseau d'entreprise de Cisco a été rendu public.

Le second modèle correspond aux stratégies suivantes :

• La vente à perte pour se positionner sur le marché - Par exemple, Netscape a choisi de rendre publiques les sources de son navigateur (projet Mozilla) afin de relancer l'innovation et ainsi de tenir tête à Microsoft.
• Le gel des gadgets - Certains fabricants de matériel rendent publics le code source des logiciels associés (comme les drivers), ces derniers n'étant pas une source de bénéfices. Ainsi, Apple Computer a décidé mi-mars 1999 d'ouvrir la source de Darwin, le coeur de leur système d'exploitation MacOSn X
• Donner la recette, ouvrir un restaurant - Red Hat et les autres sociétés distribuant Linux ne vendent pas le logiciel. En réalité, leur valeur ajoutée provient de l'assemblage, des tests d'un système d'exploitation garanti (ne serait-ce qu'implicitement) comme étant de qualité commerciale et compatible avec d'autres systèmes d'exploitation portant la même marque. D'autres éléments de leur proposition sont une assistance technique gratuite à l'installation et la fourniture d'options pour des contrats d'assistance étendus.
• Les accessoires - Dans ce modèle, on vend des accessoires pour du logiciel à la source ouverte. Cela couvre toute la gamme, des objets comme les tasses et les t-shirts aux documentations éditées et produites par des professionnels. O'Reilly édite par exemple des livres sur les technologies libres.
• Libérer l'avenir, vendre le présent - Le logiciel est publié sous forme de binaires et la source sous une licence fermée, avec une date limite à laquelle les restrictions prendront fin On trouve dans cette catégorie les licences chrono-dégradables. Aladin Enterprises suit ce modèle avec son logiciel Ghostscript.
• Libérer le logiciel, vendre la marque - Sun Microsystems procède de la sorte avec Java et Jini, dans le cadre de la Sun's Community Source Licence.
• Libérer le logiciel, vendre le contenu - Un site d'information vend de l'information, pas son infrastructure technique. Cette dernière peut avantageusement être libérée. AOL devrait ainsi libérer la source de son logiciel client.

Source : Viseur R., La dynamique Open Source, 2001. [Voir]