Précédent Remonter Suivant
Page d'accueil de ce livre

Chapitre 8  De Multics à Unix et au logiciel libre

8.1  Un échec plein d'avenir

Comme nous l'avons déjà mentionné à la section 3.10.1, Multics est né en 1964 au MIT (Massachusetts Institute of Technology) dans le cadre d'un projet de recherche nommé MAC, sous la direction de Fernando Corbató. La même équipe avait déjà créé le système CTSS. Multics était destiné aux ordinateurs General Electric de la famille GE 635, pour lesquels le constructeur fournissait de son côté un système d'exploitation plus conventionnel. Le projet associait le MIT, General Electric et les Bell Telephone Laboratories (une filiale d'AT&T, American Telegraph and Telephone, qui détenait le monopole des télécommunications pour les États-Unis).

L'objectif du projet était la réalisation d'un grand système informatique capable de fournir des services interactifs en temps partagé à un millier d'utilisateurs simultanés. Multics comportait beaucoup d'innovations de grande portée : le langage de commande pour piloter le fonctionnement de la machine était un langage de programmation, le même que celui dont disposait l'utilisateur pour interagir avec le système, le shell évoqué à la section 3.10.1. Le système d'exploitation était écrit en langage évolué (en l'occurrence PL/1), voie ouverte par les systèmes Burroughs écrits en Algol, mais encore peu fréquentée. Les concepts de mémoire centrale pour les données volatiles et de fichiers pour les données persistantes étaient fondus en un concept unique de mémoire virtuelle segmentée, certains segments étant dotés de la qualité de persistance, comme décrit à la section 5.4. Les segments persistants étaient catalogués dans des répertoires à l'organisation arborescente tels que ceux décrits à la section 5.2.1. Moins spectaculaire en apparence mais peut-être aussi importante était l'existence de toute une collection d'outils programmables et combinables entre eux destinés à faciliter le travail d'un type d'utilisateur : le programmeur, et plus spécialement celui qui écrivait un système d'exploitation.

Malgré ou à cause de toutes ces qualités uniques et promises à un grand avenir, Multics fut en gros un échec, au moins du point de vue de sa diffusion. Ses mérites furent reconnus tardivement, et le plus souvent tacitement, par ceux qui en reprirent les idées à leur compte.

Cette méconnaissance longue des mérites de Multics a ses raisons : la technologie des ordinateurs disponible à l'époque de sa diffusion, essentiellement pendant les années 1970, ne permettait d'implémenter les méthodes et les concepts élaborés de ce système qu'au prix d'une grande lourdeur. Les ordinateurs exploités sous Multics étaient gros, chers et lents. L'institut de statistique qui employait à l'époque l'auteur de ces lignes en avait acquis un, fruit de la fusion CII-Honeywell-Bull, et ses experts en informatique démographique avaient essayé d'imaginer les moyens de traiter avec cet engin les recensements de la population, mais ils avaient fini par regarder ce drôle de système un peu de l'oeil de la poule qui a couvé un oeuf de cane.

Leur perplexité n'avait d'ailleurs d'égale que celle des ingénieurs commerciaux qui essayaient de vendre la chose, ou celle des ingénieurs spécialistes de Multics auxquels nous posions des questions incongrues comme « Pourrions-nous traiter des fichiers sur bande magnétique en traitement par lots ? », méthode béotienne mais indispensable à l'époque du fait de la faible capacité des disques.

Il résulta de cette expérience peu de résultats nouveaux dans le travail statistique courant, mais un sursaut intellectuel parmi ceux des informaticiens qui n'avaient pas définitivement sombré dans la léthargie coboliste1 dont on n'émergerait que pour sombrer dans Windows. Si changer de langage ou de système ne rend pas plus intelligent, il y a des systèmes et des langages qui incitent à la réflexion, et d'autres moins. Cela dépend pour une grande part du type d'initiative laissé à l'utilisateur et du niveau d'intelligibilité que le système exhibe. Il y a des systèmes dont les paramètres de fonctionnement sont enfouis dans des fichiers binaires inaccessibles à l'utilisateur, qui n'a qu'un seul choix : cliquer sur des menus en espérant que cela finira par produire un résultat désiré ; c'est le cas de Windows. Unix au contraire contient tous ses paramètres dans des fichiers texte lisibles et réunis dans un endroit connu (le répertoire /etc). La première méthode n'est justifiable que si la réalisation du système est sans faille, et autorise l'utilisateur à ne jamais se préoccuper de ces paramètres, ce qu'ont réussi les concepteurs de MacOS, mais pas ceux de Windows ; elle suppose aussi que lesdits utilisateurs ne sont que cela, utilisateurs, qu'ils ne nourrissent aucun intérêt pour le système et n'envisagent pas une seconde de se mettre à le modifier, ou du moins à en modifier le comportement en jouant sur les paramètres.

Multics, sous cet angle comme sous certains autres, était un précurseur d'Unix, système qui considère ses utilisateurs comme des personnes intelligentes, mais aussi suffisamment intéressées par le système lui-même pour lui consacrer un temps non négligeable dont les employeurs ne comprennent pas toujours la fécondité. C'est ainsi que des industriels ont inventé pour Unix une interface utilisateur nommée CDE (Common Desktop Environment) dont le principe est de plaquer sur le système une sorte de super-Windows dont le paramétrage, réservé à des administrateurs, est ensuite propagé à la masse des utilisateurs. Cette vision centralisée et hyper-organisée aurait sans doute bien réussi dans les années 1960, mais elle risque de ne pas résister aux sables mouvants de la sociologie réelle des organisations des années 2000.

8.2  Où l'on commence à rêver à Unix

Les créateurs d'Unix, Ken Thompson et Dennis M. Ritchie, avaient une forte expérience de Multics, et ils savaient aussi bien ce qu'ils voulaient en retenir que ce qu'ils en rejetaient. Ils en retenaient notamment les aspects suivants : Cette qualité, partagée par Multics et Unix, d'être propice à la création d'une communauté ouverte et communicative, mérite que l'on s'y arrête. Lorsque Multics a été introduit dans l'Institut statistique évoqué ci-dessus, il y a immédiatement cristallisé la formation d'une petite communauté intellectuelle, que la Direction n'a d'ailleurs eu de cesse de résorber parce qu'elle n'en comprenait pas la fécondité et qu'elle percevait son activité comme un gaspillage. D'innombrables expériences similaires ont eu lieu autour de Multics et d'Unix, sans qu'une cause unique puisse leur être attribuée. Le fait que ces systèmes aient été créés par des chercheurs, habitués à l'idée que la connaissance soit objet de partage gratuit et de communication désintéressée mais assortie de plaisir, est un élément. L'existence de logiciels commodes pour la création de textes, le courrier électronique et les forums en ligne a aussi joué, mais cette existence était-elle une cause ou une conséquence ? La nature programmable du shell, l'accès possible pour tous aux paramètres du système, inscrits dans des fichiers de texte ordinaires, encourageaient un usage intelligent du système, et l'intelligence va de pair avec l'échange.

Si l'on compare Multics et Unix aux systèmes industriels disponibles à l'époque, comme l'OS 360, GCOS 8 ou plus tard VMS de Digital Equipment, il apparaît que ces derniers ne sont pas conçus dans le même esprit : l'utilisateur dispose d'un mode d'emploi du système, réputé contenir les solutions pour tout problème qu'il pourrait se poser. Lorsque tout ceci est bien fait, comme par exemple dans VMS, le système à mémoire virtuelle conçu pour l'ordinateur VAX, cela suscite un usage efficace et commode mais passif du système.

L'auteur de ces lignes a été un utilisateur longtemps réticent et sceptique d'Unix, dérouté par l'aspect « caisse à outils » du système. VMS, que je pratiquais simultanément, avait été conçu par une équipe de (très bons) ingénieurs, soucieux de livrer un produit homogène et cohérent, et ils avaient parfaitement réussi. La meilleure preuve de cette réussite était la documentation du système, souvent un aspect un peu négligé : celle de VMS était une merveille de clarté et d'exhaustivité, au prix certes d'un nombre impressionnant de mètres linéaires de rayonnage. Mais quel que soit le problème à résoudre, on était sûr que la réponse était dans la « doc ». Lorsque Digital Equipment a produit sa propre version d'Unix, ils ont publié un petit manuel résumé des commandes Unix, baptisé « The little grey book » (la couleur canonique de la documentation Digital venait de virer de l'orange au gris). Par opposition, la documentation VMS s'est trouvée baptisée « The big grey wall ».

Habitué donc à l'univers confortable et hyper-balisé de VMS, je découvrais avec Unix un système de prime abord beaucoup moins homogène, même si je devais découvrir plus tard que son homogénéité résidait ailleurs. Comme chaque commande Unix s'exécute sous le contrôle d'un processus distinct, elle peut être assez découplée du noyau du système. Cette modularité, qui est un avantage, avait permis de confier l'écriture de beaucoup de commandes à des étudiants en stage, quand elles n'étaient pas tout simplement des contributions spontanées, et alors leur qualité et celle de leur documentation pouvaient être assez inégales.

De Multics les créateurs d'Unix rejetaient la lourdeur. La tentation fatale, pour des auteurs de systèmes informatiques en général, et de systèmes d'exploitation ou d'architectures de processeurs tout particulièrement, consiste à céder au perfectionnisme et à réaliser des dispositifs qui ajouteront au système global une complexité considérable pour résoudre des problèmes qui ne surgiront que très rarement. Les problèmes rares peuvent se contenter de solutions inefficaces mais simples. Force est de constater que les auteurs de Multics n'ont pas évité cette ornière. VMS non plus d'ailleurs, qui succédait aux merveilleux RSX-11M et autres IAS.

Frederick P. Brooks, le concepteur de l'OS/360, dans son livre justement célèbre The Mythical Man-Month [10], décrit ce qu'il appelle le syndrome du second système, et qui s'applique à Multics comme à l'OS/360 : une équipe constituée en grande partie des mêmes hommes autour de Fernando Corbató avait développé avec succès CTSS ; en s'attaquant à Multics ils ont voulu y introduire tous les perfectionnements coûteux qu'ils avaient, avec sagesse mais frustration, écartés de leur oeuvre précédente. En informatique comme ailleurs, point de salut sans une part de renoncement.

En fait, à la fin des années 1960, l'échec de Multics aux Bell Labs était patent. L'équipe qui allait y concevoir Unix, autour de Ken Thompson et Dennis Ritchie, comprit que Multics ne serait pas utilisable pour un travail réel dans un délai raisonnable. De son côté le propriétaire de Multics, la compagnie General Electric, se sentait assez peu concerné par ce système développé par des chercheurs universitaires et préférait commercialiser ses ordinateurs avec son système conventionnel, GECOS. Lorsque Multics deviendrait utilisable, à la toute fin des années 1970, les ordinateurs qu'il pouvait piloter étaient définitivement périmés et sans espoir de succession.

Dans un article de 1979 [56] Dennis Ritchie a décrit cette période où les Bell Labs se retiraient du projet Multics. Ce processus s'accompagnait d'un autre facteur d'incertitude : une réorganisation visait à séparer les équipes de recherche en informatique des équipes de l'informatique opérationnelle ; ce genre de séparation, conforme aux vues des managers financiers efficaces et à jugeote courte, a pour conséquence habituelle de diminuer les moyens disponibles pour la recherche et de réduire la qualité de l'informatique opérationnelle, privée de stimulation intellectuelle. Le groupe de D. Ritchie, K. Thompson, M. D. McIlroy et Joseph F. Ossanna souhaitait conserver l'environnement de travail luxueux que Multics leur procurait à un coût d'autant plus exorbitant qu'ils en étaient les derniers utilisateurs. Pour ce faire ils allaient développer leur propre système sur un petit ordinateur bon marché et un peu inutilisé récupéré dans un couloir, un PDP 7 de Digital Equipment. Unix était sinon né, du moins conçu.

8.3  Les hommes d'Unix

Effectivement, peu de femmes dans cette histoire. Raison de plus pour mentionner Evi Nemeth, et, peut-être pas tout à fait dans le même domaine ni à la même époque, Radia Perlman, spécialiste des protocoles de réseau, et Elizabeth Zwicky.

Le lecteur, à la fin de l'alinéa précédent, se sera peut-être fait la réflexion que pour que des employés d'une grande entreprises puissent développer un système d'exploitation, même ascétique, pendant leur temps libre, il fallait que leur encadrement ne soit pas trop rigide. Parce que ce même lecteur devrait maintenant être convaincu que le système d'exploitation est l'objet technique le plus complexe que l'homme ait conçu et réalisé au cours du XXe siècle. Quelle était au fait la mission théorique de ces jeunes gens ? Qui contrôlait la réalisation de leurs objectifs ?

Peter H. Salus a écrit un livre (A Quarter Century of UNIX, [59]) qui met en scène les principaux acteurs de la naissance d'Unix. De prime abord, on est frappé en lisant ces aventures de découvrir que cette création, qui a eu des répercussions considérables dans les domaines technique autant qu'industriel et économique, n'a vraiment été décidée ni par un groupe industriel, ni par un gouvernement, ni par aucun organisme doté de pouvoir et de moyens financiers importants. On peut d'ailleurs en dire autant de l'Internet (pour des détails, voir la section 6.5.3), une autre création aux répercussions considérables, d'ailleurs très liée à Unix et issue du même milieu social.

À la lecture du livre de Salus, quiconque a un peu fréquenté les milieux scientifiques d'une part, les milieux industriels de l'autre, ne peut manquer d'être frappé par le caractère décalé, pour ne pas dire franchement marginal, de la plupart des acteurs de la genèse unixienne.

Le monde de la science a sa hiérarchie, où les disciplines spéculatives et abstraites ont le pas sur les recherches appliquées et les disciplines descriptives, et où bien sûr les chercheurs sont patriciens et les ingénieurs et techniciens ilotes, entourés d'une population au statut incertain, les étudiants en thèse ou en post-doc, dont une minorité d'élus accédera au patriciat mais dont la majorité ne deviendra même pas ilote, contrainte à descendre aux enfers, c'est-à-dire le monde réel des entreprises industrielles et commerciales.

Dans cet univers social, l'informatique, discipline récente et mal identifiée, perçue (au mépris de toute vraisemblance, mais qu'importe au sociologue) comme un vague sous-produit de la branche la moins noble des mathématiques (l'analyse numérique), se situe plutôt vers le bas. Au sein de la discipline, le haut du pavé est tenu par les domaines où il y a une théorie possible, de préférence mathématique ou à la rigueur physique : linguistique de la programmation, algorithmique (surtout numérique ou logique), traitement de l'image ou du signal en général. Les systèmes d'exploitation disposent de tout un arsenal de concepts, mais pas d'une théorie, c'est ainsi ; de surcroît ils sont bien près du matériel, cette chose qui a des relents de cambouis et de sueur. Donc ils sont en bas. Alors des ingénieurs qui s'occupent de systèmes d'exploitation...

Le monde industriel (nous nous plaçons à l'époque de la naissance d'Unix, avant la prise de pouvoir par les financiers à costume noir et cortex de calmar) a un système de valeurs symétrique de celui de la science : on y respecte celui qui fait des choses, de vraies choses. C'est un univers dominé par les ingénieurs, qui sont censés se coltiner avec la matière. On sait bien qu'une industrie dynamique doit avoir des centres de recherche, et que dans ces endroits travaillent des types bizarres appelés chercheurs, mais même si on ne les méprise pas vraiment, ils sont considérés avec une certaine distance.

Or que nous apprend Salus ? Thompson et Ritchie étaient chercheurs dans une entreprise industrielle. Au fur et à mesure de leur apparition, les noms de ceux qui font fait Unix, parmi eux Kirk McKusick, Bill Joy, Eric Allman, Keith Bostic, sont toujours accompagnés d'un commentaire de la même veine : ils étaient étudiants undergraduates ou en cours de PhD, et soudain ils ont découvert qu'Unix était bien plus passionnant que leurs études. Bref, les auteurs d'Unix n'ont jamais emprunté ni la voie qui mène les ingénieurs perspicaces vers les fauteuils de Directeurs Généraux, ni celle que prennent les bons étudiants vers la tenure track, les chaires prestigieuses, voire le Nobel3.

8.4  Introduction à la démarche unixienne

Comme le note Christian Queinnec aux premiers mots de son livre « ABC d'Unix » [54], « UNIX est un système de production de programme ». Et, conformément à l'esprit d'Unix, cette assertion est à prendre à la fois de façon extensive : ce système comporte tout ce dont peut rêver un auteur de programme, et, aussi, de façon restrictive : malgré quelques concessions récentes, il ne comporte fondamentalement rien d'autre. Les Unix modernes tels que Linux sont certes dotés de logiciels utilisables par le commun des mortels, avec des interfaces graphiques, mais les vrais unixiens n'en abusent pas.

La documentation canonique d'Unix (les man pages) constitue une excellente entrée en matière : aucun effort pédagogique, aucune de ces redondances qui facilitent l'acquisition d'une notion. Les mots en sont comptés, aucun ne manque mais pas un n'est de trop. La lecture attentive (très attentive) de ces pages délivre une information nécessaire et suffisante à l'usage du système, d'où une locution proverbiale souvent proférée par les Unixiens expérimentés en réponse à un néophyte qui demande de l'aide : « RTFM! » (Read the f... manual!). On le voit, Unix est à l'opposé de ces logiciels à interface graphique dont les vendeurs laissent croire qu'ils peuvent être utilisés sans lire aucune documentation4.

À qui était, comme l'auteur, habitué aux systèmes des grands ordinateurs IBM des années 1970, ou au système VMS que Digital Equipment Corporation (DEC) avait développé pour ses ordinateurs VAX, la transition était rude. Les systèmes d'IBM et de DEC étaient conçus dans le but d'élargir l'audience de l'informatique à des utilisateurs moins professionnels, à une époque où les micro-ordinateurs n'existaient pas. Pour ce faire, la syntaxe de leur langage de commandes cherchait à s'adoucir en utilisant des lexèmes plus proches du langage humain, en tolérant des abréviations ou au contraire des tournures plus bavardes mais plus faciles à mémoriser. La réponse du système à une commande était aussi édulcorée : présentation aérée, commentaires explicatifs.

Pour un Unixien, toutes ces variations pédagogiques ne sont que concessions coupables à l'ignorance informatique des secrétaires et des comptables. L'initiation informatique des ces professions respectables est peut-être un objectif louable, mais dont il ne veut rien savoir, et Unix non plus, parce que pour un développeur5 ces aides pédagogiques sont autant d'obstacles à son travail.

La syntaxe des commandes Unix est sèche comme un coup de trique, d'une part parce qu'elles sont destinées à des professionnels qui les connaissent par coeur à force de les utiliser à longueur de journée, d'autre part parce qu'elles constituent un langage de programmation (le shell) qui permettra d'automatiser des opérations répétitives, et que pour un langage toute souplesse syntaxique se paye en espace et en temps (il faut bien écrire les instructions qui vont interpréter les commandes, et autant de variations possibles autant de dizaines de lignes de code en plus).

La réponse du système à l'utilisateur qui lui soumet une commande est tout aussi austère, le plus souvent d'ailleurs il n'y a pas de réponse. Ainsi, si vous voulez modifier le nom d'un fichier, et que le nouveau nom que vous souhaitez lui donner est déjà pris par un autre fichier, si le renommage est effectué le fichier homonyme sera détruit. Les systèmes à l'usage des secrétaires, des comptables ou des présidents d'université, face à un tel cas, posent la question à l'utilisateur : « veux-tu vraiment détruire l'autre fichier ? », ou renomment le fichier menacé. Pour Unix rien de tel : le fichier est froidement détruit sans même une notification post mortem. C'est un système pour les vrais hommes, qui savent ce qu'ils font, assument leurs erreurs et savent les réparer.

Mais à cet ascétisme il y a une raison encore plus dirimante, et qui n'est pas de l'ordre du sado-masochisme. L'invention sans doute la plus géniale d'Unix est la possibilité, par la simple syntaxe du shell, de réaliser des opérations de composition de processus, au sens algébrique du terme.

Les opérations les plus simples consistent à rediriger les résultats de sortie d'une commande vers un fichier, et à donner en entrée à une commande des données stockées dans un fichier, ce qui n'est pas encore de la composition de processus. Mais pour réaliser ceci il fallait déjà standardiser les formats d'entrée et de sortie des commandes, et découpler les mécanismes d'entrée et de sortie, pour introduire les notions d'entrée standard et de sortie standard, ce qui ouvrait la voie à des réalisations plus ambitieuses.

L'opérateur de composition de processus en séquence est « ; ». On remarque la concision. « a ; b » se lit : exécuter la commande a, puis la commande b. La plupart des commandes Unix s'exécutent comme un processus indépendant. Le lancement d'un programme créé par un utilisateur obéit à la même syntaxe et aux mêmes règles, ce qui encourage les développeurs à utiliser les conventions des commandes Unix, et ainsi à contribuer à l'enrichissement du système.

L'opérateur de composition de processus parallèles asynchrones est « & ». « a & b » se lit : lancer l'exécution de a, puis sans attendre qu'elle se termine lancer aussitôt b. Les deux processus seront concomitants (et concurrents pour l'acquisition du contrôle du processeur).

L'opérateur de composition de processus parallèles synchrones est « | ». « a | b » se lit : lancer l'exécution de a, puis lancer b qui va aussitôt attendre la première ligne de résulat issue de a, la traiter puis se bloquer en attente de la suivante, etc.

Prenons un exemple simple : je veux la liste de tous les processus en cours d'exécution qui exécutent le serveur WWW Apache, avec leur numéro de processus.

La commande qui affiche la liste des processus s'appelle « ps », qui doit, pour afficher non seulement les processus de l'utilisateur mais tous les autres, être agrémentée des paramètres a et x, ce qui s'écrit donc « ps ax ». Cette commande va produire la liste de tous les processus, avec leur numéro et le nom du programme exécuté, à raison d'une ligne par processus. Je veux filtrer cette liste pour n'en retenir que les lignes où le nom de programme qui apparaît est apache.

Parmi les plus belles commandes d'Unix il faut citer grep (pour general regular expression parser, analyseur général d'expressions régulières). Cette commande peut faire des choses très savantes, mais nous allons l'utiliser de façon très simple, pour retrouver une chaîne de caractères dans le texte soumis à son entrée standard. « grep apache » signifie : si la ligne de l'entrée standard contient le texte « apache », afficher le texte à l'écran, sinon passer à la suivante.

