La route vers GNU
Richard Stallman décrit les expériences qui l'ont préparé au combat pour un monde de logiciel libre.
Aux environs d'avril 1983, Stallman a écrit l'introduction du dictionnaire d'argot informatique The Happy Hacker (Le hacker heureux). Dans ce texte, il parle de ses expériences au laboratoire d'IA du MIT et de la guerre des machines Lisp. Il y décrit également comment Emacs a été développé. Le document qui suit est une version mise à jour fin 1983, peu de temps après la première annonce de GNU.
Table des matières
- Le labo d'intelligence artificielle
- La philosophie transparaît dans les réalisations du labo
- Quel est le nom de ton imprimante ?
- Le labo est trahi
- La guerre est déclarée
- Où aller maintenant ?
Danse folklorique à la salle des machines, jeudi 20 h
Venez célébrer la joie de programmer
avec les ordinateurs les plus sympas du monde.
Nous n'étions que cinq danseurs, mais nous nous sommes bien amusés.
Ma première rencontre avec l'informatique s'est faite en camp d'été, au travers des manuels de divers langages que j'empruntais aux moniteurs. Fasciné par le concept de programmation, j'écrivais des programmes sur papier. Je devais me creuser la cervelle pour trouver quoi faire faire aux programmes, parce que je n'avais rien pour me fixer un but, à part le désir de programmer. J'ai écrit des programmes pour additionner les cubes d'un tableau de nombres en plusieurs langages assembleur à diverses périodes.
Les premiers vrais ordinateurs que j'ai rencontrés étaient des IBM 360, au centre scientifique d'IBM à New York, quand j'étais au lycée. Là, j'ai vite commencé à m'intéresser à la conception de langages, de systèmes d'exploitation et d'éditeurs de texte. Recruté sur un job d'été pour écrire un programme ennuyeux d'analyse numérique en Fortran, j'ai surpris mon patron en le terminant au bout de deux semaines et ai passé le reste de l'été à écrire un éditeur de texte en APL.
Je n'ai pas tardé à montrer quelques lacunes en ce qui concerne le respect dû à l'autorité. L'accès à l'ordinateur IBM du bâtiment avait été interdit à tout le centre et nous devions nous connecter par une ligne téléphonique poussive au centre scientifique de Cambridge. Un jour, un dirigeant d'IBM est venu nous parler des travaux effectués dans les différents centres scientifiques d'IBM et a terminé par ces mots : « Naturellement vous connaissez tous le travail important qui est fait ici. » Je lui ai demandé : « Si notre travail est si important, pourquoi ne pouvons-nous plus utiliser l'ordinateur de ce bâtiment ? » Après la réunion, mes amis m'ont dit qu'ils avaient voulu soulever cette question, mais avaient peur des représailles ! Pourquoi ? C'est sûr que rien ne m'est arrivé par la suite. Ils semblent avoir appris à faire profil bas devant l'autorité même lorsqu'ils ne sont pas menacés. Sympa pour l'autorité. J'ai décidé de ne pas apprendre cette leçon-là.
Le labo d'intelligence artificielle
Le centre scientifique de New York a fermé juste à temps pour que je parte à l'université. J'ai constaté que le centre scientifique de Cambridge ne s'intéressait pas à moi, une grande chance, car cela m'a évité de rester dans l'ignorance des ordinateurs non IBM, bien supérieurs, en particulier les PDP-10 et PDP-11 de Digital. Conscient désormais que les ordinateurs ne sont pas tous aussi divertissants les uns que les autres, j'ai fureté pour découvrir les plus jouissifs et les ai trouvés au Labo d'intelligence artificielle du MIT. Il y avait là un groupe de gens qui se désignaient comme « hackers » et avaient créé leur propre système en temps partagé, le « système incompatible en temps partagé » [Incompatible Timesharing System], conçu spécialement pour favoriser le bidouillage [hacking]. C'est là qu'étaient maintenus l'ITS et tous ses programmes utilitaires (y compris le programme de débogage DDT qui était aussi le shell appelé HACTRN). Je suis venu chercher de la documentation pour leur système (quelle naïveté de ma part). Je suis ressorti sans documentation puisqu'elle n'existait pas, mais avec un job d'été. J'avais été recruté par un ingénieur-administrateur, Russel Noftsker – ironie du sort, le même qui plus tard devait jouer un rôle essentiel dans la ruine du labo. Le job est devenu permanent et perdure à ce jour.
Après avoir démontré mes compétences, j'ai eu carte blanche sur l'ensemble du système d'exploitation, une opportunité d'apprendre et d'être productif que peu d'autres labos ou entreprises m'auraient donnée. L'attitude des hackers était : « Si tu peux faire du bon boulot, vas-y, qui que tu sois. »
En comparant avec le labo d'IA, j'ai pris la mesure de l'absence de liberté et des difficultés inutiles qui existaient ailleurs. Chez IBM et à Harvard, le pouvoir était distribué très inégalement. Certaines personnes donnaient des ordres et les autres (à part moi) les prenaient. Les professeurs avaient leurs propres terminaux, qui étaient d'habitude inutilisés, tandis que souvent le reste d'entre nous ne pouvait pas travailler parce qu'il n'y avait pas assez de terminaux partagés. Les gens demandaient : « Es-tu autorisé à faire ça ? » plutôt que « Est-ce que tu sais faire ça ? Est-ce que c'est constructif ? » Ils préféraient que le travail soit fait par un idiot agréé plutôt que par un génie inconnu. J'ai cessé de fréquenter le labo d'informatique de Harvard parce que le MIT était bien mieux. (Je faisais des études de physique ; un hacker naturel n'a pas besoin de prendre des cours d'informatique, car bidouiller des programmes exigeants en compagnie de bons hackers est une meilleure formation.)
Au labo d'IA, la mentalité était différente. Nous avions pour tradition de forcer la porte de tout professeur qui osait enfermer un terminal dans son bureau. À son retour, il trouvait la porte ouverte et une note disant : « Merci de ne pas nous faire perdre notre temps à déverrouiller ce terminal. » Les terminaux sont faits pour être utilisés et c'est du gâchis de les laisser au repos. Nous avions la même attitude envers le temps de calcul. Le PDP-10 exécute 300 000 instructions à la seconde. Si aucun utilisateur ne demande à les utiliser, il les dépense à compter le temps pendant lequel il n'a rien à faire d'utile. Il est préférable qu'elles soient utilisées par n'importe qui dans un but constructif quelconque plutôt que gaspillées. Aussi, nous acceptions les « touristes » (utilisateurs invités) tant qu'ils ne nous gênaient pas. Nous les encouragions à apprendre comment marchait le système, en essayant de repérer les quelques-uns d'entre eux qui deviendraient hackers et nous rejoindraient. Il y a eu au moins deux membres de l'équipe et un professeur du MIT qui ont débuté comme ça.
J'ai constaté que les systèmes informatiques reflétaient ces différences de mentalité entre organisations. Par exemple, la plupart des systèmes sont conçus avec des dispositifs de sécurité qui permettent à quelques personnes de dire à toutes les autres ce qu'elles peuvent et ne peuvent pas faire. Cette minorité a le pouvoir et personne ne peut le contester. Nous, les hackers, appelions ceci du « fascisme » parce que de tels systèmes ont en réalité l'organisation sociale d'États policiers totalitaires.
Pour empêcher les utilisateurs de désactiver la sécurité, une forteresse doit être érigée autour des programmes système. Toutes les voies permettant de traverser l'enceinte doivent être gardées, sinon les masses opprimées vont s'y faufiler. Il se trouve que c'est impossible pour l'ordinateur de faire la distinction entre ces entrées furtives et bien d'autres opérations que les gens ont souvent besoin de faire au cours de leur travail. Puisqu'il est plus important d'assurer la sécurité que de faire avancer le travail, toutes ces opérations sont interdites. Au final, vous devez souvent demander à un membre de l'élite de faire à votre place quelque chose que vous n'avez pas le droit de faire. Si votre tête ou quoi que ce soit d'autre chez vous ne lui revient pas, ou bien s'il veut un pot-de-vin, il peut sans grand effort rendre votre travail deux fois plus difficile que nécessaire.
Il va sans dire que seule l'élite sera habilitée à modifier ou installer un programme système, sous peine de voir ses subalternes y glisser un « cheval de Troie » pour désactiver la sécurité. (Cette restriction est mise en œuvre au moyen de la « protection de fichier ».) Tout l'opposé du labo d'IA où l'on considérait qu'un touriste travaillant sur les programmes du système commençait à se rendre utile et à devenir hacker. Avec leur méthode, moins de gens peuvent contribuer à améliorer le système et les utilisateurs adoptent une attitude fataliste et désespérée envers les défauts du système. Ils prennent une mentalité d'esclaves.
À un endroit comme Digital Equipment, même les gens dont le travail est d'améliorer le système doivent composer avec tant de bureaucratie que leur efficacité et leur moral sont divisés par deux. Comme le dit Robert Townsend dans Up the Organization (Au sommet de l'organisation), la plupart des institutions démoralisent leurs employés et gaspillent leur potentiel en les empêchant de faire leur travail correctement. Sur un système informatique, on obtient ce résultat avec la sécurité et les privilèges.
La plupart des gens acceptent de tels régimes parce qu'ils s'attendent à ce que leur travail soit pénible et n'espèrent rien d'autre de leurs jobs que de l'argent. Mais pour les hackers, le bidouillage était plus que « juste » un job ; c'était un mode de vie. Pour s'assurer qu'ils n'auraient pas ce genre de problème, les premiers hackers omettaient les dispositifs de sécurité et la protection de fichier dans la conception du système. Les utilisateurs de notre système étaient des hommes libres auxquels on demandait de se conduire de manière responsable. Plutôt qu'une élite de pouvoir, nous avions une élite de savoir composée de quiconque était motivé pour apprendre. Puisque personne ne pouvait dominer les autres sur notre machine, le labo fonctionnait sur un mode anarchique. Le succès visible de cette organisation fit de moi un anarchiste [1]. Pour la plupart des gens, « anarchie » signifie « désordre entraînant gaspillage et destruction », mais pour un anarchiste comme moi cela voulait dire organisation volontaire selon les besoins, mettant l'accent sur les objectifs et non sur les règles, sans exiger l'uniformité par principe. Anarchie ne veut pas dire loi de la jungle. La société américaine est déjà une jungle où chacun s'entre-dévore, et ses règles entretiennent cet état de fait. Nous souhaitons remplacer ces règles par un souci de coopération constructive.
Sur la plupart des systèmes informatiques, protéger les fichiers signifie qu'on fait très attention au moyen de limiter qui peut faire quoi avec vos fichiers. On apprend aux utilisateurs à considérer la protection de fichier comme la seule chose qui préserve leur travail d'une destruction journalière. Nous, les hackers, qui avons vécu des années sans protection de fichier et sans avoir le sentiment que nous manquions de quelque chose, nous appelions leur attitude « paranoïa ». Il était très utile que tout soit accessible dans le système ; cela voulait dire qu'un bogue ne pouvait pas se cacher dans un fichier qu'on n'avait pas le droit de corriger.
Nous avons transposé ces comportements à la conception de langages de programmation. Regardez le mouvement pour la « programmation structurée », avec sa plateforme « bannir le GOTO ». Ces gens disaient : « Vous tous, programmeurs, êtes incompétents à part notre petite minorité. Nous savons comment vous devez programmer. Nous allons concevoir des langages qui vous forcent à programmer de cette façon, puis nous vous forcerons à les utiliser. » Nous, les hackers, pensions qu'un moyen plus approprié d'améliorer les langages de programmation était d'identifier et de fournir des constructions plus faciles à utiliser ; d'aider l'utilisateur à écrire de bons programmes plutôt que de le harceler s'il en écrivait de mauvais. Et nous mettions à la disposition des utilisateurs les moyens de créer leurs propres constructions s'ils n'aimaient pas celles que nous leur fournissions.
La philosophie transparaît dans les réalisations du labo
La mentalité du labo d'IA fait intrinsèquement partie de mon travail le mieux connu, l'éditeur plein écran EMACS (auquel Guy Steele et d'autres ont contribué). De nos jours, les éditeurs plein écran (programmes de « traitement de texte ») sont courants et on les trouve sur tous les ordinateurs personnels. En 1973, les terminaux d'affichage étaient plus chers que les imprimantes, aussi la plupart des gens se servaient toujours de terminaux d'impression, et ceux qui avaient des terminaux d'affichage les utilisaient d'habitude comme si c'était des terminaux d'impression (c'est-à-dire, comme « Glass TTY »). Le labo d'IA avait des terminaux d'affichage mais pas encore d'éditeur plein écran.
EMACS est inhabituel parmi les éditeurs plein écran parce qu'il est puissant et extensible. Il contient ses propres ressources de programmation, dont je me suis servi pour ajouter des commandes que les autres éditeurs n'ont pas, et dont les utilisateurs peuvent se servir pour ajouter les commandes qu'ils souhaitent et que je ne leur ai pas fournies. Les utilisateurs peuvent faire des bibliothèques de commandes et les partager, et lorsqu'ils font du bon travail, ces bibliothèques sont intégrées au système EMACS standard, simplement en les incluant dans le manuel.
Beaucoup d'autres éditeurs permettaient de faire des « macros ». EMACS a un langage de programmation destiné à écrire des commandes d'édition, complètement distinct du langage d'édition habituel. Puisqu'il n'est pas conçu comme langage d'édition, on peut en faire un langage de programmation bien meilleur, adapté à l'écriture de programmes compliqués. Le second ingrédient est l'absence de distinction entre « implémenteur » et utilisateur. Presque toutes les commandes « intégrées » d'EMACS sont écrites comme des extensions utilisateur. Chaque utilisateur peut les remplacer et les changer pour son propre usage.
Le développement d'EMACS a suivi un parcours qui illustre la nature du labo. Quand je suis arrivé, l'éditeur était TECO, un éditeur pour terminal d'impression un peu plus programmable que les autres. L'utilisateur tapait une suite de plusieurs commandes et ensuite TECO les exécutait. Sur un terminal d'affichage, TECO savait comment réafficher le texte d'un fichier après chaque suite de commandes. Le moyen naturel pour faire de l'édition plein écran était de l'ajouter à TECO et d'adapter le mécanisme existant de réaffichage.
À l'origine, l'éditeur plein écran n'était que l'une des commandes de TECO. Sa puissance était très limitée, et si l'on avait besoin de faire quoi que ce soit de compliqué, comme d'enregistrer le fichier sur disque ou de rechercher une chaîne de caractères, on quittait cet éditeur pour utiliser le TECO de base pendant quelque temps. Puis un utilisateur suggéra que je fournisse deux commandes d'édition que l'utilisateur pourrait ajouter à une suite de commandes TECO (ou « macro ») sauvegardée. En implémentant ceci, je découvris qu'il était tout aussi facile de laisser l'utilisateur remplacer n'importe laquelle des commandes d'édition plein écran par une suite de commandes TECO sauvegardées.
Ceci déclencha une explosion. Tout le monde et son père écrivait sa propre collection de commandes redéfinies pour l'édition plein écran, une commande pour chacune de ses opérations préférées. Les gens se les passaient de l'un à l'autre et les amélioraient, ce qui les rendait plus puissantes et plus générales. Les collections de redéfinitions sont petit à petit devenues des programmes système à part entière. Leur champ s'est étendu, de sorte qu'il y avait de moins en moins de raisons d'utiliser TECO pour l'édition proprement dite. C'est devenu un simple langage de programmation pour écrire des éditeurs de texte. Nous avons commencé à le catégoriser mentalement comme langage de programmation plutôt que comme éditeur avec fonction additionnelle de programmation. Cela voulait dire qu'on le comparait aux autres langages de programmation plutôt qu'aux autres éditeurs. Il s'ensuivit une demande pressante pour de nombreuses fonctionnalités que possédaient les autres langages de programmation. J'ai amélioré TECO dans ce sens, tandis que d'autres hackers utilisaient les nouvelles fonctionnalités pour améliorer leurs éditeurs écrits en TECO.
Après environ deux ans de cette évolution débridée, Guy Steele a décidé d'écrire un éditeur unique qui combinerait les meilleures idées de tout le reste. Nous avons commencé ensemble, mais il a rapidement dérivé vers ses autres intérêts. J'ai appelé l'éditeur EMACS, pour « editing macros » (macros d'édition) ; je voulais aussi que le nom de ce nouvel éditeur ait une abréviation d'une seule lettre, et « E » était l'une des lettres non encore utilisées.
Ainsi, le langage standard des commandes EMACS était le résultat d'années d'expérimentation faite par de nombreux utilisateurs-mainteneurs sur leurs propres éditeurs. Ce n'était possible que grâce à l'extensibilité d'EMACS et à la mentalité du labo d'IA, qui encourageait les utilisateurs à étendre le système. Le jour fatidique où j'ai donné aux utilisateurs le pouvoir de redéfinir leurs propres éditeurs pein écran, je ne savais pas que cela aboutirait à un nouvel éditeur révolutionnaire. Je suivais l'heuristique du labo d'IA, à savoir qu'il est toujours bon de donner plus de pouvoir à l'utilisateur. Les attitudes du labo d'IA encourageaient ensuite les utilisateurs à faire usage de ce pouvoir et à partager ce que cela leur avait permis de produire.
J'ai travaillé sur EMACS pendant à peu près cinq ans, le distribuant à tous librement [free] à condition que chacun redonne toutes les extensions qu'il produirait, afin d'aider à améliorer EMACS. J'ai appelé cet arrangement la « commune d'EMACS ». Puisque je partageais, c'était leur devoir de partager, de travailler avec les autres plutôt que contre eux. EMACS est maintenant en usage dans tous les meilleurs départements d'informatique des universités et à un tas d'autres endroits. Il a aussi été imité une dizaine de fois. Je constate malheureusement que beaucoup de ces imitations manquent de la véritable essence d'EMACS, qui est son extensibilité ; ce sont des « ersatz d'EMACS », qui en imitent seulement l'apparence superficielle.
De nos jours, les utilisateurs d'EMACS n'éditent presque plus avec TECO et la plupart ne connaissent même pas TECO. En fait, j'ai oublié comment on édite avec ce programme. J'ai tellement pris l'habitude de penser en termes de programmation avec TECO que dans les rares occasions où j'ai eu besoin de l'utiliser comme éditeur, j'ai été perdu pendant une minute ou deux. Les réflexes avaient disparu.
J'ai repéré un des signes qu'une amélioration de l'éditeur a de la valeur : après l'avoir utilisée pendant quinze jours, j'oublie comment on fait sans elle. Cela prouve que j'ai dû faire un gros effort pour entretenir mes anciennes habitudes.
Je ne pense pas qu'un équivalent d'EMACS aurait pu être développé commercialement. Les entreprises n'ont pas la mentalité adéquate. L'axiome de base du monde des affaires affirme que les utilisateurs sont incompétents et que, s'ils ont un contrôle quelconque sur le système, ils vont le détraquer. L'objectif principal est de ne leur donner ni occasion particulière de se plaindre, ni moyen de s'aider eux-mêmes. C'est pour la même raison que la FDA a préférerait tuer un millier de gens en empêchant la mise sur le marché de médicaments, plutôt qu'une seule personne en autorisant un médicament par erreur. L'objectif secondaire est de donner aux dirigeants du pouvoir sur les utilisateurs, parce que ce sont les dirigeants qui décident quel système acheter et non pas les utilisateurs. Si l'éditeur produit par une entreprise a une possibilité quelconque d'extensibilité, ils vont probablement laisser le dirigeant décider pour vous et ne pas vous laisser le moindre contrôle. Pour ces deux raisons, une entreprise n'aurait jamais conçu un éditeur donnant aux utilisateurs la possibilité d'expérimenter comme l'a fait le MIT, et ils n'auraient pas pu s'appuyer sur les résultats des expérimentations pour produire un EMACS. De plus, l'entreprise n'aurait pas envie de vous donner le code source, et sans lui il est beaucoup plus difficile d'écrire des extensions.
Quel est le nom de ton imprimante ?
Alors que j'installais une nouvelle police pour le manuel d'EMACS sur le système d'une imprimante laser du labo, j'ai remarqué que le menu d'initialisation avait un emplacement pour changer le nom de l'imprimante apparaissant sur la page de couverture de chaque tirage. (Cette fonctionnalité était importante quand on avait plusieurs imprimantes et qu'on voulait savoir laquelle avait produit le tirage.) Notre imprimante s'appelait « Tremont », un petit nom mièvre et sans signification. En tant que hacker, je me devais de le remplacer par quelque chose de plus amusant. Je choisis « Kafka », pour suggérer des associations dérangeantes. (Avez-vous entendu parler de l'homme qui s'est réveillé un matin sous la forme d'une imprimante laser ?)
Les jours suivants, les autres hackers n'arrêtaient pas de parler de ce nouveau nom et de suggérer d'autres noms amusants (« Treemunch », « Thesiscrunch », « Cthulhu », etc.) J'ai essayé chaque nom pendant quelques jours tout en récoltant d'autres suggestions. Tout le monde ou presque s'amusait beaucoup. La seule exception était un professeur qui me dit que je n'étais pas autorisé à faire ça et que je devais arrêter. Je répondis que je savais de première main que cela amusait les gens, et que donc je devais continuer, au moins tant que le flot de suggestions se maintiendrait. À la fin, je lui dis d'un ton sévère et officiel qu'il n'était pas autorisé à dire que le bidouillage était interdit.
Le pauvre ne s'en tint pas là. Il dit : « Si tu penses que c'est si amusant de renommer l'imprimante, pourquoi est-ce que tu ne renommes pas les PDP-10 ? » C'était vraiment une brillante idée pour laquelle je lui garde toute ma reconnaissance. Le lendemain, le PDP-10 DM (qui hébergeait Zork) fut renommé Dungeon Modelling au lieu de Dynamic Modelling b, le PDP-10 ML (utilisé pour la recherche en mathématiques et en prise de décision médicale) fut appelé Medical Liability au lieu de Math Lab c, le PDP-10 MC devint Maximum Confusion au lieu de MACSYMA Consortium et le PDP-10 AI fut appelé Anarchists International au lieu d'Artificial Intelligence. Je n'ai plus entendu personne se plaindre.
Le labo est trahi
Il existe toujours une institution appelée « Labo d'intelligence artificielle du MIT » et j'y travaille toujours, mais ses vertus d'autrefois ont disparu. Une entreprise dérivée lui a porté un coup mortel ; cela a changé sa nature fondamentalement et, je crois, définitivement.
Pendant des années, nous étions les seuls, au labo d'IA et dans quelques autres labos, à apprécier les meilleurs logiciels. Quand nous parlions des vertus de Lisp, les autres programmeurs nous riaient au nez sans trop savoir de quoi ils parlaient. Nous les ignorions et poursuivions notre travail. Ils disaient que nous étions dans une tour d'ivoire.
Puis certaines parties du « monde réel » réalisèrent que nous avions eu raison depuis le début à propos de Lisp. Un grand intérêt commercial pour ce langage se manifesta. C'était le début de la fin.
Le labo d'IA venait de développer la « machine Lisp », un ordinateur personnel ayant un grand espace d'adresses virtuelles pour pouvoir exécuter de très grands programmes Lisp. On voulait maintenant produire la machine commercialement pour que tous les autres puissent en avoir une. L'inventeur de la machine Lisp, l'über-hacker Richard Greenblatt, établit un projet pour créer une entreprise de hackers non conventionnelle qui devait croître lentement mais régulièrement, sans battage médiatique et sans la gloutonnerie ni la brutalité des entreprises américaines typiques. Il avait pour objectif de procurer un financement alternatif aux hackers et au hacking tout en fournissant au monde des machines Lisp et de bons logiciels, plutôt que de simplement maximiser les profits. Cela voulait dire se passer pour l'essentiel d'investissement extérieur, puisque les investisseurs exigeaient des méthodes conventionnelles. Cette entreprise est Lisp Machines Incorporated, généralement appelée LMI.
Les autres personnes du projet de machine Lisp croyaient que cela ne marcherait pas et critiquaient Greenblatt pour son manque d'expérience des affaires. En réponse, Greenblatt amena son ami Noftsker, qui avait quitté le labo pour l'industrie quelques années auparavant. Noftsker était réputé avoir l'expérience des affaires. Il a rapidement prouvé la justesse de cette impression par un coup de poignard dans le dos tout à fait digne de ce monde-là : avec d'autres hackers, il lâcha Greenblatt pour fonder une autre entreprise. Leur projet était de rechercher de gros investissements, de croître aussi rapidement que possible, de créer un raz de marée, et que le diable emporte les gens ou les choses qui s'y noieraient. Même si les hackers ne devaient recevoir qu'une petite fraction des fortunes que l'entreprise projetait de gagner, cela les rendrait riches ! Ils n'auraient même pas à travailler plus dur. Ils devaient seulement cesser de coopérer avec les autres comme ils en avaient eu l'habitude.
Il en est résulté deux entreprises de machines Lisp qui se faisaient concurrence : LMI de Greenblatt et Symbolics de Noftsker (généralement appelée « Slime » ou « Bolix » au labo d'IA). Chaque hacker du labo était associé à l'une ou l'autre, sauf moi, parce que même LMI impliquait des compromis moraux que je ne voulais pas faire. Par exemple, Greenblatt est contre les systèmes d'exploitation propriétaires mais approuve les applications propriétaires ; je ne veux pas refuser de partager l'un ou l'autre de ces programmes.[2]
Symbolics s'est mis immédiatement à lever des millions de dollars et à recruter avec insistance tous les gens du MIT qui n'y étaient pas solidement attachés. Greenblatt avait prévu que les gens partageraient leur temps de travail entre LMI et le labo d'IA, de manière à minimiser le traumatisme pour le labo. Symbolics a porté des accusations de conflit d'intérêt, ce qui a forcé les gens de LMI à quitter le MIT à leur tour. Soudain, j'étais le dernier hacker. Une seule personne, ce n'est pas assez ; le labo était en train de mourir.
Je soupçonne fort que la destruction du labo d'IA était un acte délibéré. Une fois qu'un homme d'affaires a mis la main sur un œuf d'or, il tue la poule pour s'assurer qu'il a un monopole.
Il m'est pénible de remuer les souvenirs de ce temps-là. Les gens qui restaient au labo étaient les professeurs, les étudiants et les chercheurs non hackers, qui ne savaient pas comment entretenir le système ni le matériel, ou ne voulaient pas le savoir. Les machines ont commencé à tomber en panne sans être jamais réparées [3] ; quelquefois on les jetait. Les modifications nécessaires du logiciel ne pouvaient pas être faites. Les non-hackers réagissaient en se tournant vers des systèmes commerciaux qui apportaient avec eux le fascisme et les contrats de licence. J'errais dans le labo, traversant ces pièces si vides la nuit alors qu'elles avaient été si peuplées, en pensant : « Oh, mon pauvre labo d'IA, tu es en train de mourir et je ne peux pas te sauver. » Chacun s'attendait à ce que, si d'autres hackers étaient formés, ils soient immédiatement recrutés par Symbolics ; il semblait que ce n'était même pas la peine d'essayer. L'administration du labo ne fit aucun effort pour nous remobiliser et l'administration du MIT se comporta de manière aussi rapace qu'une entreprise à but lucratif, ce qui démoralisa les gens encore davantage.
Par le passé, il y avait eu de temps à autre des départs de hackers, mais des remplaçants avaient été formés par ceux qui restaient. Maintenant la culture était entièrement balayée, il ne restait pas assez d'anciens pour inspirer les nouvelles recrues et pas d'excellence pour attirer les meilleurs. Par exemple, les hackers avaient l'habitude de se réunir chaque jour pour le repas du soir (habituellement chinois). Une personne donnée n'était pas là tous les jours, mais on pouvait être sûr d'en trouver d'autres pour aller manger à l'heure du dîner. Maintenant cette pratique se perdait ; lorsque les gens n'ont plus eu l'espoir d'en trouver d'autres pour aller manger ensemble, ils on perdu l'habitude de se montrer affamés à l'heure habituelle, amorçant ainsi un cercle vicieux.
L'ensemble du labo d'IA avait un seul numéro de téléphone et un système de sonorisation public. (Notre extension était le 6765 et nous répondions aux appels par « 6765 », ou « Fibonacci de 20 » parce que 6765 est le vingtième nombre de Fibonacci.) Il était facile de contacter tout un chacun en appelant ce numéro. Maintenant, la plupart des gens et des terminaux ont déménagé à d'autres étages qui ne sont pas couverts par le 6765, et le neuvième étage, cœur historique du labo, se remplit de machines. Ce changement réduit encore plus la cohésion sociale du labo. Désormais, je ne peux même pas appeler pour savoir si quelqu'un a faim et personne ne peut me contacter par téléphone.
C'est ainsi que j'ai perdu d'un coup mon réseau social, l'opportunité de poursuivre une carrière dans la droiture et presque tout ce que j'avais aidé à construire. J'avais l'impression d'être le dernier survivant d'une tribu perdue, condamné à passer ma vie parmi des étrangers incompréhensibles. Il y avait peu de chances de construire un nouveau labo ayant les qualités du labo d'IA si un labo existant, préalablement en bonne santé, ne pouvait pas survivre à la pression. L'industrie informatique ne serait pas disposée à me laisser partager avec les autres hackers comme le veut la règle d'or. J'ai commencé à chercher une nouvelle carrière sans rapport avec l'informatique, mais n'espérais pas en trouver une. Je ne me voyais pas d'avenir à part travailler sur des programmes de comptabilité ou autre, sans aucun intérêt pour un hacker (moi y compris). Ce serait une vie dénuée de sens, mais au moins je n'aurais pas la honte de refuser de partager avec d'autres hackers s'ils ne voulaient pas de ce que je faisais. Je n'étais pas sûr que ce soit préférable à une forme plus radicale de suicide.
Pendant un an à peu près, il y a eu LMI, Symbolics et les restes du labo d'IA. Tous trois partageaient le système d'exploitation de la machine Lisp. De temps à autre les hackers de Symbolics répondaient à un rapport de bogue en disant : « Ceci ne peut pas être corrigé sur le système actuel. Attendez notre nouvelle machine. » C'était pour faire apparaître la nouvelle machine comme un grand progrès. Cela m'amusait beaucoup d'annoncer, peu de temps après, que j'avais déjà corrigé le bogue.
La guerre est déclarée
Mais la situation devait s'aggraver, parce que LMI n'a pas été l'échec que Symbolics avait prédit à grands cris. Ils fabriquaient et vendaient des machines Lisp, et les vendaient beaucoup moins cher que Symbolics, qui avait un investissement gigantesque à amortir et un tas de salaires à payer. Après environ un an, Symbolics a réalisé que son triomphe, inévitable et annoncé à grand renfort de publicité, ne se matérialiserait pas sans des mesures plus violentes. Leur plan : cesser le partage à trois des améliorations logicielles. Puisque LMI était beaucoup plus petite, ils s'attendaient à ce qu'elle soit incapable de suivre la cadence. (Le labo d'IA n'était plus considéré comme un contributeur significatif.)
Symbolics exigea que le labo d'IA se soumette à de nouvelles conditions : utiliser les améliorations faites par Symbolics, mais ne pas les partager avec LMI [4]. Cette exigence fut annoncée dans le style novlangue comme un formidable acte de générosité. En fait, la permission pour le MIT de continuer à utiliser leurs améliorations n'était rien d'autre qu'une nouvelle tactique destinée à enfermer le labo dans une relation de dépendance. Le labo leur enverrait les rapports de bogues et les démos et achèterait uniquement chez eux. Ce n'est pas une motivation inhabituelle. C'est justement pour cette raison que de nombreuses entreprises font don au MIT des ordinateurs qu'elles fabriquent. Mais d'habitude elles essaient de gagner la coopération du MIT par la générosité plutôt que par la menace.
Symbolics s'attendait sans doute à ce que le labo cède immédiatement et se reporte entièrement sur leur marque de logiciel. Mais j'ai refusé de capituler, d'être enrôlé par Symbolics pour les aider contre LMI. LMI était davantage digne de mon aide. N'ayant plus le droit de rester neutre, je me battrais contre ceux qui me forçaient à me battre [5].
Au lieu d'utiliser les améliorations de Symbolics, j'ai fait des améliorations similaires sur le dernier système partagé. La plupart des utilisateurs du labo ont continué à utiliser le système du MIT ; certains parce qu'ils n'aimaient pas Symbolics, d'autres parce qu'ils le considéraient comme techniquement supérieur et d'autres encore parce qu'ils avaient plus de liberté pour le modifier. Au cours des trois derniers semestres, j'ai fait en sorte que le système du MIT demeure tout aussi bon et quelquefois meilleur [que celui de Symbolics]. Puisque LMI utilisait toutes les améliorations que je faisais, LMI également avait un système tout aussi bon. Le refus du partage par Symbolics a surtout causé beaucoup de tracas aux utilisateurs, en raison des incompatibilités entre les deux systèmes.
En général, je laissais Symbolics concevoir une nouvelle fonctionnalité, puis je regardais leur documentation et implémentais quelque chose d'à-peu-près compatible. J'aurais pu tout aussi bien améliorer le système sans faire attention à eux, mais ç'aurait été une mauvaise stratégie. Ils auraient pu copier mes améliorations telles quelles et passer leur temps à en faire de nouvelles ; ou bien ignorer mon implémentation et faire quelque chose de similaire mais incompatible, ce qui aurait causé des ennuis à tous les utilisateurs. Comme dans une course cycliste, on a beaucoup moins de travail si on est juste derrière un autre coureur. En tant que compétiteur isolé face à une grosse équipe, j'ai besoin de cet avantage. Je peux facilement foncer à l'avant, mais ce n'est pas une manière efficace de dépenser mon énergie.
Symbolics riposte par des menaces de poursuites (bien qu'ils n'aient jamais porté plainte) et en essayant de me faire licencier. Le bruit court qu'ils lisent mon courrier électronique plusieurs fois par jour, cherchant quelque chose dont ils pourraient m'accuser ; une fois ils ont été pris et cela s'est retourné contre eux. (C'est contre mes principes de les arrêter avec des dispositifs de sécurité qui punissent tout le monde.) Ils pensent que c'est mal si quelqu'un obtient quelque chose pour rien ; il vaut mieux que cette chose aille au rebut plutôt que de bénéficier à leurs concurrents de manière équitable. C'est ce genre de dissensions qui paralyse notre pays.
En travaillant contre Symbolics de cette façon, non seulement j'échappe à l'obligation de me soumettre à leurs termes, mais j'aide à instaurer la justice et à préparer la punition qu'ils méritent pour avoir détruit l'ancien labo d'IA. Je pensais au début créer un noyau d'autosuffisance pour revitaliser le labo. Mais personne ne m'a rejoint ; désormais chacun s'en tient à sa recherche.
Où aller maintenant ?
Symbolics n'a jamais atteint l'excellence dans le domaine du logiciel, mais leur nouvelle machine plus rapide a été prête avant celle de LMI. Ils en ont déjà livré plusieurs au MIT, et mes utilisateurs sont en train de migrer dessus. Utiliser la version MIT du système sur ces machines n'est pas pratique parce que les machines sont trop différentes.
Du fait de la perte d'utilisateurs, il m'est difficile de vérifier que mes nouveaux logiciels fonctionnent vraiment. Mais avec un peu de chance je pourrais tenir assez longtemps pour empêcher Symbolics de gagner à la fin. LMI vient de commencer ses livraisons. Bientôt ils auront beaucoup de succès et assureront eux-mêmes le développement du système, alors Symbolics sera aux prises avec une concurrence agile et agressive. Une fois que LMI pourra s'en sortir sans mon aide ; les conditions seront réunies pour la punition éventuelle de Symbolics. Alors je pourrai arrêter de travailler sur les machines Lisp. J'ai fixé cette échéance à Thanksgiving de cette année.
Et une fois organisée la punition des malfaiteurs, il sera temps pour moi de reconstruire ce qu'ils ont détruit.
La reconstruction ne peut pas se faire au labo d'IA. Le MIT tente de mettre sous licence tout ce qui est fait ici d'utile ; rester ici et continuer à partager est une lutte en soi. Et de toute façon, ce n'est pas drôle d'être entouré de machines Symbolics et de vendus semi-compétents. J'ai besoin de prendre un nouveau départ, et la première étape est de m'éloigner des ruines du passé. Donc, je vais donner ma démission.
La reconstruction ne peut pas se faire en travaillant sur les machines Lisp. Le MIT déclare posséder le logiciel de la machine Lisp, il ne donc peut pas être partagé secrètement. (LMI est une exception ; ils ont un contrat avec le MIT.) Une telle coopération souterraine est mieux que rien du tout, mais cela ne peut pas constituer un nouveau mode de vie. Il faut une coopération publique, généralisée. Il me semblait préférable de travailler sur le système des machines Lisp plutôt que de laisser Symbolics gagner par défaut, mais il n'est pas bon de vivre de cette façon plus longtemps que nécessaire. Pour la même raison, je ne peux pas travailler pour LMI bien qu'ils soient disposés à laisser une partie de mon travail [dans le domaine] public. Je peux faire des compromis en menant une guerre, mais quand il s'agit de construire quelque chose de correct un tel compromis est inutile, car cela empêcherait tout ce que je construis d'être correct.
Au lieu de ça, j'ai choisi un projet ambitieux qui s'attaque à la racine du mécanisme par lequel le mode de vie commercial, hostile, se perpétue. Je vais écrire GNU, un remplaçant complet pour le système Unix (noyau, compilateurs, utilitaires et documentation), afin de l'offrir librement à chacun.
Grâce à GNU, les hackers pourront facilement décider de vivre dans le partage et la coopération. L'usage d'un ordinateur nécessite un système de logiciels. Actuellement, aucun système de logiciels libres n'est disponible, il faut donc faire un sacrifice immense pour refuser d'utiliser des logiciels propriétaires. Mais une fois qu'un système attractif sera disponible librement, cette pression sera levée pour toujours. Les hackers seront libres de partager.
Je commencerai à Thanksgiving. Je demande aux fabricants d'ordinateurs de faire des dons à la cause, mais je le ferai même si je dois travailler comme serveur. Déjà d'autres programmeurs qui regrettent les façons de faire d'autrefois se rallient à la cause. Venez nous apporter votre aide ! Et peut-être que l'ancien esprit du labo d'IA revivra.
Bon bidouillage
Richard M Stallman
Le hacker heureux
Notes
- J'aimais les modes de vie et de fonctionnement anarchiques du labo d'IA, mais cela ne fait pas de moi un anarchiste jusqu'au-boutiste. Je n'appelais à abolir ni l'État et ses nombreuses actions utiles, ni la possibilité de faire des choix de société démocratiquement. Voir Why we need a state (Pourquoi nous avons besoin d'un État).
- Le labo d'IA restait neutre à l'égard de ces deux entreprises ; je me contentais de prendre part à cette neutralité.
- Le PDP-10 du labo d'IA est tombé en panne en février 1982 et n'a jamais été réparé.
- Symbolics a lancé son ultimatum le 16 mars 1982, qui se trouvait être mon anniversaire. C'est resté dans ma mémoire comme le jour où Symbolics a attaqué le labo d'IA et LMI, dans le but de soumettre le premier pour détruire le second.
- Paradoxalement, ce conflit ouvert m'a tiré de mon désespoir en me montrant quelque chose de positif pour quoi me battre. Je n'étais plus perdu, sans but vers lequel me diriger. Un combat m'était tombé dessus de nulle part, une agression dont la défaite valait que je lui consacre le maximum de mes capacités.