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

10. Quand faut-il ouvrir, quand faut-il fermer ?

Après avoir dressé un bilan des modèles économiques qui financent le développement des logiciels à sources ouverts, nous pouvons à présent nous poser la question plus générale de savoir quand le fait d'être à sources ouverts ou à sources fermés a une utilité économique. En premier lieu, nous devons découvrir les bénéfices que l'on peut retirer de chacune de ces stratégies.

10.1 Quels sont les bénéfices ?

L'approche sources fermés permet de faire du bénéfice grâce au secret de votre code ; d'un autre côté, cela vous prive de la possibilité de bénéficier d'un avis vraiment indépendant de vos pairs sur vos sources. L'approche sources ouverts permet d'avoir l'avis de vos pairs, mais ne vous permet pas de faire du bénéfice grâce au secret de votre code.

Le bénéfice que l'on obtient en gardant son source secret est facilement compréhensible ; traditionnellement, les modèles de l'industrie du logiciel sont construits autour. Encore récemment, les avantages que l'on pouvait retirer des critiques de ses pairs n'étaient pas bien compris. Le système d'exploitation Linux nous a pourtant enseigné une leçon que nous aurions dû apprendre depuis plusieurs années à partir de l'histoire des logiciels qui sous-tendent le coeur de l'Internet et les autres branches de l'ingénierie — et c'est que la critique de ses pairs est la seule méthode robuste pour obtenir une fiabilité et une qualité élevées.

Dans un marché concurrentiel, les clients qui recherchent une fiabilité et une qualité élevées choisiront de préférence les producteurs de logiciels qui ont choisi d'ouvrir leurs sources et qui ont trouvé comment se financer grâce aux services, à la valeur ajoutée, et aux marché annexes associés à leur logiciel. Ce phénomène est à la base de l'étonnant succès de Linux, qui, parti de rien en 1996, est passé à 17 % du marché des serveurs à la fin de 1998 et semble bien parti pour dominer le marché d'ici deux ans (début 1999, IDC a annoncé que, d'après ses prévisions, Linux devrait progresser plus vite que l'ensemble de tous les autres systèmes d'exploitation jusqu'en 2003).

Un avantage tout aussi important des logiciels à sources ouverts est qu'ils peuvent être vus comme un moyen de diffuser des normes ouvertes et de construire des marchés autour de celles-ci. La spectaculaire progression de l'Internet est surtout due au fait que personne ne « possède » le protocole TCP/IP ; personne ne détient de droits sur les protocoles qui constituent la base de l'Internet..

Les effets réseau qui ont induit les succès de TCP/IP et de Linux apparaissent de façon évidente. D'une part, ils empêchent totalement l'apparition de problèmes de confiance mutuelle, et d'autre part ils offrent une certaine symétrie — les acteurs potentiels d'une infrastructure commune placeront d'autant plus naturellement leur confiance dans celle-ci s'ils peuvent voir quels en sont ses mécanismes internes, et ils préféreront une infrastructure dans laquelle tous les partis ont un rôle symétrique à une infrastructure où un seul parti possède le privilège d'en extraire du bénéfice ou d'exercer un contrôle.

Il n'est, cependant, pas vraiment nécessaire d'admettre l'existence des effets réseau pour comprendre que la symétrie est une chose importante pour les utilisateurs de logiciels. En effet, aucun de ces utilisateurs ne voudraient raisonnablement choisir de s'enfermer lui-même dans un monopole contrôlé par son fournisseur en devenant dépendant de sources fermés s'il existe une quelconque solution à sources ouverts de qualité raisonnable. Cet argument est d'autant plus fort que le logiciel considéré est crucial dans le travail de l'utilisateur — plus le logiciel est vital, moins le client peut tolérer de le voir contrôlé par un parti extérieur.

Pour finir, un des importants avantages pour le consommateur des logiciels à sources ouverts, relié à la confiance mutuelle, est l'assurance d'un suivi futur de ce logiciel, le rendant résistant au temps. Si les sources sont ouverts, le client a certains recourts si le vendeur met la clef sous la porte. Cela peut-être particulièrement important pour le modèle du « gel des gadgets », car le matériel informatique tend à avoir un court cycle de vie, mais l'effet est plus général et augmente ainsi la valeur des logiciels à sources ouverts.