Nous allons composer les deux commandes « ps ax » et « grep apache » par l'opérateur de composition parallèle synchrone « | » : 
ps ax | grep apache
Chaque ligne issue de la première commande sera soumise à la seconde pour analyse, ce qui réalisera le filtre souhaité : 
> ps ax | grep apache
  284 ?        S      0:00 /usr/sbin/apache
  295 ?        S      0:00 /usr/sbin/apache
  296 ?        S      0:00 /usr/sbin/apache
  297 ?        S      0:00 /usr/sbin/apache
  298 ?        S      0:00 /usr/sbin/apache
  299 ?        S      0:00 /usr/sbin/apache
  434 pts/0    S      0:00 grep apache
Je reçois ainsi la liste de tous les processus Apache avec leur numéro, et en prime le processus d'analyse, puisque sa ligne de commande comporte elle aussi le texte apache.

Cette métaphore du filtre est promue au rang de paradigme par UNIX : les programmes vraiment unixiens doivent être écrits comme des filtres, c'est à dire recevoir un flux de caractères sur leur entrée standard et émettre un flux de caractères (convenablement modifié) sur leur sortie standard, ce qui permet de les combiner ad libitum.

C'est le livre de Jean-Louis Nebut [49] qui me semble-t-il explicite le mieux la syntaxe du shell en termes de filtres et de composition de processus. Il est aisé de concevoir que le fonctionnement d'un tel système suppose une discipline assez ascétique dans la syntaxe des commandes et leur mode d'interaction. Notamment, puisqu'elles doivent être les syntagmes d'un langage de programmation, dont les programmes sont usuellement appelés shell scripts, il n'est pas souhaitable que les commandes engagent un dialogue avec l'utilisateur, qui dans ce cas ne sera pas un humain mais le système d'exploitation.

