Articles sur l'Open Source

Créée en 1989, Cygnus Solutions™ fut la toute première, et selon un rapport du magazine Forbes en août 1998, c'est aujourd'hui la plus importante entreprise fondée sur les logiciels libres. Son produit phare, le kit de développement GNUPro, est le leader du marché des compilateurs et des débogueurs pour logiciels embarqués. Cygnus compte parmi ses clients les plus grands fabricants de microprocesseurs, et des leaders dans le domaine de l'électronique grand public, de l'Internet, des télécommunications, de l'automatisation, des réseaux, de l'aérospatiale ou de l'automobile. Son siège se trouve à Sunnyvale, en Californie, elle a des bureaux à Atlanta, Cambridge, Tokyo et Toronto, et des employés en divers endroits allant de l'Australie à l'Oregon. Cygnus est la plus grande entreprise à capitaux privés dans l'industrie du logiciel embarqué, plus importante que deux entreprises à capitaux publics et sur le points de dépasser la troisième entreprise par ordre d'importance. Avec une croissance du chiffre d'affaires de 65 % depuis 1992, Cygnus a figuré dans le Top 100 de la croissance du CA du San Jose Business Journal's. Elle figure maintenant dans la Software 500 list (tous secteurs confondus).

Dans cet article, je décrirai le modèle du logiciel libre qui est la clé de notre succès, et la manière dont nous continuons à le revoir et à l'améliorer afin de progresser.

Ce n'est que le 13 novembre 1989 que nous avons reçu la lettre du California Department of Corporations nous informant que notre demande était approuvée, que nous pouvions déposer notre capital de 6000$; et commencer notre activité sous le nom de « Cygnus Support ». C'était l'aboutissement d'un projet né plus de 2 ans auparavant, et le début d'une aventure qui continue encore aujourd'hui, presque 10 ans plus tard.