10.2 Comment interagissent-ils ?

Lorsque le bénéfice que l'on fait sur le secret des sources est plus élevé que celui qu'on dégagerait sur des sources ouverts, il est logique, économiquement parlant, de fermer ses sources. Lorsque le bénéfice des logiciels à sources ouverts est plus élevé que celui basé sur le secret des sources, il est logique d'ouvrir ses sources.

En elle-même, cette observation est triviale. Elle devient plus complexe lorsqu'on remarque que le bénéfice d'un logiciel à sources ouverts est plus difficile à mesurer et à prédire que celui des logiciels à sources fermés — et que ce bénéfice est plus souvent outrageusement dévalué que surestimé. En effet, jusqu'à ce que le courant de pensée du monde des affaires revoie ses prémisses en suivant l'exemple de l'ouverture des sources de Mozilla au début de l'année 1998, les bénéfices des logiciels à sources ouverts étaient faussement mais très communément supposés comme nul.

Mais comment peut-on évaluer le bénéfice que l'on peut retirer des logiciels à sources ouverts ? C'est, en général, une question difficile, mais nous pouvons l'aborder comme n'importe quel autre problème prévisible. On peut partir des cas observés où l'approche sources ouverts a réussi ou échoué. Nous pouvons essayer de généraliser ces exemples en un modèle qui donne, au moins, une intuition qualitative quant aux contextes dans lesquels l'ouverture des sources procure un net gain à l'investisseur ou à l'entreprise visant à maximiser les retours sur capital. Nous pourrons alors revenir aux cas réels et essayer de raffiner un peu le modèle.

D'après l'analyse présentée dans [CatB] , nous pouvons supposer que les logiciels à sources ouverts permettent de réaliser un bénéfice important lorsque (a) la fiabilité/stabilité/pérénité sont critiques, et (b) la qualité de la conception et de l'implémentation sont difficilement vérifiables par un autre moyen que l'analyse critique des pairs (le second critère se retrouve, dans la pratique, pour les logiciels complexes).

Le désir naturel d'un consommateur d'éviter d'être enfermé dans un monopole dirigé par son fournisseur augmentera d'autant plus son intérêt pour les logiciels à sources ouverts (et, donc, la compétitivité des fournisseurs qui ouvrent leurs sources) que le logiciel est important pour lui. Ainsi, un autre critère, (c) joue en faveur des logiciels à sources ouverts lorsque le logiciel est crucial pour l'activité du consommateur (comme, par exemple, dans beaucoup d'entreprises, le département comptable).

Comme pour l'étude de cas, nous avons précédemment observé que les logiciels à sources ouverts créaient un climat de confiance mutuelle et une symétrie parmi les acteurs, ce qui, à long terme, tend à attirer plus de consommateurs et à dépasser les stratégies à sources fermés ; et il est souvent meilleur d'avoir une petite part d'un marché qui croît rapidement qu'une grosse part d'un marché fermé qui stagne. Par conséquent, en ce qui concerne les stratégies de logiciels, les logiciels à sources ouverts qui jouent sur la diffusion à outrance ont plus de chance d'atteindre un bénéfice à long terme qu'une stratégie à sources fermés qui joue sur la location d'un droit de propriété intellectuelle.

En fait, la capacité des consommateurs potentiels à raisonner sur les conséquences futures des stratégies des vendeurs et leur réticence à accepter le monopole d'un fournisseur induisent une forte contrainte ; bien que celle-ci ne soit pas accablante, vous pouvez choisir soit une stratégie de diffusion sources ouverts, soit une stratégie de revenu immédiat source fermés — mais pas les deux (des analogies à ce principe sont visibles un peu partout, par exemple dans les marchés électroniques où les clients refusent souvent d'acheter tout à la même source). On peut voir les choses de façon moins négative ; là où les effets réseau (sous forme de rétro-actions positives) dominent, les logiciels à sources ouverts sont probablement le bon choix.