8.5  Dissémination d'Unix

8.5.1  Un système exigeant

Nous venons de dire qu'Unix était un système de production de programme, conçu pour satisfaire les programmeurs professionnels et à peu près personne d'autre. Comment expliquer alors qu'il se soit répandu dans beaucoup d'autres domaines, souvent au prix de beaucoup de crises de nerfs de la part d'utilisateurs furieux ? Parce qu'il faut bien dire qu'Unix n'est pas un système confortable pour qui n'est pas disposé à y consacrer la moitié de son temps de travail.

L'auteur de ces lignes, il y a de nombreuses années, a compris que s'il voulait espérer garder l'estime de certains collègues il lui fallait savoir se servir assez couramment d'Unix et surtout de l'éditeur de texte Emacs avec lequel d'ailleurs il compose le présent texte. Cette prise de conscience a entraîné de nombreuses et lourdes conséquences. Il en va d'Emacs comme d'Unix : aucun espoir d'acquérir un minimum de maîtrise de cet éditeur (génial) sans plusieurs heures de pratique quotidienne, qui au bout de quelques mois permettront de savoir raisonnablement utiliser quelques dizaines parmi ses 14 000 et quelques fonctions, sans parler du langage de programmation qui lui est incorporé. Bien, il fallait s'y mettre, et pour cela une seule solution : utiliser Unix et Emacs pour tout, rédaction de documents, courrier électronique, lecture des News.

De ce type de situation on serait tenté d'inférer une conception un peu paradoxale du métier d'informaticien : le travail consisterait essentiellement à rester en symbiose avec le système et les outils de base comme Emacs, à se tenir au courant de leurs évolutions en fréquentant des collègues, par des rencontres, des colloques, les News, à essayer les nouveaux logiciels dès leur sortie, et, logiquement, à en produire soi-même. Il va de soi que dans cette perspective les demandes trop précises d'un employeur qui n'aurait pas compris ce processus seraient perçues comme autant d'obstacles mesquins. Le trait ici est bien sûr forcé, mais l'employeur avisé n'oubliera pas que ses ingénieurs, pour rester compétents, ont besoin de temps pour les activités énoncées ci-dessus.

La conclusion qui semblerait logique après la lecture des lignes précédentes serait qu'Unix aurait dû disparaître sous les coups furieux des DRH et des chefs de projet, ou du moins aurait dû rester cantonné à un petit monde de chercheurs, de développeurs et de hobbyistes. Il n'en a rien été pour au moins deux raisons exposées à la section 8.5.2.

8.5.2  Naissance d'une communauté

Lorsqu'après quelques années de travail assez confidentiel il n'a plus été possible à AT&T (American Telegraph and Telephone) d'ignorer le travail de Thompson et Ritchie, celui-ci avait acquis une certaine ampleur et une certaine notoriété, notamment dans le monde universitaire. AT&T décida de vendre Unix assez cher aux entreprises6, et se laissa convaincre d'en concéder l'usage gratuit aux Universités. Cette décision fut à l'origine de la popularité d'Unix dans le monde universitaire.

C'est en 1974 que Vinton Cerf (de l'Université Stanford) et Robert Kahn (de BBN) publièrent le premier article sur TCP/IP. Le travail sur les protocoles fut intense. En 1977 TCP/IP atteignit une certaine maturité, et c'est de ce moment que l'on peut dater la naissance de l'Internet expérimental.

En 1979 la DARPA lançait des appels d'offres assez généreux auprès des centres de recherche prêts à contribuer au développement de TCP/IP, elle souhaitait notamment l'adapter au VAX 11/780, l'ordinateur à mots de 32 bits que DEC venait de lancer (les PDP-11 étaient des machines à mots de 16 bits). Bill Joy, du Computer Systems Research Group (CSRG) de l'Université de Californie à Berkeley et futur fondateur de Sun Microsystems, convainquit la DARPA qu'Unix serait une meilleure plateforme que VMS pour ce projet parce qu'Unix avait déjà été porté sur plusieurs types d'ordinateurs.

De fait, dès 1977 le CSRG avait créé une version expérimentale d'Unix (la « 1BSD », pour Berkeley System Distribution) dérivée de la Sixth Edition des Bell Labs. La Seventh Edition de 1978 tournait sur DEC PDP-11 et avait été portée sur un ordinateur à mots de 32 bits, l'Interdata 8/32 : elle fut portée sur VAX sous le nom de 32V, et le CSRG (nommément Bill Joy et Ozalp Babao~glu) réunit ces diverses souches pour créer la 3BSD en 1979.

Le financement de la DARPA devait stimuler les deux projets : le développement de cette nouvelle version d'Unix nommée « Unix BSD », résolument tournée vers le monde des réseaux, et celui de ce que l'on connaît aujourd'hui sous le nom de TCP/IP. De ce jour, les développements respectifs de TCP/IP, de l'Internet et d'Unix furent indissociables. La souche Bell Labs continua son évolution indépendamment pour engendrer en 1983 la version System V. La suite de cette histoire se trouve ci-dessous à la section 8.5.3.

