|
Ténors de l'Informatique Libre Copyright © 1999 par Éditions O'Reilly
Chapitre 10. La stratégie commerciale fondée sur les logiciels Open SourceBrian Behlendorf
En 1997 et 1998, des logiciels libres tels que Linux, FreeBSD, Apache et Perl suscitèrent une attention croissante de la part d'un nouveau public composé de chefs de projet, de cadres, d'observateurs de tendance et d'investisseurs. La plupart des développeurs de ces logiciels accueillirent favorablement cet intérêt pour leur travail : pas uniquement parce que cela développait leur ego mais aussi parce qu'il leur permettait de justifier auprès de leurs supérieurs et de leurs collègues des efforts de plus en plus liés à leurs occupations professionnelles. Mais ce nouveau public posait des questions difficiles :
Je vous soumets l'idée que le modèle Open Source est indéniablement un modèle fiable de conduite du développement d'un logiciel commercial. Je veux essayer de vous montrer les conditions pré-requises pour un tel projet, quel type de projet se rattache à ce type de modèle, et les étapes qu'une entreprise devra franchir pour le lancer. Cet essai est destiné aux entreprises qui vendent des logiciels ou de l'assistance technique, ou qui utilisent un logiciel bien spécifique comme cœur de leur activité (idée de pièce maîtresse). Tout cela dépend des plates-formesBien que fervent partisan de l'approche Open Source en ce qui concerne les développements de logiciels, je reconnais volontiers que cette approche ne profitera pas toujours aux parties en présence. Elle exige des efforts, et les retours sur investissement ne sont jamais garantis. Une analyse correcte passe par la détermination des objectifs à long terme de l'entreprise et de ses points forts du moment. Commençons par un examen des "Application Programming Interfaces" (API) [1] des plates-formes et des conventions. Pour les besoins de cet essai, je m'attarderai sur les API (telles que celle du serveur Apache pour la mise au point de modules), les protocoles régissant l'activité en ligne (par exemple HTTP), et les « conventions » érigées par les développeurs de systèmes d'exploitation (telles que la façon dont Linux organise son système de fichiers, ou encore dont les serveurs NT sont administrés) et désignerai tout cela par le terme « plate-forme ». Win32, la collection de fonctions fournies et définies par Microsoft pour tous les développeurs d'applications MS-Windows 95 et NT, est une plate-forme. Si vous désirez développer une application destinée à des utilisateurs de MS-Windows, vous devez utiliser cette API. Si vous essayez, comme IBM le fit une fois avec OS/2, d'écrire un système d'exploitation qui puisse faire fonctionner des programmes mis au point pour Microsoft Windows, vous devez intégrer l'API Win32 dans son intégralité, afin d'être en mesure de l'exploiter. De la même manière la Common Gateway Interface (ou CGI) est une plate-forme. Les spécifications CGI permettent aux développeurs d'un serveur Web d'écrire des scripts et des programmes qui fonctionneront avec n'importe quel serveur Web. CGI est beaucoup plus simple que Win32 et bien sûr permet beaucoup moins, mais son existence était importante pour le marché des serveurs Web parce qu'il permet aux développeurs d'applications d'écrire un code portable, des programmes qui fonctionnent avec n'importe quel serveur Web. Une différence capitale entre CGI et Win32, outre leurs niveaux de complexité, est que nulle entité ne possède les spécifications de CGI, donc que tous les principaux serveurs Web la proposaient afin de pouvoir exécuter n'importe quel script CGI. C'est seulement après plusieurs années d'utilisation qu'il fut envisagé de définir la spécification CGI par un document d'Appel à commentaires (RFC) publié par l'Internet Engineering Task Force [2]. Une plate-forme est ce qui définit de façon précise un quelconque morceau de logiciel, que ce soit un navigateur comme Netscape ou bien un serveur Web comme Apache. Les plates-formes permettent de construire ou d'utiliser un morceau de logiciel par-dessus un autre, et elles ne sont pas seulement essentielles pour l'Internet, où des plates-formes usuelles comme HTTP et TCP/IP facilitent vraiment la progression très rapide de l'Internet, mais sont aussi en train de devenir de plus en plus déterminantes lors de la phase de conception d'un environnement informatique, dans le cas d'un serveur comme dans celui d'une machine réservée à l'utilisateur. Dans le cadre du projet Apache, nous avons eu la chance de développer d'emblée une API interne qui nous permette de distinguer d'une part les fonctionnalités centrales du serveur (chargé de gérer les connexions TCP, la coordination des sous-processus, et la gestion des requêtes HTTP de base), et, d'autre part, presque toutes les fonctionnalités de haut niveau comme le login, les modules CGI, les requêtes SSI (serveur side include), la configuration des paramètres de sécurité, etc. La richesse de cette API nous a aussi permis de mettre en place d'autres fonctionnalités importantes telles que mod_perl (un module d'Apache qui transforme le serveur Web en interpréteur Perl) et le mod_jserv (qui met en place l'API pour applets Java) afin de séparer les groupes de développeurs actifs. Le noyau du groupe de développement ne redouta donc pas de devoir non seulement maintenir et améliorer le cœur du serveur mais aussi construire un « monstre » destiné à servir et recueillir les fruits de ces efforts intensifs. Il existe des entreprises construites sur le modèle des plates-formes logicielles propriétaires. Elles peuvent tarifer tout usage de cette plate-forme sur la base d'une installation classique du logiciel, sur celle d'un paiement par utilisation, ou peut-être encore selon un autre modèle. Un copyright protège certaines d'entre elles, d'autres sont rendues opaques par l'absence de description rédigée pour le client ; d'autres encore évoluent si vite, parfois pour des raisons autres que techniques, que ceux qui tentent de les développer ne parviennent pas à suivre la cadence et semblent « à la traîne » sur le plan technique même si le problème ne relève pas de la programmation. Un tel modèle commercial, bénéfique même à court terme pour l'entreprise qui possède la plate-forme, agit contre les intérêts de toutes les autres sociétés et ralentit le progrès technique. Des concurrents demeureront incapables de profiter de leurs compétences ou tarifs très étudiés parce qu'ils n'ont pas accès à la plate-forme. D'un autre point de vue, le consommateur peut être dépendant d'une plate-forme et, lorsque les prix augmentent, se trouver forcé de décider entre payer un peu plus sur le court terme pour la plate-forme ou bien dépenser beaucoup d'argent afin d'adopter une plate-forme plus viable. Les ordinateurs et l'automatisation sont devenus si interdépendants et si essentiels pour l'entreprise qu'un responsable sensé ne doit pas confier à un seul fournisseur l'essentiel de son environnement. La possibilité de choisir un intervenant ne signifie pas seulement bénéficier du libre arbitre si certaines options sont trop coûteuses, et le coût d'un changement de plate-forme revêt à ce titre une importance capitale. Il peut être réduit si le logiciel n'est pas lié à la plate-forme. Les consommateurs gagnent donc à toujours exiger que le logiciel déployé soit adossé à une plate-forme non propriétaire. C'est difficile à concevoir parce que les courbes rendant compte de l'offre et de la demande n'ont de sens que tant que les produits à vendre ont un coût facilement évaluable. Par exemple lorsque la fabrication de dix exemplaires d'un produit est à peu près dix fois plus onéreuse que celle d'un seul. Personne n'aurait pu prévoir l'extraordinaire économie d'échelle dont profitent les éditeurs de logiciels commerciaux, l'absence de corrélation directe entre l'effort requis pour produire un logiciel et le nombre de personnes qui peuvent l'acheter et l'utiliser. Une personne ou un groupe qui produit des logiciels libres et qui crée un protocole fondamental ou une API est, à long terme, plus important pour la santé de cette plate-forme que deux ou trois créations indépendantes mais non libres. Pourquoi cela ? Parce qu'un concurrent peut acheter le produit commercial afin de le retirer du marché, réduisant à néant l'indépendance conférée aux utilisateurs par l'ouverture du logiciel. Cela peut aussi servir en tant que cadre académique ou référentiel de comparaison des réalisations et des comportements. Des organisations, par exemple l'IETF ou le W3C, constituent un forum de développement de standards ouverts, et œuvrent de façon quasi parfaite. Elles publient des documents généralement appréciés exposant comment les composants de l'Internet doivent interagir mais ne peuvent garantir le succès à long terme d'un standard donné, ni donc de sa pénétration. Ces organisations ne disposent d'aucun moyen d'imposer à leurs membres de créer des logiciels adossés aux protocoles ainsi définis. Le seul recours, parfois, consiste à fonder un groupe de travail capable de démontrer la supériorité de l'approche préconisée. Par exemple, en décembre 1996, AOL a modifié de façon apparemment négligeable son serveur mandataire (proxy), utilisé par ses clients afin d'accéder au Web. Cette « mise à jour » relevait d'une arrière-pensée politique : lorsqu'un utilisateur accédait à un site utilisant un serveur Apache 1.2, à l'époque tout récent et conforme aux spécifications du nouveau protocole HTTP/1.1, on lui souhaitait la bienvenue grâce à ce message précis :
Le noyau des développeurs Apache, alarmé, s'est réuni pour analyser la situation. Ils posèrent une question à l'équipe des techniciens d'AOL qui répondit :
Malheureusement, les ingénieurs d'AOL avaient l'impression erronée que les réponses HTTP/1.1 n'étaient pas compatibles avec les clients HTTP/1.0 ou les mandataires. Ils le sont pourtant. HTTP a été conçu de sorte que la compatibilité ascendante de toutes les révisions mineures d'une version (par exemple la version 1) reste assurée. Mais les spécifications pour HTTP/1.1 sont tellement complexes que sans une lecture complète et détaillée, on aurait pu croire que ce n'était pas le cas, et plus particulièrement avec les documents HTTP/1.1 disponibles à la fin de 1996. Nous, développeurs d'Apache, devions donc décider soit de faire marche arrière (donner des réponses HTTP/1.0 à des demandes HTTP/1.0), soit de respecter les conventions. Roy Fielding, notre « gardien du HTTP », fut en mesure de nous montrer clairement combien le comportement du logiciel à ce moment était correct et bénéfique ; il y aurait des cas où des clients HTTP/1.0 voudraient migrer vers une conversation HTTP/1.1 en découvrant que ce serveur la prend en charge. Il était aussi important d'indiquer aux mandataires qu'une première requête 1.0 vers un serveur pouvait être suivie d'un échange en 1.1. Nous décidâmes de camper sur nos positions et de demander à AOL de corriger son logiciel. Nous suspections que la réponse HTTP/1.1 qui posait actuellement un problème à leur logiciel était causée par leur négligence en matière de qualité de la programmation plutôt que par un défaut du protocole. L'expertise étayait notre décision. Apache gérait alors 40% des serveurs Web de l'Internet, et la version 1.2 était déjà fort répandue. Ils devaient donc décider de corriger leurs erreurs de programmation ou bien de déclarer à leurs utilisateurs qu'au moins 20% des sites Web de l'Internet leur seraient interdits. Le 26 décembre, nous avons publié une page Web décrivant la dispute, et diffusé l'information pour justifier notre action, non seulement à nos propres utilisateurs, mais aussi à plusieurs journaux importants tels que C|Net et Wired. AOL décida de corriger son programme. À peu près au même moment, nous avons annoncé la disponibilité d'une modification du code source d'Apache destinée aux gestionnaires de sites soucieux de contourner le problème d'AOL jusqu'à ce qu'il soit rectifié, une correction qui obligeait le logiciel à fournir une réponse en HTTP/1.0 aux requêtes issues d'AOL. Nous étions résolus à ce qu'elle reste une correction "non officielle", sans suite ni suivi, et qu'elle ne deviendrait pas la configuration par défaut de la distribution officielle. Plusieurs autres éditeurs de produits HTTP (dont Netscape et Microsoft) proposèrent des logiciels non compatibles avec Apache. Dans la plupart de ces cas, l'éditeur devait choisir entre résoudre ses bogues ou se passer des sites qui deviendraient alors inaccessibles. Dans la plupart des cas il implémentait délibérément le protocole de façon incorrecte sur ses serveurs et ses clients. Son produit fonctionnait alors normalement en milieu homogène (serveurs et clients de même marque), mais au mieux imparfaitement avec un serveur ou un client d'un concurrent. Cela posait des problèmes plus délicats que celui d'AOL, car dans certains cas la majorité des utilisateurs ne rencontre pas de dysfonctionnement patent. Les conséquences à long terme de ces bogues (ou de bogues additionnels augmentant le problème) ne seront perceptibles que lorsqu'il sera trop tard. Si aucun logiciel libre strictement conforme et très utilisé tel qu'Apache n'avait existé, les incompatibilités de ce genre auraient régulièrement augmenté et se seraient superposées, masquées par les mises en doute mutuelles et croisées ou des tours d'esprit Jedi (« Nous ne parvenons pas à reproduire le problème en laboratoire… »), où la réponse à « J'ai un problème quand je me connecte avec un navigateur X à un serveur Y » est, « Eh bien, utilisez le client Y et tout fonctionnera bien ». À la fin de ce processus, on aurait obtenu au moins deux Webs mondiaux — l'un construit avec le serveur Web X, l'autre avec Y, et chacun d'eux n'aurait servi que ses clients. Ce genre de sape du standard a connu plusieurs précédents historiques, tant cette politique (le « verrouillage ») se trouve ancrée dans la stratégie commerciale de nombreux éditeurs de logiciels. Bien sûr, ceci aurait été désastreux pour tout le monde car cela aurait condamné tout utilisateur du protocole HTTP (les fournisseurs de contenu et de services, les développeurs de logiciels ...) à maintenir deux serveurs distincts. Certains consommateurs firent peut-être pression afin de contraindre les fournisseurs à s'accorder sur le plan technique mais le marché invitait fermement ces derniers à « innover, différencier, mener l'industrie, définir la plate-forme », et cela aurait pu leur interdire de définir conjointement les protocoles utilisés. Nous avons en fait constaté un désastre de ce type avec la partie client de JavaScript. Les différents navigateurs Web, y compris les différentes versions bêta d'un même navigateur, présentaient de telles différences de comportement que les développeurs durent créer du code capable de détecter les différentes révisions afin de sélectionner une forme adéquate — ce qui augmenta les délais de réalisation des documents interactifs en JavaScript. Ce n'est que lorsque le W3C intervint et jeta les bases de DOM (Modèle Objet de Document) que l'on assista à une tentative sérieuse de créer un standard multipartite autour de JavaScript. Certaines forces naturelles du monde économique actuel poussent à la déviation lorsqu'un logiciel propriétaire est adossé à une spécification. Elle peut naître de la plus petite incompréhension du document de spécification, et se résorbera d'autant moins facilement qu'elle sera corrigée tard. J'affirme donc que construire ses services ou ses produits sur une plate-forme standard préserve la stabilité de votre activité économique. Le succès de l'Internet a montré non seulement combien les plates-formes communes facilitent la communication mais a aussi contraint les fournisseurs à penser davantage à comment ajouter de la valeur à l'information en transit plutôt qu'à vouloir tirer profit du réseau lui-même. Analyser les objectifs servis par un projet à code ouvertUne entreprise doit donc déterminer dans quelle mesure ses produits implémentent une nouvelle plate-forme, et jusqu'où son intérêt commercial découle de la survie de cette plate-forme propriétaire. Quelle part de votre gamme de produits et de services, et donc quelle fraction de vos revenus, se trouve au-dessus de cette plate-forme, et combien au-dessous ? C'est même probablement quelque chose que vous pouvez chiffrer. Supposons que vous éditiez un logiciel serveur de bases de données compatible avec de nombreux systèmes d'exploitation. Vous vendez séparément des logiciels d'administration graphique, des outils de développement rapide, une bibliothèque de procédures de base, etc. Vous proposez des contrats annuels d'assistance. Une mise à jour implique un nouvel achat. Vous assurez aussi des formations. Et votre groupe de conseillers croît rapidement et déploie votre logiciel auprès des utilisateurs. Votre balance de revenus ressemble par exemple à ceci :
À première vue vous ne pouvez envisager d'offrir votre logiciel serveur car sa vente engendre 40% de vos revenus. Avec de la chance vous réalisez des bénéfices, et si vous êtes encore plus chanceux votre marge de profit atteint 20%. Renoncer à 40% brise l'édifice. Cette analyse tient tant que l'équation ne varie pas. Il est cependant probable qu'elle change si vous étudiez correctement la question. Les serveurs de bases de données ne relèvent pas du groupe des applications que les entreprises achètent dans les rayons d'un magasin, installent, puis oublient. Toutes les autres catégories de revenus demeurent donc bien réelles et nécessaires quel que soit le prix du logiciel. Renoncer à facturer le serveur rend possible d'augmenter les autres services, car le coût du logiciel ne grève plus le budget des clients lorsqu'ils se procurent le serveur. En simplifiant à outrance, si les utilisateurs restent motivés pour acheter les prestations de conseil et d'assistance ainsi que les outils de développement et les bibliothèques, alors la gratuité ou le moindre coût de la base de données permet de l'utiliser sur deux fois plus de systèmes. Cela ajoute donc 20% au revenu total. Mieux : cette gratuité permettra à environ trois ou quatre fois plus de nouveaux utilisateurs de découvrir votre logiciel. Cela réduira la proportion assurée par les autres services (car certains se contenteront de la version gratuite et aussi parce que vos concurrents offriront des services pour votre produit) mais tant qu'elle ne diminue pas trop vous augmenterez votre revenu global. De plus, le coût de développement de votre logiciel diminuera si une licence appropriée le protège, notamment parce que des clients motivés corrigeront des bogues. La version standard intégrera peu à peu les efforts de ceux des consommateurs qui contribueront au projet de développement. Bref : vos coûts de développement diminueront. Dans le cas d'une gamme de produits semblable à celle de l'exemple choisi, la « libération » du logiciel principal ne favorisera guère les actions de vos concurrents destinées à mieux exploiter d'autres sources de revenus. D'ores et déjà des conseillers intègrent vos outils, des auteurs indépendants en parlent, et d'autres entreprises (encouragées par vous) proposent des bibliothèques de code. La disponibilité du code source aidera peu vos concurrents à proposer une assistance technique portant sur votre code mais, en tant que développeur originel, vous disposerez d'un avantage qu'ils devront surmonter. Tout n'est pas bleu et rose, bien sûr. Certains coûts liés à ce processus resteront difficiles à lier directement à un revenu. Le coût de l'infrastructure destinée à supporter cet effort, par exemple, n'est pas hors de portée mais peut mettre à l'épreuve les administrateurs de systèmes et le personnel assurant l'assistance technique. Il faudra y ajouter le coût de mise en place et de maintenance d'un canal de communication entre vos développeurs et le monde extérieur, et celui du développement d'un code ainsi publié, car la mise au point d'une version publiable du source s'avère parfois onéreuse. Après tout ce travail, le marché décidera peut-être que cette « libération » importe peu. Je fournirai à ce propos quelques réponses dans le reste de cet essai. Évaluer les besoins du marché pour votre projetUne entreprise perçoit souvent le logiciel libre comme un moyen de sauver un projet, de gagner en notoriété, ou simplement de placer de façon élégante une catégorie de produits sur une voie de garage. Ce ne sont pas de bonnes raisons pour lancer un projet Open Source, et une entreprise déterminée à poursuivre ce modèle a besoin de connaître exactement ce dont le produit a besoin pour garantir le succès d'une stratégie fondée sur du code ouvert. La première étape consiste en une étude de l'existant, donc de tous les concurrents commerciaux ou libres, même les plus modestes. Soyez très attentif afin de déterminer ce que votre produit offre en séparant les parties qui peuvent être potentiellement offertes avec un produit commercial, vendues, ou bien dont le code source peut être publié séparément. De même, n'excluez pas des combinaisons de logiciels libres et commerciaux qui offrent les mêmes services. Revenons à l'exemple du vendeur de base de données ci-dessus. Son produit comporte trois parties : un serveur SQL, un gestionnaire de transactions et de sauvegardes, et une bibliothèque de développement. Il ne doit pas seulement comparer ses produits avec ceux des leaders comme Oracle et Sybase, et ceux des petits concurrents dynamiques comme Solid et Velocis, mais aussi avec les bases de données libres telles que MySQL et Postgres. Une analyse de ce genre montrera peut-être que le serveur SQL apporte seulement quelques fonctionnalités supplémentaires à MySQL, et dans un domaine qui n'a jamais été considéré comme étant décisif sur le plan commercial mais simplement nécessaire pour rester en phase avec les concurrents. Le gestionnaire de sauvegardes et de transactions n'a aucun concurrent libre, et la bibliothèque Perl DBI surpasse la bibliothèque de développement proposée mais n'a pas de véritable concurrent en Java ou en C. Cette société pourrait envisager les stratégies suivantes :
Je ne proposerais pas la quatrième solution dans ce cas, car MySQL a une très nette avance ici, beaucoup d'ajouts, et de nombreux utilisateurs. Un projet de logiciel libre décline parfois à cause d'un manque de dynamisme des membres du noyau de l'équipe de développement, ou parce que le logiciel devrait s'affranchir des limites de sa propre architecture afin de satisfaire de nouveaux besoins, ou bien parce que la demande dépend d'un contexte révolu. Quand cela arrive, les gens cherchent alors d'autres solutions et il devient donc possible d'introduire un autre produit qui attirera l'attention même s'il ne constitue pas une avance significative sur le statu quo. La demande engendre de nouveaux projets de logiciels libres, son analyse est donc absolument nécessaire. Le développement d'Apache commença lorsqu'un groupe de webmestres partagèrent les corrections apportées au logiciel serveur Web du NCSA, puis décidèrent qu'échanger des corrections comme autant de cartes à collectionner restait peu efficace et sujet aux erreurs. Ils décidèrent donc de proposer une distribution séparée du serveur du NCSA incluant leurs modifications. Aucun des acteurs principaux des débuts ne s'est engagé parce qu'il voulait vendre un serveur commercial, bien que ce soit certainement une raison valable de le faire. Une analyse de la demande du marché pour un projet particulier de logiciel libre impose aussi de s'abonner aux listes de diffusion et les forums Usenet pertinents, de fouiller les archives, et d'interroger vos clients et leurs collègues. Alors seulement vous pouvez déterminer si certains souhaitent participer au projet. Revenons aux débuts du serveur Apache. Ceux d'entre nous qui échangions des corrections, les envoyions aussi au NCSA dans l'espoir de les voir inclus dans la distribution, ou tout au moins validés afin de nous faciliter leur intégration à des versions ultérieures. Puis Netscape embaucha certains des développeurs de ce serveur, et les autres ne parvinrent plus à gérer les messages électroniques expédiés par toutes les parties intéressées. Construire notre propre serveur fut plus une action d'auto-préservation qu'une tentative visant à proposer un serveur Web. Il est important de commencer avec des objectifs limités donc faciles à atteindre, et de ne pas devoir attendre que votre projet domine le marché avant de réaliser des bénéfices. Position des logiciels libres dans la gamme de logicielsPour déterminer quels composants d'un produit donné libérer, il peut être intéressant de conduire un exercice simple. Premièrement, dessinez une ligne représentant une gamme de produits. Sur la gauche, inscrivez le libellé « Infrastructure ». Cette partie comprendra les logiciels qui implémentent les systèmes et plates-formes, jusqu'au noyau, à TCP/IP, et même jusqu'au matériel. Sur la droite, inscrivez « Applications », représentant les outils et les applications destinés à l'utilisateur non technicien. Le long de cette ligne placez des points représentatifs, en termes relatifs, où vous pensez que se situe chacun des composants de vos logiciels. Dans l'exemple ci-dessus, les outils d'administration et les frontaux graphiques se trouvent à l'extrême droite, tandis que le code qui gère les sauvegardes se trouve à l'extrême gauche. Les bibliothèques de développement se trouve plutôt à proximité du centre, et le moteur SQL à gauche. Ensuite, vous pouvez placer les produits de vos concurrents, en les détaillant par composant et en utilisant un stylo de couleur différente pour distinguer les logiciels libres des produits commerciaux. Vous constaterez vraisemblablement ainsi, que les logiciels libres sont souvent placés à gauche et les offres commerciales à droite du graphique. Les logiciels libres sont donc plus souvent proches de l'infrastructure et des systèmes d'arrière-plan que de la gamme de logiciels représentée ici. Il y a plusieurs raisons à cela :
Voilà pourquoi nous constatons la présence de nombreux logiciels libres fiables pour les systèmes d'exploitation et les services réseaux, mais très peu pour les applications destinées à l'utilisateur. Des contre-exemples existent. Par exemple GIMP, programme de manipulation d'images GNU, un programme X11 comparable, dans ses fonctionnalités, au « Photoshop » d'Adobe. Déjà, par certains aspects, ce produit est aussi un outil d'infrastructure, une plate-forme, car il doit son succès à sa merveilleuse architecture modulaire et aux douzaines de compléments développés pour permettre d'importer et d'exporter de nombreux formats de fichiers différents et d'employer des centaines d'effets de filtres. Examinez à nouveau le graphique dessiné. Vous pouvez voir votre offre dans le contexte de vos concurrents, et dessiner une ligne verticale. Elle marque la séparation entre le code que vous libérerez et le reste. Cette ligne représente votre vraie plate-forme, votre interface entre le code public que vous essayez d'imposer comme standard sur la gauche, et le code propriétaire pour lequel vous souhaitez susciter de la demande sur la droite. La nature a horreur du videTout espace occupé par des logiciels commerciaux dans une infrastructure par ailleurs gagnée par le logiciel libre offre une forte motivation de redéveloppement dans l'espace public. Lorsqu'un mur commercial existe entre deux pièces de logiciels libres une sorte de force naturelle s'exerce afin de combler ce manque avec une solution publique parce qu'il peut être rempli avec des ressources suffisantes. S'il est suffisamment limité pour être traversé par votre entreprise avec votre propre équipe de développement, il est probable qu'il le soit suffisamment pour être comblé par un groupe de développeurs motivés. En ce qui concerne notre exemple de la base de données, mettons que vous décidiez de publier les sources de votre serveur SQL (ou de votre propre amélioration ajoutée à MySQL) mais que vous commercialisiez un pilote propriétaire assurant une interface avec un serveur Web permettant de créer des contenus dynamiques. Le serveur de données sera un point d'attraction favorisant ce produit, et vous augmenterez donc substantiellement les marges de ce composant. Relier une base de données à un serveur Web reste à la fois courant et recherché, les développeurs devront donc acquérir votre interface ou bien trouver un autre moyen d'accéder aux données depuis le serveur Web. Chaque développeur souhaitera économiser l'argent qu'il devrait vous verser. Si un nombre de développeurs suffisant mettent en commun leurs ressources, ou si une seule personne compétente ne peut simplement pas payer pour votre pilote mais veut quand même utiliser la base de données, il est possible que vous trouviez un beau matin un concurrent libre à votre offre commerciale, ce qui annihile votre avantage. Cet exemple reflète un concept plus large : s'appuyer sur un code source propriétaire dans une zone stratégique pour gagner de l'argent est devenu une aventure commerciale risquée. Si vous pouvez gagner de l'argent en assurant la l'assemblage du serveur Web, les interfaces et le serveur de données, ou en fournissant une interface qui gère ce système dans son ensemble, vous vous épargnerez ce type de surprise. Tous les logiciels commerciaux ne présentent pas cette vulnérabilité. C'est même une caractéristique spécifique aux logiciels commerciaux qui essayent de s'installer dans une niche directement entre deux logiciels libres bien établis. Présenter votre offre commerciale comme une addition aux logiciels libres est une stratégie bien plus solide. Dois-je offrir, ou bien me débrouiller seul ?Beaucoup de catégories de logiciels abritent des implémentations libres, surtout sur le marché des serveurs. Par exemple des systèmes d'exploitation, des serveurs Web, des serveurs de messagerie (SMTP, POP, IMAP), de news (NNTP), et de noms (DNS), des langages de programmation (la « glu » pour un contenu dynamique sur le Web), des bases de données, du code réseau en tout genre. Sur votre bureau on trouvera des éditeurs de texte comme Emacs, Nedit et Jove, des systèmes graphiques tels que Gnome et KDE, des navigateurs Web tel que Mozilla ainsi que des économiseurs d'écrans, des calculatrices, des organiseurs, des clients de messagerie, des outils pour le graphisme… La liste est longue. Bien que toutes les catégories ne recèlent pas de logiciels libres incontournables tels qu'Apache ou Bind, il y a très peu de niches commerciales sans au moins un concurrent libre en chantier. C'est beaucoup moins vrai pour la plate-forme Win32 que pour Unix ou Mac, principalement parce que la communauté ne la juge pas suffisamment libre. Si un logiciel libre rencontre le succès dans une catégorie qui recoupe votre offre potentielle ne négligez pas que participer à son développement en y ajoutant de nouveaux modules permettra d'améliorer aussi le source de votre produit, de prendre un avantage sur le plan marketing, ou d'établir une plate-forme commune. Afin de déterminer si cette stratégie est acceptable on doit étudier sa licence :
Satisfaire les développeurs est probablement le plus grand défi pour le modèle de développement du logiciel libre, on ne peut pas vraiment y répondre avec un amoncellement de techniques ni même avec de l'argent. Chaque développeur doit réaliser qu'il contribue au projet, que vous ne négligez pas ses questions et ses commentaires sur l'architecture et la conception du projet, et que le fruit de ses efforts sera intégré dans la distribution ou qu'il recevra une explication détaillée des raisons pour lesquelles il ne peut l'être. Beaucoup se trompent car déclarent : « Le modèle de développement des logiciels libres fonctionne car, grâce à lui, l'Internet tout entier devient votre service de Recherche & Développement et de gestion de la Qualité ! ». En pratique le nombre total de développeurs disponibles capables de mener à bien une mission donnée reste limité, mieux vaut donc éviter qu'un projet parallèle naisse à cause d'une dispute d'importance secondaire séparant les développeurs. Mais la sélection naturelle fonctionne au mieux lorsque les projets luttent afin de profiter des ressources. Maintenir deux projets en compétition dans la même niche lorsque les développeurs ne manquent pas permettra à l'une des parties d'innover d'une façon totalement nouvelle pour les autres. Le domaine du serveur SMTP offre un bel exemple de compétition salutaire. Le programme libre Sendmail d'Eric Allman régna longtemps sans partage, puis des concurrents apparurent, par exemple Smail et Zmailer. Mais Qmail, de Dan Bernstein, convainquit le premier de nombreux utilisateurs. Sendmail avait à ce moment 20 ans et commençait à accuser le poids des années. Il n'est pas conçu pour l'Internet de la fin des années 90, où les attaques par dépassement de la capacité des tampons (buffer overflow) et refus de service (denial of service) sont aussi fréquents que la pluie en Bretagne. Qmail fut à plus d'un titre une coupure radicale. La conception du programme, son administration, et même son mode opératoire étaient nouveaux. Sendmail ne peut vraisemblablement pas le rejoindre. Non parce qu'Allman et son équipe ne sont pas de bons programmeurs ou ne reçoivent pas d'aide efficace et motivée mais simplement parce que seul un changement radical de Sendmail leur permettrait d'explorer de nouvelles voies. Pour des raisons similaires IBM finance le développement du serveur SMTP SecureMailer de Wietse Venema, qui semble aussi devenir populaire en ce moment. Le domaine du serveur SMTP est suffisamment défini et important pour pouvoir soutenir plusieurs projets de logiciels libres. L'avenir dira lesquels survivront. AmorçageIl est essentiel pour la santé d'un projet à code ouvert de profiter d'un élan grâce auquel il d'évoluera, et de répondre à de nouveaux défis. Le monde du logiciel ne connaît rien de statique, et chaque composant majeur restera maintenu et amélioré. L'un des avantages de ce modèle est qu'il réduit la quantité de développement attribuée à chaque groupe. Vous avez donc besoin d'autres développeurs actifs. Durant la phase de détermination de la demande vous rencontrerez probablement un groupe d'autres entreprises et de personnes suffisamment intéressés pour former un noyau de développeurs. Exposez-leur les grandes lignes de votre stratégie, sans la fixer. Il peut être utile de créer une liste de diffusion pour discuter de ce projet avant de fixer quoi que ce soit. Ce groupe émettra probablement des idées pertinentes et dressera une liste de ses propres ressources mobilisables. Dans le cas d'un projet peu ambitieux les volontaires pourront ne s'engager qu'à essayer votre produit et rester abonnés à la liste de diffusion. Il faudra, sinon, quantifier les ressources disponibles. Voici les ressources minimum pour un projet de complexité modérée, comme par exemple le développement d'un outil générique de gestion d'un panier d'achats sur le Web, ou d'un nouveau type de serveur réseau implémentant un protocole simple. Je décrirai ci-après les rôles et types de compétences.
Ces cinq rôles occupent presque trois personnes à plein temps. En réalité un groupe de personnes partageant les responsabilités pourront partager les responsabilités afférentes, et certains projets survivront, sitôt les premiers obstacles de publication franchis, alors que le niveau d'implication moyen des participants ne dépasse pas cinq heures hebdomadaires. Mais au début du projet les développeurs doivent concentrer leurs efforts comme s'il s'agissait d'un classique projet industriel d'entreprise. Ces cinq rôles n'assureront aucun nouveau développement, tout cela ne relève que de la maintenance. Si vous ne trouvez pas assez de ressources auprès de collègues et de partenaires pour assurer tout cela ainsi qu'un nombre suffisant de nouveaux développeurs chargés du travail de base (jusqu'à ce que de nouvelles recrues se présentent) vous devriez reconsidérer la publication du code de votre projet. Quelle licence adopter ?Déterminer quelle licence utiliser pour votre projet s'avérera parfois difficile. Vous n'apprécierez probablement pas cette étude, mais votre service juridique s'en chargera. D'autres documents et sites Web traitent en détail de ces questions liées à la propriété industrielle. Je vais me contenter de proposer une vue générale sur la portée commerciale de chaque style de licence. La licence de style BSDApache et les projets de systèmes d'exploitation issus de BSD (FreeBSD, OpenBSD, NetBSD) l'emploient, et il peut être résumé par : « Voilà le code, employez-le comme bon vous semble, cela m'est égal. Mais faites toujours état de sa provenance. ». D'ordinaire, cette reconnaissance de l'origine est requise sous différentes formes (publicité, fichier LISEZ-MOI, ou dans la documentation imprimée, etc). D'aucuns affirment que cette exigence rend l'approche incompatible avec toute mise à l'échelle, c'est-à-dire que si quelqu'un publie un ensemble comprenant 40 modules libres sous licence BSD différents il pourrait y avoir 40 notes de copyright à afficher. En pratique cela ne pose jamais de problème, et en fait certains perçoivent ces exigences comme autant de forces positives destinées à faire prendre conscience de l'importance des logiciels libres. Dans une perspective commerciale la licence BSD offre le meilleur contexte légal à tout nouveau participant, car elle ne laisse peser aucune inquiétude quant aux restrictions d'utilisation ou de redistribution. Vous pouvez mélanger ou comparer ce logiciel avec votre propre code propriétaire, et ne publier que ce qui, selon vous, fait progresser le projet et vous aide en retour. C'est pourquoi nous l'avons choisie pour Apache. Notre logiciel a été lancé par des webmestres commerciaux en quête d'un meilleur serveur Web pour leurs propres besoins commerciaux, contexte fort différent de celui que connurent beaucoup d'autres projets libres en phase de gestation. Vraisemblablement aucun des membres de l'équipe d'origine ne se proposait de créer un serveur commercial, aucun de nous ne savait ce que le futur nous apporterait, et nous ne souhaitions pas limiter de prime abord nos possibilités de choix. Le groupe des développeurs d'Apache a aussi adopté ce type de licence car elle hisse à merveille un code donné en tant qu'implémentation de référence d'un protocole ou d'un service commun. Beaucoup souhaitaient voir HTTP survivre et devenir un vrai standard pluripartite, et nous n'étions absolument pas opposés à ce que Microsoft ou Netscape incorporent dans leurs produits notre moteur HTTP ou un quelconque autre composant de notre code si cela favorisait davantage l'érection de HTTP en tant que standard commun. Ce degré d'ouverture comporte des risques. La licence ne contient aucune incitation destinée à encourager les entreprises à contribuer à améliorer le code, et donc le projet en retour. Il y a certainement eu dans l'histoire d'Apache des cas où des entreprises ont développé à partir d'Apache des approches que nous aurions voulues voir réincorporées. Mais une licence exigeant cela aurait peut-être a priori condamné de telles améliorations. Tout cela signifie que, sur le plan stratégique, le projet a besoin d'un élan continu, et que les participants doivent réaliser davantage de bénéfices en contribuant au projet qu'en conservant par-devers eux leurs modifications. Cet état demeure délicat à maintenir, surtout si une entreprise décide d'augmenter le volume des efforts de développement qu'elle consacre à un projet dérivé et commence à douter du retour potentiel en proportion de sa contribution au projet. Les responsables s'exclament : « Nous menons à bien davantage de travail que tous les autres regroupés, et pourquoi devons-nous partager ? ». Je ne détiens pas de formule magique adaptée à ce scénario, mais affirme qu'en ce cas l'entreprise créatrice n'a probablement pas trouvé le meilleur moyen de susciter efficacement des contributions de tierces parties. La licence publique de Mozilla (MPL)L'équipe Mozilla de Netscape a mis au point la licence publique de Mozilla afin de protéger son projet. Cette dernière, parue plusieurs années après les autres, doit résoudre certains problèmes cruciaux posés par les licences BSD et GNU. Son style, dans le corps des groupes Open Source, ressemble surtout à celui de la licence BSD. Elles présentent toutefois deux différences majeures : La MPL requiert que les modifications apportées à la « distribution » soient aussi publiées sous MPL, et restent ainsi intégrables au projet. « Distribution » désigne ici les fichiers du code source distribués. Cette importante disposition permet à une entreprise d'ajouter une interface à une bibliothèque de code propriétaire sans exiger que les autres bibliothèques de code soient aussi diffusées sous MPL, elle ne concerne que l'interface. Le logiciel ainsi couvert peut être plus ou moins inclus dans un environnement de produit commercial. Plusieurs clauses de la MPL protègent à la fois le projet dans son ensemble et ses développeurs contre un brevet déposé sur le code contribué. Elle impose que l'entreprise ou la personne contribuant au projet abandonne tout droit découlant du code. Il ne faut pas négliger l'importance de cette seconde clause, mais elle contient aussi aujourd'hui un gros défaut. S'atteler à la question du brevet est une Très Bonne Chose. Une entreprise pourrait offrir le code à un projet afin d'essayer, après son intégration, de revendiquer ses droits pour son utilisation. Une telle stratégie commerciale pourrait paraître risible et serait très regrettable, mais malheureusement certaines sociétés n'ont pas encore saisi cela. Ainsi, la seconde clause interdit à quiconque de fournir subrepticement du code qu'il sait breveté, et de créer par là-même des ennuis à tous les autres participants. Cela ne signifie pas qu'un tiers, détenteur d'un brevet, se manifeste ensuite. Aucun instrument légal n'offre de protection contre cela. En fait, je défendrais que cela doit faire l'objet d'une mission confiée à un nouveau service du bureau américain des brevets géré par le ministère du commerce et de l'industrie qui semble détenir le pouvoir d'attribuer certaines idées ou certains algorithmes et devraient donc être en mesure, réciproquement, de certifier qu'un code proposé est libre de droits, épargnant ainsi a priori au donateur tout tracas juridique. Comme je l'ai dit ci-dessus, la licence MPL actuelle (décembre 1998) contient un défaut. Par essence, la section 2.2 précise (dans sa définition de « version du contributeur ») que le contributeur renonce aux droits sur toute partie de Mozilla et non seulement sur le code soumis. Cela ne semble pas fâcheux. De grandes entreprises collaboreraient ainsi sans contrainte. Malheureusement, une certaine grosse entreprise détentrice de l'un des plus gros portefeuilles de brevets y voit un problème majeur. Non parce qu'elle a l'intention de demander un jour à Mozilla des royalties, ce qui paraîtrait fort téméraire. Mais elle est concernée car certaines parties de Mozilla utilisent des procédés dont elle détient les brevets grâce auxquels perçoit régulièrement d'importantes sommes d'argent. Elle ne souhaite donc pas renoncer à ses brevets sur le code de Mozilla, car les entreprises qui paient pour employer ces techniques incluraient alors le code de Mozilla correspondant dans leurs produits, sans leur servir de rente. Si la section 2.2 se référait simplement aux corrections contribuées plutôt qu'à l'ensemble du navigateur pour le renoncement aux brevets, ceci ne poserait pas de problème. La licence MPL, si l'on écarte cette bizarrerie, demeure remarquablement solide. Exiger le retour des changements vers le « noyau » implique l'intégration des corrections essentielles de bogues et des améliorations, et laisse des entités commerciales développer des fonctionnalités à valeur ajoutée. La MPL reste peut-être la licence la plus adéquate pour des applications destinées à l'utilisateur final, où il est plus probable que les brevets posent problème, et où le dynamisme mène à la diversification des produits sous-jacents. Au contraire, la licence BSD est peut-être plus appropriée dans le cas d'un projet destiné à rester « invisible » ou de la réalisation de bibliothèques de fonctions essentielles, comme par exemple un système d'exploitation ou un serveur Web. La licence publique GNU (GNU Public Licence, GPL)Bien qu'à première vue elle n'incite guère au commerce, certains aspects de la licence GNU sont, croyez-le ou non, favorables à des objectifs commerciaux. Fondamentalement, la GPL requiert la publication sous une même licence des améliorations, des dérivés, et même du code qui incorpore un code sous GPL. Des tenants du logiciel libre défendirent cette disposition « infectieuse » car elle constitue selon eux un moyen de s'assurer que le code libre le demeure et qu'aucune entité ne propose sa propre version du logiciel sans la rendre publique. Ceux qui placent leur logiciel sous GPL préfèrent priver le projet d'une contribution plutôt que de risquer de ne pouvoir l'utiliser librement. Cette approche présente un certain attrait d'ordre théorique, bien sûr, et certains affirment que le succès de Linux doit beaucoup à la GPL, car une récupération commerciale, très tentante, aurait sinon perturbé de façon décisive la cohérence de son développement. Ainsi, à première vue, la GPL semble peu compatible avec tout objectif commercial lié au logiciel libre. Les modèles traditionnels grâce auxquels la plus-value du logiciel se matérialise sous forme d'argent paraissent a priori écartés. Elle pourrait toutefois offrir un moyen extraordinairement efficace d'établir une plate-forme interdisant à un concurrent de proposer la sienne, et donc de vous protéger lorsque vous vous déclarez premier fournisseur de biens et de services pour elle. La relation entre Cygnus™ et GCC illustrent bien cela. L'entreprise Cygnus™ assure de fréquentes et nombreuses modifications de GCC en le portant vers différents types de matériels. Elle verse la plus grande partie de ces modifications, en accord avec la GPL, sous forme de contributions à la distribution de GCC, et les rend donc disponibles. Cygnus™ facture ses prestations de portage et de maintenance, et non le code lui-même. L'histoire de Cygnus™ et de sa prééminence sur ce marché en font une société de référence pour ce type de service. Si un concurrent tentait de concurrencer Cygnus™, il lui faudrait redistribuer ses modifications sous GPL. Cela signifie que GCC ne lui offrirait aucune niche technique ou commerciale exploitable sans donner à Cygnus™ la même occasion d'en prendre avantage. Cygnus™ a créé une situation dans laquelle les concurrents ne peuvent la concurrencer sur le plan technique, à moins de dépenser beaucoup de temps et d'argent et d'utiliser une autre plate-forme que GCC. La GPL peut aussi être utilisée à des fins commerciales en tant que sentinelle technologique, proposée avec une version non GPL du même logiciel. Examinons par exemple le cas d'un excellent programme de chiffrement des connexions TCP/IP. Vous ne vous souciez pas des utilisations non commerciales ou même commerciales mais souhaitez percevoir des droits lorsque d'autres entreprises incluent le code dans un produit ou le redistribuent et réalisent des bénéfices. Si vous placez le code sous GPL, nul ne peut l'intégrer librement dans un produit commercial sans le placer sous GPL, et la plupart d'entre eux s'y refuseront. Cependant, si vous maintenez une branche séparée de votre projet non protégée par la GPL vous pouvez la breveter. Vous devez toutefois vous assurer que tout code apporté par des tiers est explicitement rendu disponible pour cette branche commerciale en déclarant que vous en restez seul auteur et restez libre d'y intégrer tout code soumis pour intégration dans la version sous GPL. Cela offre à certaines entreprises un modèle commerciale viable. Transvirtual, à Berkeley, applique ce schéma à une machine virtuelle Java légère et à un projet de bibliothèque de classes. Selon certains le nombre de contributeurs attirés par un tel modèle s'avérera faible et les versions GPL et non GPL convergeront donc. À mon sens si vous traitez les contributeurs comme il se doit, peut-être même en leur offrant de l'argent ou tout autre forme de compensation (ils épaulent, après tout, votre approche commerciale), ce modèle devrait fonctionner. Le champ d'action de la licence Open Source évoluera à mesure que les gens valideront les approches efficaces et écarteront les autres. Vous restez libre de mettre au point une nouvelle licence placée où bon vous semble dans le spectre disponible (représenté par BSD à ma droite et GPL à ma gauche). Ne négligez pas que ceux qui utilisent et étendent votre code se sentiront d'autant plus incités à continuer qu'ils se sentiront libres. Les outils d'aide à la création de Projets à code ouvertLe projet Apache dispose d'outils de conduite partagée du développement, bien entretenus et fort efficaces. Le plus important parmi ceux-ci est CVS ou « Concurrent Versioning System » (un « Système de gestion des révisions »). Il s'agit d'une collection de programmes maintenant un répertoire de code partagé puis assurant sa mise à jour au gré des modifications en mémorisant les dates et les noms de leurs auteurs. De nombreuses personnes agissent ainsi simultanément sur le même programme sans se gêner mutuellement. Le processus de déverminage s'en trouve aussi facilité du fait que CVS rend possible d'examiner un à un tous les changements survenus afin de trouver l'origine exacte d'un bogue donné. Le code client de CVS, disponible pour toutes les plates-formes majeures, fonctionne tout-à-fait correctement via des lignes téléphoniques et sur des connexions longues distances. SSH en assure si nécessaire la confidentialité tout en gérant les habilitations. Le projet Apache n'utilise pas seulement CVS pour mettre à jour le code source mais aussi pour mettre à jour le fichier STATUS dans lequel nous plaçons toutes les questions importantes et les descriptions commentées et raisonnées d'innovations majeures, et même les résultats de scrutins liés à chaque question-clé. CVS enregistre aussi les bulletins de vote émis lors des prises de décisions du groupe, maintient les documents de notre site Web, gère la documentation de développement, etc. En bref, il constitue à la fois notre coffre-fort et notre livret de gestion du savoir. Sa simplicité peut effrayer (la plupart des logiciels de cette catégorie sont chers et très touffus) mais, en pratique, est l'une de ses plus grandes qualités. Tous ses composants, côté serveur comme côté client, sont libres. Un projet aux sources libres doit offrir un solide ensemble de forums de discussion à ses développeurs et utilisateurs. Le logiciel utilisé importe peu (nous employons Majordomo, mais Ezmlm ou Smartlist ou n'importe quel équivalent rendrait autant de services). Il faut consacrer une liste à chaque sous-groupe cohérent de développeurs, de sorte qu'ils sélectionnent eux-même les thèmes traités et restent proches. Créer, de plus, une liste séparée pour chaque projet grâce à laquelle le serveur CVS diffuse des avis de changements effectués est aussi très important car cela offre aux participants le moyen d'examiner au fur et à mesure les modifications effectuées. Cette approche invite tout un chacun à respecter les standards de codage et facilite la recherche des bogues. Mieux vaut séparer les listes des utilisateurs de celles des développeurs, et peut-être même, si le nombre de participants augmente, le noyau des développeurs activistes des autres. Préserver les archives des listes disponibles publiquement afin de laisser les utilisateurs y chercher des réponses à leurs questions. Un projet bien mené comprend aussi un outil de suivi des bogues et des versions. Dans le cadre du projet Apache nous utilisons un outil GNU appelé GNATS. Il gère parfaitement plus de 3000 rapports de bogues, et les corrections correspondantes. Vous voulez trouver un outil grâce auquel de nombreuses personnes pourront répondre à des rapports de bogues, certaines en se spécialisant sur des éléments donnés du projet, capable de diffuser des informations par la messagerie électronique et d'interagir grâce à cette dernière plutôt qu'exclusivement via le Web. Adoptez un outil facile à exploiter et automatisable, afin que les développeurs répondent de façon aisée (la plupart d'entre eux n'apprécient guère cette phase) et aussi de sorte qu'ils retrouvent facilement tout bogue déjà découvert. Cette base de données deviendra de fait le dépôt de la connaissance périphérique à votre projet. Une telle base de données doit permettre de répondre à la traditionnelle question « Pourquoi tel comportement est-il une fonctionnalité et non un bogue ? » L'approche Open Source n'est pas la panacée éliminant à l'avance toute menace. Non seulement parce que des conditions favorables restent toujours nécessaires, mais aussi parce que la gestion d'un développement en cours exige une extraordinaire somme de travail. Dans de nombreux cas vous devrez, en tant que promoteur d'un nouveau projet, agir un peu comme le docteur Frankenstein, mélangeant ici des éléments et appliquant là une tension électrique afin de donner vie à votre création. Bonne chance.
Notes
|