On peut ajouter à cela que les logiciels à sources ouverts semblent être doués pour générer un plus grand retour de bénéfices que les logiciels à sources fermés dans des logiciels qui (d) établissent ou mettent en oeuvre des opérations informatiques courantes et des infrastructures de communication.

Enfin, on peut remarquer que les fournisseurs d'un service unique, ou même de services très différents les uns des autres, ont toutes les raisons de craindre que leurs concurrents copient leurs méthodes, au contraire des vendeurs de services, dont les algorithmes sont connus et compris de tous. Par conséquent, les logiciels à sources ouverts sont plus probablement à même de l'emporter lorsque (e) les algorithmes clefs (ou leurs équivalents fonctionnels) font partie de la base de connaissance commune des informaticiens.

Les logiciels qui sous-tendent l'Internet, Apache, et l'implémentation de l'interface de programmation (API) ANSI Unix de Linux sont les plus importants exemples de ces cinq critères. Le chemin vers les logiciels à sources ouverts dans l'évolution de tels marchés est bien illustré par une re-convergence des protocoles réseau sur TCP/IP au milieu des années 1990, après cinquante ans de tentatives ratées pour construire un empire sur des protocoles fermés tels que DECNET, XNS, IPX, et compagnie.

D'un autre côté, les logiciels à sources ouverts semblent être inefficaces pour des entreprises qui ont pour unique produit une technique logicielle originale (remplissant exactement le critère (e)) et qui est (a) relativement tolérant aux fautes, qui peut (b) facilement être vérifié par d'autres moyens que l'analyse critique des pairs, qui n'est pas (c) crucial au bon fonctionnement de l'entreprise, et qui ne verra pas sa valeur substantiellement augmentée par (d) les effets réseau ou la diffusion à outrance.

Pour donner un exemple de ce cas extrême, au début de l'année 1999 une entreprise qui écrivait des logiciels pour optimiser la longueur des planches extraites de coupes des troncs pour des scieries m'a demandé « Devrions-nous passer en sources ouverts? ». Ma conclusion fut « Non ». Le seul critère qui était pleinement rempli était le (c) ; mais, à la rigueur, un opérateur expérimenté pouvait optimiser lui-même la découpe.

Il est important de remarquer que lorsqu'un produit particulier ou une technique spécifique résident sur ces considérations, les métriques peuvent évoluer à travers le temps, comme nous le verrons dans les cas que nous allons étudier plus tard.

En résumé, les points suivants poussent à ouvrir les sources de votre logiciel :

(a)

lorsque la fiabilité/stabilité/pérénité du logiciel sont critiques

(b)

lorsque la qualité de la conception et de l'implémentation du logiciel sont difficilement vérifiables par un autre moyen que l'analyse critique de ses pairs

(c)

lorsque le logiciel est indispensable à l'activité du client

(d)

lorsque le logiciel établit ou met en oeuvre une infrastructure banale, d'informatique ou de communications

(e)

lorsque les algorithmes clefs du logiciel (ou leurs équivalents fonctionnels) font partie de la base de connaissances communes des informaticiens

10.3 Doom : une étude de cas

L'histoire du record des ventes d'ID software, Doom, illustre les façons dont la pression du marché et l'évolution d'un produit peut modifier de façon conséquente l'importance des bénéfices entre un logiciel à sources fermés et un logiciel à sources ouverts.

Lorsque la première version de Doom est sortie fin 1993, c'était le premier et unique jeu à un joueur avec une animation temps réel (l'antithèse du critère (e)). Ce n'était pas seulement l'impact visuel de la technique qui étonnait, mais surtout le fait que pendant de nombreux mois, personne n'est arrivé à comprendre comment cela avait été réalisé sur les microprocesseurs sous-puissants de l'époque. Ce secret valait bien le prix du jeu. De plus, le bénéfice potentiel que l'on pourrait en retirer en passant en sources ouverts était faible. En tant que jeu à un joueur, le logiciel (a) pouvait se permettre d'avoir quelques bogues, (b) n'était pas extrêmement difficile à contrôler, (c) ne prenait pas une place cruciale dans l'activité professionnelle du client, (d) ne bénéficiait pas des effets réseau. Il était donc naturel pour Doom d'être en sources fermés.