La disponibilité pratiquement gratuite pour les Universités, les subventions généreuses de la DARPA, c'était deux contributions de poids au succès d'Unix. Un troisième ingrédient s'y ajouta, sans lequel les deux autres n'eussent sans doute pas suffi : ce monde du réseau des centres de recherche était par ses traditions prédisposé aux échanges intellectuels, et justement la construction du réseau lui fournissait le moyen de s'y adonner de façon décuplée. Dans le monde scientifique d'antan, les contacts avec l'extérieur un peu lointain étaient l'apanage des patrons de laboratoire, qui allaient aux conférences où ils accédaient à des informations qu'ils pouvaient ensuite distiller pendant des séminaires suivis religieusement par les disciples. Avec le réseau, de simples étudiants ou de vulgaires ingénieurs pouvaient entrer en contact directement avec des collègues prestigieux. En outre, ces échanges étaient indispensables, parce qu'Unix était gratuit, mais sans maintenance, les utilisateurs étaient contraints de s'entr'aider pour faire fonctionner leurs systèmes. Je me rappelle encore en 1981 les collègues de l'IRCAM qui administraient un des premiers VAX sous Unix d'Europe, toute leur maintenance logiciel était en direct avec Berkeley. Une communauté (scientifique ? technique ? dans les marges de la science et de la technique ?) allait se créer. L'association USENIX en serait une des instances visibles, mais elle resterait largement informelle.

Il est à noter que cette communauté serait assez vite internationale : pour les managers d'AT&T qui s'étaient laissé convaincre de concéder Unix gratuitement aux chercheurs, comme pour la DARPA, le monde informatisable se limitait aux États-Unis et à leur extension canadienne, ils n'avaient pas un instant envisagé l'existence d'Universités en Europe ou en Australie, et encore moins qu'elles puissent s'intéresser à Unix. Pourtant, Salus énumère les institutions inscrites à la première liste de diffusion électronique, telles que citées par le numéro 1 de UNIX NEWS de juillet 1975, et on y trouve déjà l'Université catholique de Louvain et l'Université hébraïque de Jérusalem. N'oublions pas que le premier article consacré à Unix était paru dans les Communications of the Association for Computing Machinery (CACM), l'organe de la principale société savante informatique, en juillet 1974, sous la plume de Thompson et Ritchie, seulement un an auparavant donc.

Accéder au réseau, pour les non-Américains, posait quand même un problème de taille : financer une liaison téléphonique privée transatlantique n'était, et n'est toujours pas, à la portée d'un budget de laboratoire. Ce n'est pas avant la décennie 1980 que les subventions conjuguées de la National Science Foundation (NSF) américaine et, par exemple, du ministère français de la Recherche permettront un accès convenable pour l'époque à ce qui était devenu entre-temps l'Internet. Mais dès les années 1970 des groupes Unix quasi militants apparaissaient dans quelques pays : Australie en 1975, Grande-Bretagne en 1976, Pays-Bas en 1978, France en 1981. Unix se propage sur bande magnétique, son usage est recommandé de bouche à oreille, c'est assez analogue au phénomène des radio-amateurs dans les années 1960 : tout le plaisir est de réussir à établir une communication avec le Japon ou le Kenya, peu importe après tout ce que l'on se dit, mais le sentiment d'appartenance à la même société d'initiés est d'autant plus fort que les gens sérieux et raisonnables ne comprennent pas.

Ce milieu social d'étudiants en rupture de PhD et d'ingénieurs de centres de calcul dont les responsables ont renoncé à comprendre la teneur exacte de l'activité va assurer le développement d'Unix et de l'Internet, tant les deux sont indissociables. Ce faisant ils vont engendrer une nouvelle entité technique et économique, le logiciel libre. Tout cela sans maîtrise d'ouvrage, sans cahier des charges, sans business plan, sans marketing, sans conduite du changement ni plan qualité, ni tout un tas d'autres choses soi-disant indispensables.

Avant d'aborder la question du logiciel libre, il faut s'interroger sur un phénomène quand même surprenant : nous avons dit qu'Unix était très inconfortable pour tout autre qu'un développeur utilisant ses diverses fonctions à longueur de journée. Comment expliquer alors qu'en une dizaine d'années il se soit vu reconnaître une position hégémonique dans tout le monde de la recherche ? Parce que même dans les départements d'informatique des universités et des centres de recherche, la majorité des gens ne passent pas leur temps à programmer, il s'en faut même de beaucoup, alors ne parlons pas des biologistes ou des mathématiciens.

