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.

	Avant tout, établis une base ferme.
--Sun Tzu

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.

	Le Monde est plein de possibilités insurmontables.
--Yogi Berra

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 à :

1. placer tout le travail sous CVS (CVS est un logiciel libre de contrôle de l'évolution du code source),

2. écrire des scripts d'installation et de configuration qui recouvriraient les centaines de plates-formes compatibles avec notre produit fini,

3. automatiser les procédures de test

4. nous aider à honorer les nouveaux contrats de développement dont la date limite se rapprochait sans cesse plus vite.

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 :

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 :

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 :

	Watson ! Viens ici !
--Alexander Graham Bell

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.