Cependant, le monopole de Doom ne fut pas éternel. Des concurrents inventèrent des techniques d'animations similaires, et d'autres jeux semblables, comme Duke Nukem, sont apparus. Au moment où ces jeux commencèrent à grignoter des parts de marché à Doom, le bénéfice que l'on pouvait tirer du secret des algorithmes de représentation en vue subjective a disparu.

D'autre part, les efforts pour diffuser ce partage firent apparaître de nouveaux défis techniques — une meilleure fiabilité, plus de fonctionnalités de jeu, un plus grand nombre d'utilisateurs et de plates-formes. Avec l'avènement des jeux de « combat à mort » en multi-joueurs et des services de jeu de Doom, le marché commença à ressentir de manière substantielle les effets réseau. Tout cela demandait des heures de programmation qu'ID aurait préféré passer sur la version suivante.

Toutes ces tendances ont augmenté le bénéfice que l'on pouvait retirer d'une ouverture des sources. À un certain moment, la situation a rendu économiquement acceptable l'ouverture des sources de Doom par ID et le fait de faire du bénéfice sur les marchés annexes tels que les recueils de scénarios. Peu après, c'est effectivement ce qui s'est passé. La totalité des sources de Doom furent mis en libre accès fin 1997.

10.4 Savoir quand lâcher emprise

Doom est un cas intéressant car il n'est ni un système d'exploitation, ni un logiciel de communication réseau ; il est donc très éloigné des exemples habituels des logiciels à sources ouverts. En effet, le cycle de vie de Doom, achevé par le passage en sources ouverts, peut illustrer de manière typique le cas des logiciels d'application dans l'écologie du code actuellement ; où les communications et les calculs distribués créent à la fois des problèmes de robustesse, de fiabilité, de changement d'échelle que seule la revue des pairs permet de résoudre, et franchissent fréquemment les frontières séparant les environnements techniques et les acteurs en compétition (avec tous les problèmes de confiance et de symétrie que cela implique).

Doom a évolué d'un jeu à un joueur à un jeu multi-joueurs. De plus en plus, les effets du réseau ont remplacé la puissance de calcul. Des tendances similaires sont visibles, même dans les marchés les plus importants, comme les ERP, qui ne se sont jamais autant occupé de réseau avec des fournisseurs et des clients — et, bien sûr, il y a toute la structure implicite du Web. On peut déduire de tout cela qu'à peu près partout le bénéfice que l'on peut retirer des logiciels à sources ouverts est progressivement en train de croître.

Si la tendance se maintient, le défi principal du siècle prochain en conception des logiciels et en gestion des ressources sera de savoir quand il faut ouvrir — quand faut-il garder ses lignes de code secrètes, et quand faut-il ouvrir ses sources afin de mieux profiter de l'analyse critique de ses pairs et d'augmenter ses bénéfices sur les services et les marchés annexes.

Il existe une très forte motivation économique à ne pas manquer le moment où le passage en sources ouverts est rentable. Au-delà de ce moment, il existe un sérieux risque si vous tardez trop — un concurrent peut vous couper l'herbe sous le pied et ouvrir les sources de son logiciel dans le même secteur d'activité que vous.

La raison pour laquelle il ne faut pas manquer ce coche est que les utilisateurs et les talents disponibles pour participer aux logiciels à sources ouverts dans une catégorie donnée sont limités, et le recrutement a tendance à perdurer. Si deux producteurs sont le premier et le second à entrer dans une compétition fondée sur un marché à sources ouverts dans des secteurs similaires, le premier va probablement attirer la plupart des utilisateurs et les plus motivés des co-développeurs ; le second devra se contenter des restes. Le recrutement tend à perdurer, car les utilisateurs ont assimilé le logiciel et les développeurs investi du temps dans le programme lui-même.


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