La réponse n'est pas univoque. Mon hypothèse est que si cette population d'étudiants et d'ingénieurs, pauvre en capital social et en légitimité scientifique, a pu se hisser à cette position hégémonique, c'est que la place était à prendre. Pendant les années 1960 et 1970, on assiste aux tentatives des autorités académiques légitimes de l'informatique, dont les porte-drapeaux ont nom Dijkstra, Hoare, Knuth, ou en France Arsac, Ichbiah, Meyer, pour imposer leur discipline comme une science à part entière, égale de la Physique ou de la Mathématique. Pour ce faire ils élaborent des formalisations, des théories, des concepts souvents brillants. Peine perdue, ils échouent, malgré le succès technique et économique retentissant de l'informatique, ou peut-être même victimes de ce succès. Le public, fût-il universitaire, ne discerne pas l'existence d'une science derrière les objets informatiques qui deviennent de plus en plus ses outils de travail quotidiens. Les raisons de cet état de fait restent en grande partie à élucider, sur les traces de chercheurs en histoire de l'informatique tel en France un Pierre-Éric Mounier-Kuhn. Ce désarroi identitaire de l'informatique universitaire snobée par ses collègues laissait le champ libre à des non-mandarins d'autant plus dépourvus de complexes qu'ils n'avaient aucune position à défendre et que le contexte économique d'Unix lui permettait de se développer dans les marges du système, sans gros budgets hormis le coup de pouce initial de la DARPA. Les financements absorbés par Unix et TCP/IP sont assez ridicules si on les compare à ceux de l'intelligence artificielle, sans doute la branche la plus dispendieuse et la plus improductive de la discipline7, ou même à ceux du langage Ada, projet sur lequel se sont penchées toutes les bonnes fées de la DARPA et du monde académique, et qui finalement n'a jamais percé en dehors des industries militaires et aérospatiales (ce n'est déjà pas si mal, mais les espoirs étaient plus grands).

Finalement, les outsiders unixiens l'ont emporté par leur séduction juvénile et leur occupation du terrain pratique, qui leur a permis de proposer à telle ou telle discipline les outils qui lui manquaient au moment crucial : le système de composition de documents TeX pour les mathématiciens, qui seul répondait à leurs exigences typographiques, et pour les informaticiens toutes sortes de langages et surtout d'outils pour créer des langages. J'ai vu dans le monde de la biologie Unix supplanter VMS : il faut bien dire que les tarifs pratiqués par Digital Equipment et la rigidité de sa politique de produits lui ont coûté la domination d'un secteur qui n'avait pas beaucoup de raisons de lui être infidèle. Un collègue m'a confié un jour « Le principal argument en faveur d'Unix, c'est que c'est un milieu sympathique ». Cet argument m'avait paru révoltant, mais je crois qu'il avait raison, si l'on prend soin de préciser que par « sympathique » on entend « propice aux libres échanges intellectuels ».

8.5.3  Le schisme

Une si belle unanimité ne pouvait pas durer (et aurait été de mauvais augure). La souche BSD manifestait une certaine indépendance par rapport à l'orthodoxie AT&T. À la section ci-dessus 8.5.2 nous avons laissé d'une part les versions issues de la souche Bell Labs, regroupées à partir de 1983 sous l'appellation System V, de l'autre celles issues de la souche BSD, qui en 1983 en sont à la version 4.2BSD. De cette époque on peut vraiment dater la séparation de deux écoles rivales. On pourra se reporter au livre de McKusick et ses coauteurs [42] qui donne dans ses pages 5 et 6 un arbre phylogénétique complet du genre Unix.

Quelles étaient les différences entre System V et BSD ? En fait la seule différence vraiment profonde, perceptible dans l'architecture du noyau, était le code destiné à la communication entre processus (et de ce fait au fonctionnement du réseau), organisé dans les systèmes BSD selon le modèle de socket que nous avons évoqué à la section 6.6.1, tandis que les System V utilisaient un autre modèle, moins versatile, baptisé STREAMS. BSD fut aussi en avance pour adopter un système de mémoire virtuelle à demande de pages et un système de fichiers amélioré (Fast File System). Autrement certaines commandes du shell étaient différentes, ainsi que le système d'impression et l'organisation des fichiers de paramètres du système (répertoire /etc), etc. La différence était surtout perceptible pour les ingénieurs système et pour les développeurs de logiciels proches du noyau.

Au fur et à mesure qu'Unix se répandait, certains industriels en percevaient l'intérêt commercial et lançaient des gammes de matériels sous Unix. Bill Joy et certains de ses collègues de Berkeley créaient en 1982 Sun Microsystems dont les ordinateurs à base de processeurs Motorola 68000 mettaient en oeuvre une version dérivée de BSD, SunOS. Chez DEC c'était Ultrix. HP-UX de Hewlett-Packard et AIX d'IBM étaient de sensibilité System V. Dès 1980 Microsoft avait lancé Xenix ; à ce sujet il convient d'ailleurs de noter qu'à cette époque Bill Gates considérait Unix comme le système d'exploitation de l'avenir pour les micro-ordinateurs ! AT&T lançait ses propres microprocesseurs et ses propres ordinateurs (la gamme 3B) sous Unix, qui n'eurent aucun succès : le démantèlement du monopole d'AT&T sur les télécommunications aux États-Unis au début des années 1980 lui donnait l'autorisation de commercialiser des ordinateurs, mais cela ne suffit pas à assurer le succès de cette gamme de machines...

En fait les différences idéologiques étaient plus tranchées que les différences techniques. Le monde de la recherche et de l'université, ouvert sur les réseaux, penchait pour BSD, issu du même univers, cependant que le monde de l'entreprise avait tendance à se méfier de l'Internet (ou à lui être indifférent) et à se tourner vers la version de la maison-mère, System V.

Il y eut des trahisons sanglantes et impardonnées : en 1992, Sun, porte-drapeau du monde BSD avec SunOS 4.1.3, à l'époque le meilleur Unix de l'avis de la communauté des développeurs, conclut avec AT&T des accords d'ailleurs sans lendemain aux termes desquels il passait à System V sous le nom de Solaris, honni par les puristes BSD.

Ce qui est certain, c'est que ces luttes de clans et ce culte de la petite différence ont beaucoup nui à la diffusion d'Unix et beaucoup contribué au succès des systèmes Windows de Microsoft. La communauté des développeurs a également déployé tous ses efforts pour combattre toute tentative de développer au-dessus d'Unix et du système de fenêtrage X une couche d'interface graphique « à la Macintosh », qui aurait rendu le système utilisable par des non-professionnels. De tels systèmes apparaissent aujourd'hui (Gnome, KDE), alors que la bataille a été gagnée (au moins provisoirement) par Windows.

On peut aujourd'hui considérer que le schisme BSD-System V est résorbé dans l'oecuménisme : tous les System V ont des sockets (pour faire du TCP/IP il faut bien) et tous les BSD ont le système de communication inter-processus (IPC) STREAMS de System V, notamment. Mais l'idéologie BSD reste toujours vivace.

8.6  Aux sources du logiciel libre

8.6.1  Principes

Le logiciel libre mobilise beaucoup les esprits en ce début de millénaire. La définition même de la chose suscite de nombreuses controverses dues en partie au fait que le mot anglais free signifie à la fois libre et gratuit. Si l'on s'en tient à une acception restrictive, l'expression logiciel libre désigne un modèle économique et un mouvement associatif créés en 1984 par un informaticien de génie, Richard M. Stallman, auteur depuis 1975 d'un logiciel extraordinaire, Emacs. En 1983, Stallman, qui travaillait au laboratoire d'intelligence artificielle du MIT, excédé par les restrictions au développement d'Unix induites par les droits de propriété industrielle d'AT&T et de quelques autres industriels8, fonde le projet GNU (« GNU is Not Unix ») destiné à créer un système d'exploitation libre de droits et dont le texte source serait librement et irrévocablement disponible à tout un chacun pour l'utiliser ou le modifier.

L'année suivante, Stallman crée la Free Software Foundation (FSF) pour « promouvoir le droit de l'utilisateur d'ordinateur à utiliser, étudier, copier, modifier et redistribuer les programmes d'ordinateur », c'est à dire étendre le modèle du projet GNU à d'autres logiciels. Un corollaire indissociable de ce principe est que le texte source du logiciel libre doit être accessible à l'utilisateur, ainsi que la documentation qui permet de l'utiliser. Cette clause confère à tout un chacun le moyen de modifier le logiciel ou d'en extraire tout ou partie pour une création nouvelle. Pour assurer la pérennité du principe, tout logiciel libre conforme aux idées de la FSF est soumis aux termes d'une licence, la GNU GPL (GNU General Public License), qui impose les mêmes termes à tout logiciel dérivé. Ainsi il n'est pas possible de détourner du logiciel libre pour créer du logiciel non libre sans violer la licence.

8.6.2  Préhistoire

Avant d'examiner plus avant les tenants et les aboutissants de ces principes et de ce modèle économique, il convient de signaler que jusqu'en 1972 le logiciel, s'il n'était pas libre au sens de la GPL, était pratiquement toujours disponible gratuitement et très souvent sous forme de texte source, et ce parce que jusqu'alors la conscience du coût et de la valeur propre du logiciel était dans les limbes. IBM, qui avait fini par accaparer 90% du marché mondial de l'informatique, distribuait systèmes d'exploitation et logiciels d'usage général à titre de « fournitures annexes » avec les ordinateurs.

Peu après l'annonce de la gamme IBM 360 en 1964, RCA annonça les ordinateurs Spectra 70 dont l'architecture était conçue afin de pouvoir accueillir le logiciel développé pour les IBM 360, y compris le système d'exploitation. Cette ambition ne se réalisa pas, notamment parce que les ingénieurs de RCA n'avaient pu se retenir d'ajouter à leur système des « améliorations » qui en détruisaient la compatibilité, mais IBM avait perçu la menace et commença à élaborer une parade juridique qui consistait à séparer la facturation du logiciel de celle du matériel : ce fut la politique d'unbundling, annoncée en 1969, mais dont l'application à ce moment fut entamée assez mollement.

Au début des années 1970, quelques industriels (notamment Telex, Memorex et Calcomp) commencèrent à vouloir profiter de la manne et pour cela vendre des matériels compatibles avec ceux d'IBM, c'est à dire tels que les clients pourraient les acheter et les utiliser en lieu et place des matériels IBM originaux. IBM riposta à ce qu'il considérait comme une concurrence déloyale en cessant de divulguer le code source des parties de système d'exploitation qui permettaient la conception et le fonctionnement des systèmes concurrents. Il en résulta des procès acharnés, et en 1972 un arrêt de la Cour suprême des États-Unis, au nom de la législation anti-trust créée pour limiter l'emprise de Rockfeller, statua dans le procès Telex--IBM et imposa à IBM de facturer à part logiciel et matériel. Ceci précipita l'entrée en vigueur de la politique d'unbundling. Les observateurs de l'époque déclarèrent que cela n'aurait aucun effet, mais deux industries étaient nées : celle du matériel compatible IBM, qui serait florissante une vingtaine d'années, et celle du logiciel, dont Microsoft est le plus beau fleuron.

8.6.3  Précurseurs

Si l'Église chrétienne a reconnu à Jérémie, Isaïe, Daniel et Ézéchiel la qualité de précurseurs de la vraie foi et de la venue du Sauveur, Richard Stallman est plus intansigeant, mais n'en a pas moins lui aussi des précurseurs. Ils se situent dans les limbes, à l'époque où ARPANET engendrait TCP/IP, qui était bien évidemment du logiciel, et qui était distribué aux membres du réseau, c'est à dire, nous l'avons vu, potentiellement à toutes les universités et tous les centres de recherche. Comme tout cela se passait à Berkeley, il en résulta que le système de prédilection de TCP/IP et, partant, de l'Internet fut Unix, et que traditionnellement les principaux logiciels de réseau sous Unix furent distribués gratuitement, du moins aux centres de recherche, sous les termes d'une licence dite « BSD » qui garantissait les droits de propriété intellectuelle des « Régents de l'Université de Californie ». Les éléments de base du protocole TCP/IP proprement dit font partie du noyau Unix BSD, d'où ils ont assez vite été adaptés aux noyaux des autres Unix, cependant que les logiciels d'application qui en permettaient l'usage, tels que Sendmail pour envoyer du courrier électronique, Ftp pour transférer des fichiers, Telnet pour se connecter à un système distant, etc., étaient distribués indépendamment. Plus tard Bind pour la gestion du service de noms de domaines, INN pour le service de News et beaucoup d'autres logiciels s'ajouteront à cette liste, toujours gratuitement.

Par ailleurs, Unix devenait populaire dans le monde de la recherche et les logiciels développés par des scientifiques étaient aussi rendus disponibles dans des conditions analogues : TeX pour la composition typographique, Blast pour la comparaison de séquences biologiques, Phylip pour l'analyse phylogénétique, pour ne citer que trois exemples parmi une foule, sont disponibles selon les termes de licences assez variées (ou d'absence de licence...), mais toujours sans versement de redevances. Bref, le monde de la recherche fait et utilise du logiciel libre depuis longtemps sans forcément le dire ni même en avoir conscience.

8.6.4  Économie du logiciel

L'économie du logiciel, étudiée notamment avec brio par Michel Volle dans son livre e-conomie [72], exprime un paradoxe dont la conscience ne s'est manifestée que récemment. Citons Michel Volle dans la présentation de son livre : « Le ``système technique contemporain'' est fondé sur la synergie entre micro-électronique, informatique et automatisation. On peut styliser sa fonction de production en supposant qu'elle est ``à coûts fixes'' : le coût de production, indépendant du volume produit, est payé dès l'investissement initial. Développons cette hypothèse : les usines étant des automates, l'emploi réside dans la conception et la distribution. La distribution des revenus n'est pas reliée au salariat. Les entreprises différencient leur production pour construire des niches de monopole. Elles organisent leurs processus autour du système d'information. Le commerce passe par des médiations empruntant la communication électronique.