Cette vision a commencé de façon relativement innocente. Mon père m'a dit un jour : « Quand tu lis un livre, lis-le de la première à la dernière page ». Comme tous les conseils paternels, celui-ci ne fut appliqué que lorsque j'en avais envie. En 1987, trouvant mon travail de plus en plus ennuyeux, je commençai à m'intéresser aux logiciels GNU, et je décidai de lire le GNU Emacs Manual, publié à compte d'auteur par Richard Stallman, de la première à la dernière page (aucun éditeur n'avait voulu publier ce livre, car ses lecteurs étaient non seulement autorisés mais encore encouragés à en faire des copies gratuites. De fait, même aujourd'hui, c'est un concept toujours difficile à expliquer aux éditeurs).

Emacs est un programme fascinant. Bien plus qu'un éditeur de texte; il avait été étendu pour permettre de lire son courrier électronique, les forums Usenet, exploiter un shell, lancer des compilations et déboguer les programmes résultants; il donne même accès à l'interprète Lisp™ sur lequel il repose. Des utilisateurs inventifs (ou, ce qui revient au même, des hackers qui s'ennuyaient) avaient ajouté des fonctions saugrenues comme le mode doctor de psychanalyse automatique inspiré du programme ELIZA de John Mc Carthy, ou encore le mode dissociated-press qui réarrange le texte de façon bizarre et très amusante. Il y a même un programme qui dessine et anime la solution du problème des tours de Hanoï (sur un écran de texte !). C'étaient cette profondeur et cette richesse qui m'ont donné envie d'en savoir plus, de lire le manuel et le code source d'Emacs.

Le dernier chapitre de ce livre, le « manifeste GNU », est une réponse personnelle de l'auteur à la question qui m'a travaillé durant toute ma lecture, à savoir : pourquoi un programme aussi bon est-il disponible gratuitement avec ses sources et librement redistribuable, en un mot libre ? Stallman répond à la question plus générale suivante :

On ne peut pas citer tout le « Manifeste » ici. On dira simplement que s'il ressemble en surface à un pamphlet socialiste, j'ai voulu y voir autre chose. En fait j'y ai vu un business plan. L'idée est simple : le logiciel libre unifie les efforts des programmeurs du monde entier, et des entreprises proposant des services (personnalisation, améliorations, corrections, assistance technique) pour ces logiciels profiteraient des économies d'échelle et du fort pouvoir d'attraction de cette nouvelle espèce de logiciel.

Emacs n'était pas le seul programme époustouflant de la Free Software Foundation. Il y avait le débogueur GNU (gdb), que Stallman a dû écrire parce que les débogueurs de DEC (maintenant filiale de Compaq) et de Sun n'étaient pas assez puissants pour un programme aussi complexe qu'Emacs. Non seulement ce programme pouvait tolérer une charge importante, mais il le faisait avec élégance : ses commandes et ses extensions étaient vraiment adaptées aux programmeurs. Et comme c'était un logiciel libre, des programmeurs n'ont pas tardé à ajouter d'autres extensions qui l'ont rendu encore plus puissant. Les logiciels propriétaires n'offraient pas ce type d'extensibilité.

Mais la vraie bombe tomba en juin 1987, lorsque Stallman publia la version 1.0 du compilateur C de GNU, gcc. Je l'ai immédiatement téléchargé et j'ai utilisé tous les trucs du manuel de gdb et d'Emacs pour maîtriser rapidement ses 110 000 lignes de code. La première version du compilateur de Stallman était compatible avec deux plates-formes : le vénérable VAX et les nouvelles stations Sun3. Il générait un code qui tenait la dragée haute aux compilateurs de DEC et Sun. J'ai porté gcc sur le nouveau processeur 32032 de National Semiconductor. Le résultat était 20 % plus rapide que le compilateur propriétaire fourni par National. Après deux semaines de bitouilles supplémentaires, j'ai porté la différence à 40 % (on a souvent dit que la puce de National n'a pas connu le succès parce qu'elle ne délivrait pas 1 Mips et ne concurrençait donc pas le 68020 de Motorola. Or les benchmarks faits avec des applications lui donnaient juste 0,75 Mips à sa sortie. Mais 140 % x 0,75 Mips = 1,05 Mips. Combien les piètres performances de ce compilateur coûtèrent-elles à National SemiConductor ?). Les compilateurs, les débogueurs et les éditeurs sont les trois principaux outils du programmeur dans sa vie quotidienne. gcc, gdb et Emacs étaient tellement supérieurs aux outils propriétaires que je ne pouvais m'empêcher de songer à la quantité d'argent qu'on pourrait gagner en substituant aux outils propriétaires ces programmes meilleurs et aux progrès plus rapides.

Bien qu'il ne soit pas écrit avec des pincettes, le « manifeste GNU » est en fait un document rationnel. Il dissèque la nature profonde des logiciels, de la programmation, de la grande tradition universitaire, et conclut à une obligation morale de partager gratuitement l'information qu'on a reçu gratuitement, indépendamment des conséquences financières. J'ai atteint une conclusion différente, qui m'a valu de longues discussions avec Stallman. Si je pense que la liberté d'utiliser de distribuer et de modifier le logiciel prendra le pas sur tout modèle visant à limiter la liberté, ce n'est pas pour des raisons éthiques mais à cause de la loi du marché.

Au début j'essayais d'argumenter de la même manière que Stallman : en vantant les qualités des logiciels libres. J'expliquais comment la liberté était le moteur d'une plus grande innovation à des coûts plus bas, permettait des économies d'échelle grâce à des standards plus ouverts, etc. Et les gens répondaient : « C'est une grande idée mais ça ne fonctionnera pas car personne ne voudra payer pour des logiciels gratuits. ». Après deux ans passés à perfectionner ma rhétorique, à affûter mes arguments, à porter la bonne parole aux gens qui me payaient pour voyager dans le monde entier, je n'avais jamais été plus loin que « C'est une grande idée, mais... », lorsque j'eus ma seconde illumination : si tout le monde pense que c'est une idée géniale, c'est sans doute une idée géniale, et si personne ne pense que ça va marcher, je n'aurai pas de concurrent !

Vous ne verrez jamais un livre de physique où la loi de Newton est introduite de cette manière; pourtant, mathématiquement parlant c'est strictement équivalent à « F = ma ». Ce que je veux dire par là, c'est qu'en faisant bien attention aux signes, on peut inverser les membres d'une équation sans remettre en cause sa validité. Faire de l'argent en offrant une assistance de nature commerciale pour des logiciels gratuits paraissait impossible parce que les gens, obnubilés par ce signe « - », oubliaient de le compter de l'autre côté du signe égal.

Avant de laisser tomber ma thèse à Stanford pour créer une entreprise, il ne me restait plus qu'à répondre une question, largement hypothétique au demeurant. Supposons un instant que j'aie assez d'argent pour acheter n'importe quelle technique propriétaire (celle de Sun ou Digital, par exemple). Combien de temps pourrais-je gagner de l'argent avant que quelqu'un d'autre lance une entreprise avec les outils GNU et m'expulse du marché ? Pourrais-je seulement récupérer mon investissement initial ? Quand j'ai compris combien être en compétition avec des logiciels libres est une position inconfortable, j'ai su que le temps était venu.

Dans cette section, je détaillerai la théorie du logiciel libre comme modèle commercial et la façon dont nous avons essayé de la mettre en pratique. Nous commencerons par quelques réflexions célèbres :

Le concept d'une économie du libre marché est si vaste que j'aime à plaisanter, chaque année, lors de la remise du Nobel d'économie, en disant qu'il est allé à celui qui a paraphrasé Adam Smith le plus élégamment. Mais toute blague mise à part, il existe un potentiel immense et inexploité, qui n'attend que d'être mis en valeur par un marché du logiciel vraiment libre.

Du temps d'Adam Smith, le libéralisme économique concernait surtout les particuliers : les marchés plus vastes, et spécialement les échanges entres nations, étaient très contrôlés. Lorsque les hommes d'affaires en eurent assez du système royal, ils se sont révoltés et ont créé un nouveau système de gouvernement qui s'occupait moins de leurs affaires. De fait, leur conception de la liberté dicta la Constitution des États-Unis, et elle semble partout à l'origine de nombre d'actions politiques et économiques. Qu'est-ce qui rend la liberté si attirante ? Et pourquoi liberté et prospérité économique sont-elles si étroitement liées ?

Clairement, en ce qui concerne les outils pour programmeurs en 1989, les logiciels propriétaires étaient dans un état lamentable. D'abord, les outils étaient primitifs et offraient des fonctionnalités limitées. Ensuite ils avaient souvent des limitations arbitraires qui pouvaient devenir rédhibitoires lorsque les projets étaient complexes. Enfin, l'assistance technique proposée par les éditeurs de logiciels était horrible. À moins d'être un gros client et de pouvoir utiliser le pouvoir du portefeuille pour faire pression, on était sans recours quand on tombait sur un os. Enfin, chaque vendeur avait ses propres extensions propriétaires, ce qui faisait que quand on avait commencé à utiliser les maigres fonctionnalités d'une plate-forme, on se liait à elle, d'abord de façon imperceptible, puis de manière tout-à-fait inextricable. De fait, le modèle des logiciels propriétaires fonctionnait si mal que c'était intéressant à observer.

Encore de nos jours, l'économie de marché fonctionne à l'intérieur des murs des éditeurs de logiciels propriétaires (où les ingénieurs, les groupes de production sont en compétition pour obtenir des fonds et des avantages). À l'extérieur, l'utilisation et la distribution des logiciels est étroitement contrôlée par des brevets, des licences, et des secrets commerciaux. On peut seulement imaginer l'énergie et l'efficacité qui sont perdues par cette pratique de la liberté au niveau micro-économique seulement.

Dans la vision simpliste des éditeurs de logiciels, une fois que vous avez créé un logiciel assez bon pour que des gens veuillent l'acheter, faire des copies de ce logiciel est peu ou prou équivalent à copier des billets de banque : ça ne coûte quasiment rien et ça peut rapporter gros. Je pense qu'une des raisons pour lesquelles les logiciels étaient si misérables dans les années 1980 est que les gens se focalisaient sur le modèle idéal de l'impression de billets de banque, sans ce soucier de ce qui arriverait quand les gens commenceront à utiliser les liquidités. L'assistance était considéré comme un sous-produit dégénéré des défauts du logiciels, et minimiser son coût revenait donc à maximiser les bénéfices.

C'était frustrant pour les utilisateurs, mais tout aussi néfaste aux logiciels eux-mêmes. Des fonctionnalités pourtant faciles à ajouter avaient souvent été rejetées pour cause de « manque d'intérêt stratégique ». Sans accès au code source, des fonctionnalités que les clients auraient été capables d'ajouter eux-mêmes restaient objets de spéculation et de contestation. Et au final les département marketing des éditeurs définissaient seuls l'espace de la concurrence, avec une myriade de fonctions inutiles mais tape-à-l'œil. Le libéralisme économique marchait à l'envers !

C'est très bien d'avoir des théories merveilleuses pour bâtir un monde meilleur. C'est une autre paire de manches que d'amener ces théories au point où elles se tiennent debout d'elles-mêmes. Bien que les entreprises de service soient rares à cette époque, il y avait des exemples à étudier dans d'autres domaines.

Regardons la pratique de la justice aux États-Unis (ou en Grande-Bretagne). La loi commune est disponible gratuitement pour quiconque veut l'utiliser. Pas besoin de licence pour utiliser un texte de loi dans son argumentaire. De fait, les décisions législatives, quel qu'ait été le coût de leur production, sont accessibles à tous. Pourtant, les avocats sont parmi les professionnels les plus chers qui soient. Comment un avocat peut-il faire autant d'argent sans détenir aucun savoir propriétaire ?

Ce n'est pas seulement l'acte de poursuivre en justice que les gens estiment tant. C'est la valeur cumulée de ces actes. Si vous engagez un bon avocat et qu'une décision de justice est prise en votre avantage,cette décision devient un précédent qui fait jurisprudence et s'ajoute à la loi. La justice n'est pas aveugle, elle est chargée d'histoire.

Le travail des avocats n'est pas sans analogies avec la création et la maintenance de standards pour les logiciels libres. Créer un bon standard coûte très cher. Mais travailler sans aucun standard ou maintenir un mauvais standard coûte bien davantage ! D'où l'intérêt d'avoir des gens valables pour travailler sur les logiciels qui seront les standards de demain. Au début, nous croyions que les gens comprendraient cet intérêt, et nous paieraient pour créer des logiciels libres de grande qualité qui deviendraient les standards de facto dans le monde du logiciel.

Les débuts de Cygnus

Ayant bien exploré la théorie, il était temps de la mettre en pratique. Créer une entreprise de services est assez facile, pour peu qu'on sache un peu gérer une entreprise. Malheureusement, aucun des trois fondateurs n'avait d'expérience dans ce domaine.

Nous avons lu des livres sur la création d'entreprise pour savoir enregistrer notre société, établir nos statuts, et autres formalités. Pour chaque penny sur lequel nous avons radiné durant la première année, nous avons dû débourser des milliers de dollars par la suite. Il n'est cependant pas évident que nous aurions pu faire mieux en achetant des conseils professionnels, car le premier de ces conseils que nous avons pris nous a coûté des centaines de dollars par heure, plus des dizaines de milliers pour se débarrasser définitivement du problème. Ces chiffres en disent long sur notre incapacité à juger l'importance des problèmes légaux et corporatifs et à demander les bons conseils, mais aussi sur la singulière incompétence des nombreux avocats avec lesquels nous avons parlé.

Ayant créé un modèle économique complètement nouveau, nous avons également créé nos concepts pour la finance, le marketing, les ventes, l'information des clients, et l'assistance. Chacune de ces créations nous a bien servi pendant la première année, si chaotique qu'elle fût, et chacun faisait ce qui était nécessaire pour faire décoller l'entreprise, mais ces concepts ont dû être complètement revus quand l'entreprise a grandi.

Pour combattre le chaos, nous avons travaillé dur à simplifier le principe de notre business : nous proposions un service d'assistance technique reconnu pour des logiciels techniques reconnus, en utilisant les économies d'échelle pour faire des bénéfices. D'après notre estimation, nous proposions une assistance deux à quatre fois meilleure que celle des ingénieurs maison, à un tarif deux à quatre fois moindre. Nous ne mettions pas trop l'accent sur les histoires de logiciels libres parce que c'était encore bien trop flou pour être vendable. Nous nous efforcions de donner aux gens de meilleurs outils pour moins cher, et contrat par contrat, nous avons appris comment faire.

Nous avons signé notre premier contrat en Février 1990, et à la fin du mois d'avril, nous avions pour 150000 dollars de contrats. En mai, nous avons envoyé des lettres à 50 candidats potentiels pour notre service et en juin, à 100 autres. Soudain, l'entreprise devenait une réalité. À la fin de la première année nous avions pour 725,000 dollars de contrats et partout surgissaient de nouvelles occasions.

Ce franc succès a entraîné de sérieux problèmes. En vendant nos services pour la moitié ou le quart de ce que coûterait la même chose en interne, nous avions signé des contrats pour 1,5, voire 3 millions de dollars. Mais nous n'étions que 5 : un vendeur, un étudiant à temps partiel, et les trois fondateurs qui s'occupaient de tout, depuis le branchement des câbles Ethernet jusqu'à la conception des lettres à en-tête. En suivant le même taux de croissance, combien de nuits blanches nous faudrait-il pour en arriver là ? Personne ne le savait, car nous n'avions ni modèle financier, ni méthode opérationnelle.

GNUPro

Nous avons décidé de réaliser des économies d'échelle avant que l'usure devienne un problème. En vrais ingénieurs, nous avons décidé que le moyen le plus rapide de concrétiser ces économies était de se concentrer sur le plus petit sous-ensemble de logiciels libres que nous pouvions raisonnablement vendre comme une solution utile. Plus il serait petit, pensions-nous, et puis le déploiement en grandeur réelle serait facile.

En faisant l'impasse sur les outils du shell, les utilitaires, les programmes de contrôle de version, et même sur un noyau libre pour le 386 d'Intel, nous avons décidé de vendre le compilateur et le débogueur GNU comme un produit prêt-à-l'emploi. Il y avait une bonne dizaine d'entreprises qui vendaient des compilateurs 32 bits fabriqués par d'autres, et autant de compilateurs conçus par des sociétés comme Sun, HP, ou IBM. En nous jetant dans la mêlée, nous avions l'impression qu'en dominant le marché des compilateurs 32 bits, nous deviendrions assez gros pour nous lancer dans d'autres projets (une gamme complète de logiciels libres, analogue au modèle de sous-traitance d'EDS pour les systèmes IBM).

Le compilateur GNU existait déjà sur des dizaines d'environnements et permettait de compiler vers plus de 10 architectures cibles (j'avais réalisé 6 de ces portages moi-même), ce qui en faisait un des compilateurs ayant le plus de portages au monde. Le débogueur GNU fonctionnait sur 5 plates-formes pour le code natif, et plusieurs personnes l'avaient adapté pour les systèmes embarqués. Fort naïvement, nous pensions que fabriquer un produit tout fait consisterait juste à rassembler des octets de divers provenances en une distribution, écrire un README et un script d'installation, ajouter quelques produits auxiliaires, tester le tout, et le distribuer. La réalité s'avéra beaucoup moins rose.

D'abord, gcc était dans la difficile transition entre la version 1.42 et la 2.0. La version 1 de gcc était meilleure que la plupart des compilateurs sur les machines CISC comme le 68000 ou le VAX. Mais pour la rendre compétitive sur les puces RISC, beaucoup d'optimisations étaient nécessaires. Le premier portage de gcc pour le processeur SPARC, en 1988, était 20 % plus lent que le compilateur de Sun. En 1989 j'ai écrit un séquenceur d'instructions qui a ramené l'écart à 10 % et la même année, en optimisant les branchements, j'ai encore gagné 5 %. Avec la transition générale du CISC vers le RISC, ce qui était le meilleur compilateur sous tous les aspects devenait un choix moins évident, dont le client devait évaluer les avantages et les inconvénients. C'était beaucoup plus difficile à vendre.

Ensuite, GNU C++ était en perte de vitesse. J'ai écrit GNU C++ en 1987, c'était alors le premier compilateur de code natif pour C++. Le C++ est un langage beaucoup plus complexe que le C, et il était encore en mutation quand nous avons lancé Cygnus. En 1990, plusieurs fonctionnalités nouvelles, encore plus complexes, devinrent « standard » et avec le surmenage lié à Cygnus, je n'avais pas le temps de le maintenir à jour.

Troisièmement, gdb était en mille morceaux. Alors que gcc et g++ sont restés raisonnablement cohérents, avec des nouvelles versions émanant régulièrement d'un site central, gdb souffrait de fragmentation. Les adversaires du logiciel libre argumentent souvent en disant que l'avantage des logiciels propriétaires est qu'il n'y a qu'une version « officielle », tandis que chacun fait ses bitouilles dans son coin avec les logiciels libres, sans que se dégage un « standard » légitime. En l'absence d'un responsable, il se fragmentait donc, et des milliers de gens avaient leur propre version.

Quatrième difficulté, nous n'avions pas une chaîne d'outils complète. Nous avions un assembleur, un éditeur de liens, et d'autres outils (les fameux binutils) qui fonctionnaient sur certaines des plates-formes prises en charge par gcc et gdb, mais pas sur toutes, loin s'en fallait. En fait, si on faisait l'intersection des plates-formes prises en charge par gcc avec celles qui peuvent employer gdb, puis avec gas, gld, etc. on obtenait l'ensemble vide.

Cinq, nous n'avions pas de bibliothèque C, ce qui n'était pas un problème pour les plates-formes natives comme Sun ou HP, mais un enjeu capital pour les développeurs de systèmes embarqués, qui avaient besoin de construire des applications autonomes.

Sixième obstacle : nos concurrents ne pouvaient certainement pas égaler nos prouesses d'ingénierie just-in-time, mais ils avaient tous des produits déjà complets qu'ils vendaient avec beaucoup d'efficacité, chacun dans son marché de niche. En mettant sur pied et en vendant un produit tout fait, nous changions de plan : ce n'était plus une attaque sur le flanc, mais un assaut frontal contre des entreprises engendrant 10 ou 100 fois notre chiffre d'affaires.

Enfin, avions-nous confiance nous-mêmes en ce que nous faisions ? Ce qui est agréable quand on joue le rôle des intégrateurs de beaucoup d'outils évoluant très vite, c'est qu'on ressent très nettement que les gens ont besoin de vous. Les esprits sceptiques contestaient la notion même d'un logiciel libre tout emballé prêt-à-l'emploi en disant : dès que nous aurons sorti un produit qui franchira les tests de qualité, notre assistance deviendra inutile et en 6 mois nous n'aurons plus de travail. C'était un défi pour notre métier que j'ai entendu maintes fois dans les quatre années qui ont suivi.

Nous n'avions rien de mieux à faire que de nous mettre au travail, et avec un calendrier initial de 6 mois, nous sommes tombés d'accord pour mettre les bouchées doubles afin d'y arriver. J'étais chargé de mener la barque de jour, et la nuit je collaborais au travail pour gcc 2.0 et g++. David Henkel-Wallace (alias Gumby), le second fondateur de Cygnus, s'occupait des binutils et de la bibliothèque en plus de ses occupations comme Directeur Général et Directeur du « Support ». Et John Gilmore, le troisième larron, a pris gdb. Nous avons engagé du monde pour nous aider à :

Six mois plus tard, nous avions incroyablement avancé dans notre travail, et certains commencèrent à trouver trop restrictive notre focalisation sur un unique produit (gcc). Le compilateur GNU resta notre principal fonds de commerce, mais nous avons commencé à signer des contrats pour d'autres logiciels, comme Kerberos (un système de sécurité réseau), Emacs, et même pour notre système de test et de recherche de bogues (qui était encore en cours de développement à l'époque).

John avait publia un article Usenet dont voici un résumé : « je suis le nouveau responsable de gdb. Si vous voulez que les fonctions que vous avez programmé fassent partie de la prochaine version et soient maintenues dans le futur, envoyez-moi les sources complètes et je verrai comment les intégrer ». En six semaines, il reçut 137 versions de gdb (des bitouillages de la version 3.5 pour la plupart), chacune ayant une ou plusieurs fonctionnalités ajoutées. Il a commencé à concevoir gdb 4.0 afin d'inclure toutes ces fonctions supplémentaires. Comment aurais-je osé lui dire que c'était impossible, puisqu'il l'a fait ?

Gumby a décidé que tous les utilitaires pour travailler sur les formats binaires devraient utiliser la même bibliothèque, qui décrirait tous les fichiers objet et formats de débogage connus. La raison de ce choix est claire quand on regarde les fonctions des différents outils qui interviennent en aval du compilateur :

Tableau 5-1. Utilitaires de manipulation de fichiers binaires

Outil	Lit le format	Écrit selon le format
gcc	ASCII	ASCII
as	ASCII	Binaire
ar	Binaire	Binaire
ld	Binaire	Binaire
size	Binaire	Binaire
strip	Binaire	Binaire
binary	Binaire	Binaire
Nm	Binaire	Binaire
gdb	Binaire	Binaire

Chacun de ces outils avait sa propre méthode pour lire ou écrire des fichiers au format binaire, et ils ne géraient pas tous les mêmes architectures et les mêmes formats : a.out, b.out, coff, ecoff, xcoff, elf, ieee695, et j'en passe. Si on faisait une correction dans l'assembleur pour puce 68000 au format a.out, on devait la réécrire dans tous les outils agissant sur ce format. Les changements étaient parfois faits de façon générique pour certains outils et de façon spécifique au format a.out pour d'autres !

En construisant une bibliothèque unique qui rassemblait toutes les fonctions dans le même code source, on pouvait réaliser plus vite des économies d'échelle car tous les outils auraient un comportement cohérent. De plus, ce serait possible de lier un fichier objet a.out avec une librairie au format coff pour produire un exécutable ieee695 ! Gumby a commencé à écrire cette bibliothèque. Il en a discuté avec Stallman, qui a affirmé que ce serait trop difficile — il fallait réécrire tous les outils et la maintenance serait impossible. Gumby lui a répliqué que ce p… de job n'était pas infaisable (d'où le nom de la bibliothèque : BFD pour Big F**cking Deal, ou Binary File Descriptor, au choix).

Pendant que John et Gumby hackaient, j'avais toujours à vendre des contrats pour garantir une source de revenus. Chaque trimestre j'avais de nouveaux objectifs à atteindre et devais donc signer plus de contrats, et tous nos meilleurs ingénieurs étaient occupés par cette version pour laquelle nous n'avions aucune visibilité. Des tensions naquirent entre le secteur des ventes et celui des développeurs lorsque le modèle du logiciel libre paraissait fonctionner à l'envers : plus on s'occupait des logiciels GNU, moins on recevait de choses par l'Internet ; nous assurions plus de 50 % du développement de la chaîne de logiciels GNU.

Ce n'était pas non plus une situation temporaire. Il aura fallu un an et demi avant d'arriver à la première version officielle. En ce jour mémorable, j'étais certain que pour la première fois, un atelier de développement C/C++ complet pouvait être construit à partir d'un code source unique sur deux plates-formes : Sun3 et Sun4. J'étais stupéfait : j'avais écrit six portages de gcc, 3 portages de gdb, un compilateur natif et un débogueur C++ en moins de temps qu'il en avait fallu à une équipe de hackers pour obtenir deux ensembles d'outils cohérents !?

Il y avait des circonstances atténuantes : premièrement, les outils marchaient mieux que jamais, et offraient plus de fonctionnalités ; deuxièmement, à cause du travail architectural accompli (nous avions non seulement réécrit les outils, mais aussi développé un script de configuration et mis en place toute une infrastructure de test automatique), il était théoriquement plus facile de réaliser des portages pour d'autres combinaisons hôte/cible, y compris pour un nombre illimité de systèmes embarqués.

Nous avons mis notre système à l'épreuve, et il a passé tous les tests haut la main :

Tableau 5-2. Nombre de systèmes pris en charge au cours du temps

Date	Nom de code	Systèmes natifs	Systèmes embarqués	Total
Mars 1992	p1	2	0	2
Juin 1992	p2	5	0	5
Septembre 1992	p3	5	10	15
Décembre 1992	p4	5	20	25
Mars 1993	q1	5	30	35
Juin 1993	q2	5	45	50
Septembre 1993	q3	7	53	60
Décembre 1993	q4	8	67	75
Mars 1994	r1	10	75	85
Juin 1994	r2	10	80	90
Septembre 1994	r3	10	85	95
Décembre 1994	r4	10	90	100

Pendant que nos ingénieurs faisaient des prouesses pour créer GNUPro, notre équipe de commerciaux cherchait le meilleur moyen de le vendre. En 1991, nous avons engagé une jeune étudiante, récemment licenciée par Applied Materials, qui voulait apprendre comment vendre des logiciels. Bien que l'anglais ne soit pas sa langue maternelle, elle s'y est mis très vite. Étant tout sauf une bitouilleuse (bien qu'elle ait passé quelques week-ends à apprendre le C), elle est devenue l'un des meilleurs avocats des logiciels libres. Après six mois de succès, elle m'a invité à assister à une de ses présentations aux clients. J'étais estomaqué. J'avais toujours vendu les logiciels libres comme un hacker, en insistant sur les mérites techniques. Elle, de son côté, vantait la complexité du travail que nous faisions et la valeur des logiciels que nous fournissions, pour expliquer finalement aux clients qu'ils devraient acheter chez nous plutôt que d'essayer de travailler avec leurs ingénieurs. Je mettais en avant le fait que nos ingénieurs étaient meilleurs que les leurs (un message que peu de décideurs apprécient), alors qu'elle expliquait comment leurs ingénieurs pourraient bénéficier du travail de fond que nous accomplissions quand au portage, à la configuration et à la maintenance. Au total, en combinant les prouesses techniques et une bonne politique commerciale, Cygnus connut une grande croissance :

Tableau 5-3. Croissance économique de la société

Réservations	Rentabilité ( %)	Taux de croissance
1990 : 725	epsilon	N/A
1991 : 1500	1	106 %
1992 : 2800	2	96 %
1993 : 4800	3	87 %
1994 : 5700	4	67 %

Issues de notre effort, des technologies importantes ont été rendues à l'Internet et sont devenues des standards en eux-mêmes : GNU configure (un script de configuration générique tenant compte de trois paramètres indépendants : le système sur lequel on compile le logiciel, le système hôte et la plate-forme cible), autoconf (un script de haut niveau pour créer des scripts configure), automake (un générateur de Makefile pour des environnements gérés par autoconf), DejaGNU (une infrastructure pour les tests de non-régression), GNATS (un système de gestion des problèmes signalés), et j'en oublie.

Aujourd'hui, l'atelier GNUPro est compatible avec plus de 175 combinaisons hôte/cible, nombre qui plafonne à cause de la diversité actuelle du marché plutôt qu'à cause d'une limitation intrinsèque de notre technologie.

De fait, GNUPro est maintenant si bien installé que plusieurs de nos concurrents ont annoncé un service d'assistance pour les logiciels GNU, nous provoquant sur notre propre terrain ! Le modèle des logiciels libres vient heureusement une fois de plus à la rescousse. À moins qu'un concurrent puisse travailler autant que nos 100 ingénieurs, pour la plupart auteurs ou responsables de la maintenance des logiciels pour lesquels nous proposons du service, il ne peut nous chasser de la position de source GNU authentique (nous fournissons 80 % des modification apportées à gcc, gdb et consorts). Le mieux qu'il puissent espérer est d'ajouter des fonctions supplémentaires pour lesquelles leurs clients payeraient. Mais les logiciels étant des logiciels libres, toute modification ou valeur ajoutée à ces logiciels revient gratuitement à Cygnus qui peut décider de l'intégrer ou non. Alors que le combat dans la sphère des logiciels propriétaires ressemble à un duel pour la vie ou la mort, la compétition sur des logiciels libres se déroule sur un ruban de Moebius : tout ce qui disparaît d'un côté réapparaît de l'autre, et finalement tout profite à l'auteur principal. Donc, si nos concurrents peuvent gagner certaines batailles grâce au « C'est un logiciel GNU, moi aussi, je peux en profiter », Cygnus reste le grand bénéficiaire sur le long terme. Ayant commencé en 1989, nous avons 10 ans d'avance sur tous les autres.

Les grands défis

Notre taux de croissance reste impressionnant, mais il s'est ralenti au fur et à mesure de notre développement. Pendant que nous essayions de vanter les vertus des logiciels libres, les sceptiques et les clients éventuels mettaient notre modèle à l'épreuve par rapport aux points suivants :

Essayez de vous imaginer la situation suivante : vous tentez de signer un contrat de 10 000 $ avec le responsable d'une équipe de 5 programmeurs pour systèmes embarqués, et il vous appelle pour savoir si oui ou non Cygnus peut émettre des actions dans le public étant donné son modèle commercial ! Autant, sur le plan technique, les logiciels libres nous ont ouvert des portes, étant les produits les plus aboutis et les plus innovants, autant ils se sont révélés un obstacle majeur lorsque nous avons attaqué le marché. Nous avons appris à nos dépens ce que Geoffroy Moore exprime dans son livre Crossing the Chasm (la traversée de l'abîme).

Cette difficulté m'est apparue clairement le jour où j'ai rendu visite à un groupe de programmeurs qui concevaient des réseaux de communication sans fil dans une entreprise qui figurait au Fortune 100. Dans le cadre de leur politique de qualité, ils évaluaient non seulement leur propre travail mais aussi leurs fournisseurs, selon un certain nombre de critères. La plupart de leurs fournisseurs étaient notés « Très bon » ou « Excellent » par rapport à tous les critères. Mais le fournisseur des outils pour systèmes embarqués arrivait bon dernier avec un « Médiocre » ou « Inacceptable » dans chaque catégorie, et ce pour chacune des trois années où la qualité avait été évaluée. Pourtant, ils ne voulaient pas acheter nos outils, en dépit des recommandations (qui venaient de leurs propres clients !) que nous pouvions leur présenter, de notre supériorité technique et de nos prix imbattables. Pourquoi ? Parce que les responsables ne voulaient pas miser sur une solution déroutante, à laquelle ils n'étaient pas habitués. Je les ai laissés en leur demandant pourquoi ils se fatiguaient à évaluer la qualité s'ils n'utilisaient pas les données ainsi récoltées, mais ce n'était pas la bonne attitude. J'aurais plutôt dû réaliser que cette frilosité est un comportement typique du marché, et que la solution n'est pas de culpabiliser les clients, mais plutôt d'améliorer notre communication et notre marketing.

Nos problèmes ne venaient cependant pas seulement de l'extérieur. À tout moment de notre croissance, beaucoup de clients n'arrivaient pas à croire que nous arriverions à embaucher suffisamment de monde pour grandir bien au-delà de notre état actuel. Ils avaient à la fois raison et tort. Pour ce qui est des ingénieurs, ils avaient tort. Cygnus a été fondée par des ingénieurs, et notre culture d'entreprise, le pouvoir d'attraction des logiciels libres et la réputation de plus importante équipe à travailler sur les logiciels libres nous attiraient tous les développeurs que nous voulions engager. Et notre taux de renouvellement pour cause de départs était quelque chose entre le quart et le dixième de la moyenne nationale (surtout si l'on regarde du côté de la Silicon Valley).

Mais engager des commerciaux, c'était une autre paire de manches. La plupart partageaient les préjugés et les doutes de nos gros clients, et n'avaient aucune envie de travailler pour Cygnus. Ceux qui travaillaient pour nous le faisaient sans motivation. Ceux qui étaient motivés l'étaient souvent pour de mauvaises raisons. Il fut un temps où pour cinquante ingénieurs, nous n'avions que deux commerciaux. La communication, la gestion, et la satisfaction des employés déclinaient pendant que les commerciaux essayaient en vain de se familiariser avec ce que signifie la gestion d'une entreprise de logiciels libres.

Ironie du sort, nous avons aussi dû refuser la candidature de commerciaux qui n'acceptaient pas qu'on ajoute des composants propriétaires à nos produits. Les logiciels libres étaient une stratégie pour nous, pas une philosophie, et nous ne voulions pas engager de gens qui n'étaient pas assez souples pour gérer des produits libres ou non afin d'atteindre les grands objectifs de l'entreprise.

Nous avons fini par accepter le fait qu'on ne peut pas engager de commerciaux qui comprennent bien les tenants et les aboutissants du logiciel libre. Nous avons dû accepter leurs erreurs (ce qui signifie budgéter le coût de ces erreurs), et eux de tirer parti de ces erreurs pour progresser. La plupart d'entre eux arrivent avec une certaine expérience et tentent d'adapter la réalité afin qu'elle coïncide avec cette expérience — source intarissable de problèmes pour Cygnus. Il était très difficile de trouver des gens capables de gérer d'après leur expérience mais aussi d'apprendre sur le tas, et assez vite. Et nous avions besoin de dizaines de commerciaux !

Le modèle des logiciels libres, ainsi mis à l'épreuve, s'est révélé à la fois très souple et très résistant. Bien que nous ayons parfois perdu des clients dont les attentes étaient déçues ou mal remplies, notre rendement annuel est resté approximativement à 90 % par dollar depuis 1993, et la principale cause du départ des clients resta la cessation d'activité après la fin normale du contrat. Deux choses nous ont aidés à survivre là où d'autres n'auraient pas résisté : d'abord chaque employé, indépendamment de son grade, reconnaissait à quel point la satisfaction des besoins des clients est importante; personne n'était « au-dessus » de l'assistance à la clientèle. Ensuite, lorsque toute autre solution avait échoué, il restait au client la possibilité de se dépatouiller tout seul (puisque tous les clients avaient le code source). Ainsi, malgré d'innombrables difficultés durant ces années-là, très peu de clients ont été laissés complètement sans issue parce que le logiciel ne faisait pas son travail. Contraste énorme si on songe aux histoires que nous avons entendues à propos de logiciels propriétaires concurrents, ou encore de logiciels libres sans service d'assistance.

Trouver des fonds au-delà des logiciels libres — eCos

Dans le monde des systèmes embarqués, il y a un nombre relativement restreint de fondeurs (qui fabriquent les puces) et d'assembleurs (OEM). Le reste du marché se constitue de petits acteurs qui font des choses intéressantes, mais dont aucun n'a le volume nécessaire pour commander la conception de nouvelles puces ou de nouvelles solutions logicielles.

Entre les fondeurs et les assembleurs on trouvait des centaines de petits éditeurs de logiciels, chacun vendant son produit. Par exemple, il existe plus de 120 systèmes d'exploitation Temps Réel (SETR) commerciaux. Aucun ne dépasse les 6 % de part de marché, selon l'IDC. C'est comparable au monde Unix il y a dix ans, en dix fois plus fragmenté. Cette situation conduit à une dégénérescence bien connue de l'économie de marché : redondance, incompatibilités, escroqueries sur les prix, etc. Ce que les fondeurs et les assembleurs voulaient, c'était des standards pour accélérer le TTM (Time to Money) ; mais les éditeurs de systèmes d'exploitation Temps Réel demandaient ou trop de temps, ou trop d'argent, ou encore les deux.

Nous étions l'étoile montante du marché des systèmes embarqués : nous grandissions deux fois plus vite que le leader de notre marché, en laissant nos quatre principaux concurrents avec une croissance à un chiffre. Cependant, nous n'étions pas de vrais leaders du marché, nous n'étions pas reconnus comme tels. En 1995, après de longues discussions avec nos principaux clients sur ce qui n'allait pas dans le monde des systèmes embarqués, nous avons commencé à comprendre que seuls les compilateurs de débogueurs GNUPro pourraient résoudre vraiment leurs problèmes. Ce dont les clients avaient besoin, c'est une couche d'abstraction entre le silicium et les programmes, qui leur permette de ne voir que la bibliothèque C standard ou encore une API POSIX temps réel. C'était une nouvelle occasion d'étendre notre offre de manière non triviale.

Nous avons taillé nos crayons et pris note des faits évidents : plus de 120 éditeurs et plus de 1000 SETR « maison », cela signifiait que du point de vue technique, personne n'avait su créer un SETR suffisamment souple pour convenir à tous les usages; et du point de vue commercial, nous avons noté que les royalties pour l'usage de ces SETR étouffaient le marché, donc notre SETR devrait être sans royalties. Autrement dit, pour consolider le marché autour de nos produits, nous avions besoin de créer une technologie entièrement nouvelle, utilisable mondialement. Et nous devions la donner en retour. Les responsables ont traîné des pieds pendant un an avant de finalement se lancer dans cette idée.

Une fois que nous avions décidé notre stratégie, nos commerciaux continuaient à nous titiller avec la question : « Comment allons-nous faire de l'argent avec ça ? ». Alors même que notre domination avec GNUPro se renforçait, ce n'était pas évident pour eux de savoir comment nous pourrions réitérer le même succès avec un système d'exploitation pour systèmes embarqués.

Nous avons fait ce que toutes les entreprises font lorsqu'elles sont face à des contradictions : nous avons posé des axiomes. En supposant que nous saurions toujours faire de l'argent, nous avons pensé aux N autres problèmes qu'il fallait résoudre pour aider nos clients et devenir numéro 1. Nous devions :

Développer des logiciels coûte cher, et développer un produit donné selon un calendrier fixé coûte bien plus cher encore.

Lorsque nous avons lancé Cygnus, nous avions tous supposé que les investisseurs ne comprendraient jamais ce que nous faisions, et qu'on n'aurait pas besoin d'eux avant cinq ans, voire plus. Fort heureusement, nous étions dans l'erreur sur les deux tableaux.

Le premier membre de la direction venu de l'extérieur, Philippe Courtot, n'a pas mis longtemps à me présenter à des investisseurs en 1992. J'étais très ouvert avec chacun d'eux au sujet de notre modèle, de notre technologie, de nos objectifs, et j'expliquais aussi que nous étions une entreprise à fonds propres, et que nous n'avions pas besoin de leur argent. De fait, nous arrivions à augmenter notre rentabilité d'un point chaque année tout en gardant un taux de croissance de 80 %. Roger McNamee, un analyste reconnu de l'industrie des logiciels, l'a exprimé très bien lorsqu'il a dit : « Je suis à la fois enthousiasmé et surpris par votre modèle commercial. Je suis emballé par la façon dont ça marche, mais plus j'y pense, et plus je me demande pourquoi je n'ai pas eu l'idée avant ! »

C'était bien sûr gratifiant de penser que nous avions si bien réussi que nous n'avions pas besoin de financement extérieur, mais en réalité, en 1996, nous avions ouvert de telles perspectives derrière notre produit « GNUPro » que nous avions besoin de nouveaux objectifs et de nouveaux partenaires.

Nous avons trouvé deux investisseurs, Greylock Management et August Capital, qui comprenaient qui on était et ce qu'on faisait, et pouvaient avancer assez d'argent pour mettre notre plan à exécution. Ils ont investi 6,25 millions de dollars, le plus gros placement privé dans une entreprise de logiciels de la première moitié de 1997, et la réalisation a suivi de près.

Pendant que l'équipe technique travaillait, les commerciaux continuaient à bosser sur la manière de faire de l'argent, car au tout début nous n'avions pas vu le rapport entre l'architecture de l'eCos et le modèle commercial utilisé pour le vendre. Du point de vue technique, nous savions que la configurabilité était la clé de l'existence d'un produit « taille unique » qui conviendrait à tous. Du point de vue du commerce, nous savions qu'un système d'exploitation « taille unique » était le moyen d'unifier le marché autour d'un standard valable pour le développement des systèmes embarqués. Pendant un an et demi, chacun traitait le problème de son côté. Incapable d'assumer le paradoxe des logiciels libres, beaucoup de commerciaux n'y arrivaient pas.

Lorsque les ingénieurs furent en mesure d'exhiber ce qu'ils avait seulement imaginé au début, c'est devenu clair pour tout le monde : nous étions en train de créer la première architecture ouverte, la première architecture libre. J'étais aussi excité que la première fois que j'ai vu gcc.

Les logiciels libres sont pain béni pour le bitouilleur et la manière dont ils créent des standards profite à l'utilisateur final, mais il n'y en a pas moins un gouffre entre ce que les hackers et ce que les simples utilisateurs peuvent faire avec des logiciels libres. Nous voulions qu'eCos soit adopté par les bitouilleurs, mais aussi par le programmeur moyen. Notre idée était de donner aux utilisateurs des outils de haut niveau pour configurer, personnaliser et valider eCos de façon automatique, remplaçant les étapes manuelles que les développeurs de SETR font aujourd'hui. En réalisant des outils qui contrôlaient eCos au niveau du code source, et en architecturant le code source de manière à ce qu'il soit administrable par ces outils, nous avons permis à l'utilisateur moyen de travailler au niveau du code source, sans même écrire une ligne de C ou C++. La preuve de notre succès est qu'eCos peut être configuré de manière à tenir dans 700 octets (strict minimum nécessaire pour réaliser une couche d'abstraction au-dessus du silicium) ou grandir jusqu'à 50 Ko (SETR complet avec IP et un système de fichiers !)

Une fois que nous avons compris que l'ouverture du code source n'était pas seulement une option, mais une caractéristique essentielle d'eCos, et qu'elle nous donnait un facteur 10 par rapport à la concurrence (10 fois moins de place en mémoire par rapport à la configuration au niveau objet, et 10 à 100 fois plus d'efficacité pour les programmeurs par rapport à des SE dont les sources sont disponibles, mais pas au cœur de l'architecture), nous avons conçu différents emballages pour mettre notre produit sur le marché, et les premières réactions ont été extrêmement positives.

Si l'on considère les obstacles que nous avons du vaincre pour mettre en place notre activité autour des logiciels GNU, on ne peut qu'imaginer les potentialités de notre système eCos, pour Cygnus et pour le monde.

Réflexions et Perspectives

Les logiciels libres profitent de l'efficacité inhérente à un marché techniquement libre, mais d'une manière imprévisible, organique. Les entreprises peuvent jouer dans ce domaine le rôle de la « main invisible » d'Adam Smith, dirigeant l'évolution de manière à faire avancer le marché global tout en atteignant leurs objectifs au niveau micro-économique. Les réussites les plus spectaculaires dans ce domaine seront destinées à ceux qui pourront se lancer dans les technologies qui engendrent la plus grande coopération de la communauté de l'Internet et qui résolvent les plus grand défis techniques et économiques des utilisateurs.

Issu des logiciels libres, l'Internet a été un déclencheur fantastique pour le développement de nouveaux logiciels libres. À mesure que les gens continueront à se connecter à l'Internet et à utiliser les logiciels libres, nous allons assister à des changements dans le monde du logiciel comparables à ce que fut la Renaissance pour le monde des savants et des universitaires. Avec le vent de liberté qu'ils font souffler sur le monde, je n'en attends pas moins !

Chapitre 5. L'avenir de Cygnus Solutions™ — Récit d'un entrepreneur

Les débuts de Cygnus

GNUPro

Les grands défis

Trouver des fonds au-delà des logiciels libres — eCos

Réflexions et Perspectives