L'investissement est risqué, la concurrence est mondiale et violente. On retrouve dans cette présentation stylisée des aspects tendanciels de notre économie. Elle éclaire la description des secteurs de l'informatique, de l'audiovisuel, des réseaux (télécommunications, transport aérien, etc.), du commerce, ainsi que les aspects stratégiques et tactiques des jeux de concurrence dans ces secteurs et dans ceux qui les utilisent. On voit alors que cette économie hautement efficace pourrait aller au désastre si elle était traitée sur le mode du ``laissez faire'', sans considérer les exigences de l'éthique et de la cohésion sociale. » (texte disponible sur le site http://www.volle.com selon les termes de la GNU Free Documentation License).

Dans le cas du logiciel ces traits sont particulièrement marqués : la création d'un logiciel important tel qu'un système d'exploitation9 est une tâche colossale qui peut mobiliser des centaines de personnes pendant une décennie, le coût marginal du produit final livré dans un grand magasin est pratiquement nul, le prix payé par le client est essentiellement celui de la boîte en carton, des frais de transport et de gestion et de l'effort commercial. Il en résulte, dans l'industrie du logiciel, une tendance irréversible au monopole : dans une industrie à coût marginal de production nul, dès que vous vendez plus que les autres, vous êtes très vite beaucoup plus riche, avec les conséquences qui en découlent. Dès lors qu'un marché prend forme et s'organise, il émerge un fournisseur unique : Microsoft pour les systèmes des micro-ordinateurs et la bureautique, Oracle pour les bases de données, SAP pour la gestion financière et comptable, SAS pour l'analyse statistique. Quelques concurrents subsistent, en permanence au bord de la faillite ou cachés dans des « niches » de marché.

Dans cette situation désespérante, l'espoir de diversité, dans un contexte industriel classique, ne peut venir que de l'apparition de nouveaux segments de marchés, desservis par de nouvelles technologies, rôle joué dans le passé par les mini-ordinateurs, puis les micro-ordinateurs à base de microprocesseur, innovations technologiques qui réduisaient de plusieurs ordres de grandeur les coûts de production.

8.6.5  Modèle du logiciel libre

Le logiciel libre, face à cette situation, représente un potentiel très dynamique, parce qu'il obéit à un modèle économique tout autre. Microsoft ne peut utiliser contre lui aucune des armes classiques de la concurrence industrielle, telles que la guerre des prix, la publicité, les fournitures associées, l'effet de gamme, etc., parce que le logiciel libre n'est sur aucun de ces terrains.

Les caractères économiques du logiciel libre ont été étudiés, entre autres, par Marie Coris dans son travail de thèse de doctorat à l'Université Montesquieu de Bordeaux IV (voir sa communication au congrès JRES 2001 : [16]). Elle énumère d'abord les caractères du logiciel en général : L'alternative se situe entre le logiciel comme bien privé, idée des entreprises telles que Microsoft, Oracle, etc., et le logiciel comme bien public, idée du logiciel libre.

Volle, Coris et d'autres ont montré que le marché d'un bien d'information ne peut prendre que deux formes : Le logiciel libre échappe à cette alternative parce qu'il se situe hors de la logique marchande, et que la rétribution de ses auteurs relève des domaines symbolique et moral. Michel Volle a fait remarquer qu'un auteur de logiciel libre aurait aussi un accès facilité au capital--risque le jour où il voudrait créer une entreprise du fait de la reconnaissance acquise dans le domaine non marchand.

La GNU GPL définit parfaitement les « quatre libertés » caractéristiques du logiciel libre : liberté d'utilisation, liberté de copie, liberté de modification et liberté de redistribution. Elle autorise donc la modification et la redistribution, mais en imposant que le logiciel reste sous GPL, et ce également dans le cas de l'incorporation d'un logiciel libre à un nouveau logiciel : le caractère « libre » est héréditaire et contagieux. Dans ce dispositif, le statut du code source détermine la nature publique du bien, plus qu'il ne sert vraiment à la maintenance par l'utilisateur. La publicité du code interdit l'appropriation privée. Mais plonger dans les sources pour y introduire des modifications est une entreprise à n'envisager qu'avec circonspection ; cela risque de coûter fort cher.

Reste à se poser une question : le logiciel libre, comme le logiciel non libre, est écrit par des hommes et des femmes qui y consacrent tout ou partie de leur vie professionnelle et qui ne vivent pas de l'air du temps. Qui finance la production de logiciels libres, et comment, puisque, quoique ses apôtres s'en défendent, sa caractéristique principale est bien qu'il est possible de l'utiliser sans bourse délier ?

Bertrand Meyer, dans un article assez polémique de critique du libre [44], dresse une nomenclature des sources de financement possibles, qui énerve les adeptes mais à laquelle il est difficile de dénier toute véracité :
  1. une donation : le développeur vit de sa fortune personnelle ou développe pendant ses nuits et ses jours de congé ;
  2. le financement public : le logiciel a été créé par un centre de recherche, une université ou une autre entreprise publique ;
  3. le financement privé : une entreprise décide de distribuer un logiciel développé à ses frais selon le modèle libre ;
  4. la subvention (publique ou privée) : le développeur crée un logiciel en utilisant son temps de travail et les ressources de son employeur, public ou privé, sans que celui-ci lui ait confié cette tâche.
Le cas 4 est celui qui provoque parfois quelque agacement, et on ne peut exclure qu'il soit assez répandu. Cela dit, un examen de ce cas informé par les tendances les plus récentes de la sociologie du travail montre que cette situation n'est pas forcément scandaleuse, et que l'initiative prise par le développeur peut comporter des avantages pour son employeur même s'il n'en avait pas initialement conscience. La création d'Unix en est le plus bel exemple, et si l'on regarde en arrière, on peut se dire qu'AT&T en aurait sans doute tiré encore plus d'avantages en en faisant un logiciel libre ; Unix ne lui a pas vraiment rapporté beaucoup d'argent, et sa facturation aux entreprises a considérablement restreint sa diffusion. Le succès actuel de Linux apporte ex post des arguments à l'appui de cette hypothèse. Toutefois, Bertrand Meyer a raison d'écrire que sans la couple Intel--Microsoft il n'y aurait jamais eu de PC à 600 Euros, et partant jamais de succès pour Linux.

Un exemple typique et très instructif du cas 3 est celui du logiciel Ghostscript, produit par la société Aladdin Enterprises, qui est un interpréteur du langage PostScript. PostScript est un langage de description de pages utilisé comme format de sortie par de nombreux logiciels et comme format d'entrée par beaucoup d'imprimantes. Ghostscript est utile pour afficher à l'écran le contenu d'un fichier PostScript, et pour l'imprimer sur une imprimante dépourvue d'interpréteur PostScript incorporé, ce qui est le cas notamment de beaucoup de petites imprimantes à jet d'encre. Ce logiciel a deux groupes bien distincts d'utilisateurs : des millions de propriétaires de petites imprimantes bon marché qui veulent afficher et imprimer du PostScript, et une dizaine d'industriels fabricants d'imprimantes, qui incorporent Ghostscript par paquets de cent mille exemplaires à leurs productions.

Dans sa grande sagesse, la société Aladdin Enterprises a décidé de ne pas se lancer dans la commercialisation à grande échelle d'un logiciel qui vaudrait quelques dizaines d'Euros, et de le distribuer aux particuliers sous les termes d'une licence dite Aladdin Ghostscript Public License, qui protégeait la propriété intellectuelle d'Aladdin et permettait un usage gratuit. Depuis 2000, Ghostscript est un logiciel libre disponible sous les termes de la GNU GPL. Aladdin Enterprises tire plutôt ses revenus de la clientèle des fabricants d'imprimantes.

Le cas 2 est sans doute le plus fréquent. La justification initiale de ce modèle me semble remonter au principe constant de l'administration américaine : ce qui a été payé une fois par le contribuable ne doit pas l'être une seconde fois. Les logiciels dont le développement a été financé par des contrats de recherche de la DARPA doivent être mis gratuitement à la disposition du public, au même titre que les photos de l'espace prises par la NASA.

Ce principe ne semble pas scandaleux : ce qui a été financé par l'argent public10 (au sens large) revient au public. Les résultats de la recherche publique sont disponibles publiquement. Il s'agit d'un système de redistribution : tous les contribuables financent les logiciels produits de cette façon, et les bénéficiaires en sont les utilisateurs. Il est légitime de s'interroger sur l'équité de ce processus de répartition, mais il en est sans doute de pires.

Qui pourrait s'estimer lésé ? Essentiellement les entreprises dont la prospérité repose sur le logiciel commercial, et qui pourraient arguer d'une concurrence déloyale, puisque le plus souvent alimentée par des financements publics. Curieusement, on observe peu de protestations de cette nature, et encore moins de procès.

Il convient aussi de remarquer que le modèle du logiciel libre, s'il n'apporte apparemment que des avantages à l'utilisateur, peut comporter des inconvénients pour l'auteur, qui s'interdit en fait tout contrôle exclusif sur la divulgation de son travail. Certes, les clauses de la GNU GPL permettent la commercialisation de logiciel libre, et il est parfaitement possible de recourir au système de la double licence, par exemple GNU GPL pour le monde académique et licence commerciale pour le monde industriel. Mais il est clair qu'un logiciel novateur dont l'auteur peut espérer des revenus importants sera mal protégé des contrefaçons si son code source est divulgué. En fait, dans le monde académique la pression idéologique pour la GNU GPL est très forte, et les auteurs de logiciels qui souhaitent vivre des fruits de leur activité de développeur plutôt que d'un emploi universitaire (ou qui, faute d'un tel emploi, n'ont pas le choix) sont assez marginalisés par ce système. Le caractère contagieux et contraignant de la GNU GPL est très pénalisant pour l'auteur qui ne souhaiterait pas vivre dans l'abnégation (c'est le terme exact : le logiciel qu'il a écrit ne lui appartient plus), ou qui, faute d'avoir obtenu un poste dans un organisme public, ne le pourrait pas. Il y a des exemples d'auteurs qui pour avoir refusé les servitudes de la GNU GPL se sont vu mettre au ban de la communauté, leurs travaux passés sous silence et leurs logiciels exclus des serveurs publics.

En fait, la réalité usuelle du développeur de logiciel libre est qu'il gagne sa vie autrement, et que la rétribution qu'il attend pour son oeuvre est la reconnaissance de ses pairs. Quiconque bénéficie du logiciel libre ressent le désir d'y contribuer et ainsi d'adhérer à une communauté perçue comme éthique. Il est souhaitable que la GNU GPL ne reste pas hégémonique et que d'autres licences aux termes moins idéologiques et plus équilibrés apparaissent dans le monde du logiciel libre.

8.6.6  Une autre façon de faire du logiciel

Le modèle du logiciel libre n'est pas sans influence sur la nature même du logiciel produit. En effet, dans ce contexte, un auteur peut facilement utiliser d'autres logiciels s'ils sont libres, que ce soit pour recourir à des bibliothèques de fonctions générales ou pour s'inspirer d'un logiciel aux fonctions analogues mais dans un environnement différent.

Des systèmes de développement coopératif se mettent en place par le réseau, qui seraient impensables pour du logiciel non-libre : les programmes sous forme source sont accessibles sur un site public, et chacun peut soumettre sa contribution. L'archétype de ce mode de développement est celui du noyau Linux proprement dit, coordonné par Linus Torvalds personnellement.

Pour qu'un tel procédé donne des résultats utilisables, il faut que le logiciel présente une architecture qui s'y prête, notamment une grande modularité, afin que chaque contributeur puisse travailler relativement indépendamment sur telle ou telle partie. Par exemple, dans le noyau Linux, tout ce qui permet le fonctionnement de machines multi-processeurs et la préemption des processus en mode noyau (voir section 3.12.5) demande une synchronisation beaucoup plus fine des fils d'exécution : les adaptations nécessaires ont été réalisées par Robert Love, ce qui a été possible parce qu'il n'était pas trop difficile d'isoler les parties du code concernées. À l'inverse, lorsque Netscape a voulu donner un statut Open Source à une partie du code de son navigateur connue sous le nom Mozilla, l'opération a été rendue difficile parce que le code initial n'avait pas été réalisé selon un plan suffisamment modulaire.

Finalement, la réutilisation de composants logiciels, dont plusieurs industriels parlent beaucoup depuis des années sans grand résultat, sera sans doute réalisée plutôt par les adeptes de l'Open Source. En effet, l'achat d'un tel composant est un investissement problématique, tandis que le récupérer sur le réseau, l'essayer, le jeter s'il ne convient pas, l'adopter s'il semble prometteur, c'est la démarche quotidienne du développeur libre. On pourra lire à ce sujet l'article de Josh Lerner et Jean Tirole, The Simple Economics of Open Source [37].

L'analyse détaillée des conséquences d'un tel mode de construction de logiciel reste à faire, mais en tout cas il ne fait aucun doute que le résultat sera très différent. Rappelons les étapes classiques de la construction d'un système informatique pour un client selon le mode projet : Oublions tout cela dans le monde du libre. Le logiciel commence à prendre forme autour d'un noyau, noyau de code et noyau humain, généralement une seule personne ou un tout petit groupe. L'impulsion initiale procède le plus souvent du désir personnel des auteurs de disposer du logiciel en question, soit qu'il n'existe pas, soit que les logiciels existants ne leur conviennent pas, que ce soit à cause de leur prix ou de leur environnement d'exécution. Puis d'autres contributions viennent s'ajouter, presque par accrétion. Un coordonnateur émerge, souvent l'auteur initial, il assure la cohérence de l'ensemble. Quand des divergences de vue surgissent, il peut y avoir une scission : ainsi deux versions sont disponibles pour Emacs, Gnu Emacs et Xemacs, toutes deux libres.

Le catalogue du logiciel libre est assez vaste. Tout d'abord le logiciel libre avant la lettre : Et pour le logiciel libre canonique, de stricte obédience : Chacun dans son domaine, ces logiciels sont de toute première qualité, et il n'y a pas à hésiter : ce sont eux qu'il faut utiliser ! Il manque bien sûr des choses, comme un logiciel OCR comparable à Omnipage de Caere...

8.6.7  Linux

Linux est indubitablement un système emblématique du logiciel libre. S'il y a d'autres systèmes d'exploitation libres, y compris dans la famille Unix, et si les logiciels libres ne sont pas tous destinés à Unix, l'association avec Linux est inévitable.

Le début de ce chapitre montre la filiation entre le mouvement autour d'Unix et le développement du logiciel libre, mais le paradoxe était qu'Unix lui-même n'était pas libre, AT&T en détenait les droits. Pourtant la communauté Unix était très attachée à l'idée de l'accès au code source du système, puisque le développement de nouveaux logiciels, certains très proches du système, ne pouvait être entrepris qu'avec un tel accès. En outre les droits d'AT&T semblaient contestables, parce qu'Unix avait recueilli beaucoup de contributions extérieures souvent non rémunérées. Plusieurs moyens ont été envisagés pour briser ou contourner ce paradoxe.

Le premier moyen consistait à obtenir d'AT&T une licence source. Si pour des chercheurs ou des universitaires c'était théoriquement possible, pratiquement des obstacles surgissaient. Si l'on était loin des États-Unis et que l'on n'avait pas de relations dans ce milieu, nouer les contacts nécessaires pouvait demander des mois. Une fois la licence source obtenue, il fallait obtenir du fournisseur de son ordinateur les sources de la version de système précise installée sur la machine, ce à quoi il ne se prêtait pas toujours avec bonne volonté. Bref, le seul moyen de pouvoir accéder réellement aux sources d'un système opérationnel était d'appartenir à un des groupes en vue du monde Unix. Rappelons qu'au début des années 1980 une machine capable de « tourner » Unix et le réseau coûtait au minimum l'équivalent de 100 000 Euros et que l'Internet n'atteignait pas l'Europe.

Ces difficultés étaient particulièrement ressenties par les enseignants qui voulaient initier leurs étudiants à Unix, ce qui était bien sûr impossible sans accès au code source. Ils ont très tôt imaginé des moyens de contourner les droits d'AT&T. Le précurseur quasi légendaire de cette démarche fut un professeur australien, John Lions, dont le livre de 1977 A Commentary on the Unix System, V6[40] comportait le code du noyau. AT&T n'avait autorisé qu'un tirage limité, mais comme en URSS du temps de Brejnev apparut une véritable activité clandestine de Samizdat. Ce livre fut réédité en 1996, et il mérite toujours d'être lu. John Lions aura vu la publication légale de son oeuvre avant sa mort en décembre 1998.

Andrew Tanenbaum, professeur à l'Université Libre d'Amsterdam (Vrije Universiteit Amsterdam), rencontra le même problème. Pour les besoins de son enseignement il créa de toutes pièces un système miniature inspiré d'Unix, adapté aux micro-ordinateurs à processeur Intel et baptisé Minix. Le cours donna naissance à un livre [68] dont les premières versions (1987) comportaient en annexe le code de Minix. Il était également possible d'acheter les disquettes pour installer Minix sur son ordinateur, mais ce n'était ni très bon marché ni très commode.

Pendant ce temps le groupe BSD travaillait à expurger son code de toute instruction rédigée par AT&T, de façon à l'affranchir de tout droit restrictif. Le résultat fut 4.3BSD Net1 en 1989, puis 4.3BSD Net2 en 1991. L'objectif était de produire 4.4BSD-Lite en 1993, mais USL (Unix System Laboratories, une branche d'AT&T qui était à l'époque propriétaire des droits Unix) attaqua ce projet en justice, ce qui en différa la réalisation d'un an. Du groupe BSD émanèrent aussi un système Unix pour processeurs Intel en 1992, 386BSD, et une société destinée à le commercialiser, BSD Inc. Mais tous ces efforts furent retardés par des questions juridiques. Ils débouchèrent, sensiblement plus tard, sur les Unix libres FreeBSD, OpenBSD et NetBSD.

Rappelons que depuis 1983 le projet GNU visait lui aussi à produire un système similaire à Unix mais libre de droits et disponible sous forme source. Au début des années 1990 ce groupe avait réalisé un certain nombre de logiciels libres utilisables sur les divers Unix du marché, notamment des utilitaires, mais toujours pas de noyau. En fait ce n'est qu'en 2000 que le système Hurd11 destiné à remplacer le noyau Unix et basé sur le micro-noyau Mach créé à l'Université Carnegie-Mellon commença à ressembler à un vrai système.

Le salut allait venir d'ailleurs. En 1991 un étudiant de l'Université d'Helsinki, Linus Torvalds, achète un ordinateur doté d'un processeur Intel 386 et cherche un moyen d'explorer son fonctionnement. Minix lui semble une voie prometteuse, dans laquelle il s'engage, mais il y rencontre quelques obstacles et commence à réécrire certaines parties du noyau. En août 1991 Linux est né, en septembre la version 0.01 est publiée sur le réseau. Elle ne peut fonctionner que sous Minix. La version 0.02 publiée le 5 octobre 1991 permet l'usage du shell bash et du compilateur C gcc, deux logiciels GNU. La première version réputée stable sera la 1.0 de mars 1994.

Pour résumer la nature de Linux, nous pourrions dire que c'est un noyau, issu à l'origine de celui de Minix, et dont le développement est toujours assuré sous la supervision personnelle de Linus Torvalds, entouré des outils GNU, le tout sous licence GPL. Ce que Linus Torvalds a fait, d'autres auraient peut-être pu le faire eux-mêmes, et ils regrettent sans doute d'en avoir laissé l'occasion, à un Européen de surcroît, mais l'histoire est ainsi.

Linux est au départ plutôt un Unix System V, mais doté de toutes les extensions BSD souhaitables, ainsi que des dispositifs nécessaires à la conformité POSIX12. Sa principale originalité tient sans doute à son processus de développement : alors que tous les autres systèmes d'exploitation cités dans ce chapitre ont été développés par des équipes organisées, le développement du noyau Linux s'est fait depuis le début par « appel au peuple » sur l'Internet. Quiconque s'en sent la vocation peut participer aux forums, lire le code et proposer ses modifications (appelées patches). Elles seront examinées par la communauté, et après ce débat Linus Torvalds tranchera et décidera de l'incorporation éventuelle au noyau officiel. Il est difficile d'estimer les effectifs d'une telle communauté informelle, mais le nombre de contributeurs actifs au noyau Linux est sans doute inférieur à 200 (nombre de développeurs recensés pour la version 2.0). Le succès de Linux résulte sans doute en partie de facteurs impondérables : pourquoi l'appel initial de Torvalds a-t-il séduit d'emblée ? La réponse à cette question est sûrement complexe, mais en tout cas le succès est incontestable. Ce qui est sûr, c'est que l'appel à contribution d'août 1991 répondait à une attente et à une frustration largement répandues.

Comme nous pouvons nous y attendre, Linux connaît aussi la division en chapelles. Ici elles s'appellent « distributions ». Au début, la diffusion des éléments de Linux s'effectuait par le réseau, mais assez vite cela devint volumineux et compliqué. Il fallait transférer le noyau lui-même (en code source), ainsi que les logiciels (surtout GNU) sans lequel il aurait été inutilisable, en veillant à la synchronisation des versions compatibles. Au bout de quelques années apparurent des éditeurs qui distribuaient pour un prix modique des CD-ROMs comportant tout ce qu'il fallait pour démarrer.

Par exemple en 1996 on pouvait acheter pour l'équivalent de moins de 30 Euros (somme compatible avec la notion de logiciel libre, puisqu'elle ne rémunérait que la copie, l'emballage et la distribution, pas le logiciel lui-même) le jeu de CD Infomagic, qui comportait notamment la distribution Slackware. La Slackware était une distribution assez ascétique : les différents logiciels étaient simplement fournis sous forme d'archives compressées qu'il fallait compiler, en bénéficiant quand même du logiciel de gestion de configuration make.

D'autres distributions proposent des paquetages : il s'agit de programmes tout compilés. Rassurez-vous, les principes du logiciel libre sont respectés, le paquetage source est fourni à côté. Les distributions RedHat et Debian ont chacune leur format de paquetage, leur logiciel d'installation qui en outre contrôle les dépendances entre paquetages, l'installation et la mise à jour par le réseau, etc. Il faut bien reconnaître que c'est assez pratique. Mais pour le débutant qui se lance dans l'installation de Linux il est néanmoins conseillé d'avoir à proximité un ami qui est déjà passé par là !



1
Adjectif formé sur le nom COBOL, langage de programmation particulièrement aride et punitif.
2
Porter un logiciel d'un ordinateur à un autre ou d'un système à un autre signifie l'adapter aux caractéristiques techniques particulières de ce nouveau contexte. L'opération s'appelle un portage. Un logiciel pour le portage duquel le travail à faire est nul ou négligeable est dit portable ; cette qualité, très recherchée, s'appelle portabilité. Unix est le système d'exploitation le plus portable parce qu'il est écrit pour l'essentiel dans un langage évolué (C) plutôt que dans l'assembleur d'un processeur particulier, et grâce à la bonne abstraction de ses primitives, grâce aussi à la simplicité et à l'élégance de son architecture générale.
3
On sait qu'Alfred Nobel, lorsqu'il créa ses Prix, ne voulut pas en attribuer aux Mathématiques. La légende dit que cette exclusion serait due à une trop grande sympathie qu'aurait éprouvée Madame Nobel pour un certain mathématicien. Pour se consoler les mathématiciens créèrent la médaille Fields, décernée tous les quatre ans. Les informaticiens ont encore plus besoin de consolation, puisqu'ils n'ont même pas réussi à séduire Madame Nobel. Ils ont créé le Turing Award, qui a notamment été décerné, parmi nos personnages, à Maurice V. Wilkes, E.W. Dijkstra, Donald E. Knuth, C. Antony R. Hoare, Frederick P. Brooks, Fernando Corbató, Ken Thompson et Dennis M. Ritchie. Voir http://www.acm.org/awards/taward.html pour plus de détails.
4
Cette prétention flatte la paresse naturelle de l'utilisateur, mais elle est fallacieuse. Il est certes possible, avec tel logiciel de traitement de texte dont le nom signifie « mot » dans une langue germanique et insulaire, de créer facilement un document laid et peu lisible, mais dès lors que l'on veut un résultat présentable il faut se plonger dans la documentation et découvrir que ce logiciel est complexe, tout simplement parce que la typographie est complexe.
5
C'est avec Unix que « développeur » a supplanté « programmeur ». Ces deux termes ont rigoureusement le même sens, « personne dont le métier est la création de programmes informatiques », mais « programmeur » avait été victime d'une dévalorisation injuste. Les premiers managers de l'informatique ont pensé y reproduire un schéma qui était déjà en déclin dans l'industrie : l'ingénieur conçoit, l'ouvrier fait. En informatique l'analyste concevrait ce que le programmeur ferait. Erreur. L'ingénieur disposait, pour transmettre à l'ouvrier la description de ce qu'il devait faire, d'un outil précis et rigoureux, le dessin industriel. Rien de tel en informatique, malgré des efforts qui durent encore pour créer des systèmes de spécification infaillibles dont UML est le dernier avatar. Et à cela il y a des raisons : un ordinateur doté de son système d'exploitation et de ses langages de programmation n'est pas seulement infiniment plus versatile et plus souple qu'un étau-limeur ou qu'une fraiseuse, il est surtout d'une tout autre nature. Il traite de l'information, et comme nous l'avons vu l'information n'est que parce qu'imprévisible. Et l'information qui décrit un programme à réaliser est de la méta-information, puisque le programme est lui-même de l'information. De ce fait la vraie difficulté réside bien toujours dans l'écriture du programme, qui est un exercice incroyablement délicat et laborieux. E.W. Dijkstra se définit lui-même comme programmeur. Mais rien n'y fait, le programmeur sent le cambouis et la sueur, alors que son remplaçant le développeur arbore (jusqu'à la retraite et au-delà) l'uniforme seyant et l'éthos décontracté des étudiants californiens.
6
En fait à cette époque AT&T possédait le monopole des télécommunications aux États-Unis, en contrepartie de quoi il lui était interdit d'avoir une véritable action commerciale dans d'autres domaines comme l'informatique.
7
Pour être juste, il faut dire que si l'intelligence artificielle au sens fort du terme a été une telle source de déceptions depuis l'article fondateur de McCulloch et Pitts en 1943 qu'il est difficile de résister à la tentation de parler d'imposture, ses financements somptueux ont permis la réalisation de produits dérivés du plus grand intérêt, comme les langages LISP, les interfaces graphiques à fenêtres, le système d'édition de texte Emacs et bien d'autres, souvent d'ailleurs des logiciels libres.
8
En fait l'ire fondatrice qui décida de la vocation prophétique du Maître était dirigée contre Xerox et son pilote d'imprimante... Felix culpa. Le lecteur remarquera que malgré leurs péchés AT&T et Xerox jouent un rôle capital dans l'histoire de l'informatique en y apportant plus d'innovations que bien des industriels du secteur.
9
Un système d'exploitation commercial moderne tel que Windows 2000 comporte quelque 30 millions de lignes de programme. Estimer le nombre de lignes de Linux est assez difficile parce qu'il faudrait ajouter à la taille du noyau celle des multiples utilitaires et logiciels généraux qui le complètent. Un décompte sur le répertoire des sources du noyau, qui comporte les pilotes de périphériques et les modules, donne pour la version 2.4.12 (architecture Intel 386) utilisée pour rédiger le présent ouvrage 2 333 129 lignes, auxquelles il faudrait en ajouter presqu'autant pour le système de fenêtrage X, sans oublier les bibliothèques de commandes et de fonctions diverses, mais dont il conviendrait de retirer quelques dizaines de milliers de lignes pour les parties redondantes liées par exemple à des architectures différentes (Intel x86, Alpha, PowerPC, etc.). Le rendement moyen d'un développeur est hautement sujet à controverses, mais si l'on compte les temps consacrés à la rédaction de la documentation et à l'acquisition de connaissances, 50 lignes par jour de travail semble un maximum, soit 10 000 par an et par personne. Mais comme le signale Brooks dans son livre « Le mythe de l'homme-mois » [10], une telle valeur est éminemment trompeuse. La création d'un logiciel est une tâche très complexe, et la division du travail la complique encore en multipliant les fonctions de direction, de coordination et d'échanges d'information, qui peuvent aboutir à ralentir le processus plus qu'à l'accélérer. Manuel Serrano en a tiré les conséquences dans sa thèse d'habilitation [60] en plaidant pour le « logiciel moyen » : les grands logiciels ne seraient devenus encombrants, dans bien des cas, que par la prolifération incontrôlée d'un processus de développement devenu bureaucratique. Une réflexion plus intense d'un groupe plus petit et plus conscient des objectifs à atteindre permettrait d'obtenir un logiciel plus petit et de meilleure qualité.
10
Ramenons ici à de justes proportions la vision que l'on a souvent en France du système universitaire américain, dont les universités seraient autant d'entreprises privées gérées comme des sociétés commerciales et dont les étudiants seraient purement et simplement des clients. Cette vision est simpliste : ainsi l'Université de Californie, organisée autour de huit campus répartis sur le territoire de l'État, reçoit 80% de ses financements de l'État de Californie, de l'État fédéral, des municipalités et d'agences fédérales. Les étudiants californiens y sont admis gratuitement sur des critères de dossier scolaire. D'autres universités ont sans doute des modes de fonctionnement plus éloignés du service public français, bref, les situations sont variées et il n'est pas certain que les formations universitaires soient plus réservées aux catégories privilégiées là-bas qu'ici, même si les barrières ne sont pas disposées de la même façon.
11
Hurd est fondé sur un micro-noyau, ce n'est donc pas un noyau. Voir chapitre 10.
12
POSIX (Portable Operating System Interface) est une norme de l'IEEE qui définit une API (Application Program Interface) et une interface de commande pour les systèmes d'exploitation, assez inspirés d'Unix. La première version de POSIX a été rédigée en 1986 par un groupe de travail auquel appartenait notamment Richard M. Stallman. Cet effort de normalisation fut au départ assez mal reçu par une communauté Unix plutôt libertaire : je me rappelle une conférence Usenix à la fin des années 1980 où certains participants arboraient un badge « Aspirin, Condom, POSIX ». Mais il est certain que POSIX fut salutaire.
© copyright Éditions Vuibert et Laurent Bloch 2003
Page d'accueil de ce livre
Précédent Remonter Suivant