Table des matières
La plupart des projets de logiciel libre échouent.
Nous avons tendance à ne pas trop remarquer les échecs. Seuls ceux qui réussissent attirent notre attention, mais le nombre total[2]de projets de logiciels libres est si conséquent que leur visibilité reste néanmoins importante pour une quantité de réussites relativement faible. De même, nous n'entendons pas parler des échecs car l'insuccès est un non-évènement. Le moment précis où un projet cesse d'être viable n'existe pas : les gens s'en écartent et finissent par l'abandonner. Il se peut qu'à un moment donné un dernier changement soit apporté au projet mais l'auteur, à cet instant, ne sait pas qu'il s'agit du dernier. Comment définir la mort d'un projet ? Est-ce quand on n'y a plus travaillé activement depuis six mois ? Quand le nombre de ses utilisateurs cesse de croître, sans avoir dépassé celui des développeurs ? Et que dire d'un projet abandonné parce que ses développeurs, se rendant compte qu'ils reproduisaient un travail existant, se décident à rejoindre un autre projet pour l'améliorer en y intégrant une grande partie de leurs travaux précédents ? Le premier projet est-il mort ou a-t-il juste changé d'adresse ?
En raison de cette complexité, il est impossible de déterminer précisément le taux d'échec. Mais le constat qui ressort de plus d'une décennie dans l'Open Source, de quelques participations à SourceForge.net et d'un peu de « googlage » est le suivant : ce taux est extrêmement élevé, probablement de l'ordre de 90% à 95%. Il l'est encore plus si l'on y inclut les projets survivants mais qui fonctionnent mal, à savoir ceux qui produisent des applications utilisables sans pour autant être des lieux agréables ou progresser de manière aussi rapide et fiable qu'ils le pourraient.
L'objet de cet ouvrage est d'éviter l'échec. Il passe en revue non seulement les bonnes attitudes à adopter, mais aussi les mauvaises, afin que chacun puisse détecter et corriger les problèmes rapidement. Mon plus grand souhait est qu'après sa lecture, on dispose d'un répertoire de techniques pour, d'une part, éviter les pièges les plus courants du développement Open Source, et d'autre part, gérer la croissance et la maintenance d'un projet réussi. Le succès n'est pas un jeu à somme nulle et cet écrit ne parle ni de victoire ni de maitrise de la concurrence. En réalité, une part importante du développement d'un projet Open Source consiste à travailler sans heurt avec les autres projets apparentés. À long terme, chaque réussite contribue au bien-être du « logiciel libre », dans son ensemble et partout dans le monde.
Il serait tentant de dire les projets de logiciels libres ou propriétaires échouent pour les mêmes raisons. Le libre n'a pas le monopole des cahiers de charges farfelus, des spécifications floues, de la gestion déficiente des ressources humaines, des phases de conception insuffisantes et autres lutins malveillants bien connus de l'industrie du logiciel. La somme d'écrits traitant de ce sujet est déjà considérable, je ne m'étendrai donc pas sur ce sujet. J'essaierai plutôt de décrire les problèmes spécifiques au logiciel libre. Quand un projet s'écroule c'est souvent parce que les développeurs (ou les directeurs) n'ont pas su évaluer les problèmes propres au développement d'un logiciel Open Source, alors même qu'ils étaient rodés aux difficultés mieux connues du développement à code fermé.
Mesurez vos attentes vis à vis de l'Open Source, ne tombez pas dans le piège d'une trop grande attente. Une licence ouverte ne garantit pas que des hordes de développeurs se mettront immédiatement au service de votre projet et ouvrir le code d'un projet en difficulté ne le guérit pas automatiquement de tous ses maux. En fait, c'est plutôt le contraire : ouvrir un projet peut ajouter une nouvelle série de complications et coûter plus cher à court terme que le garder fermé. Ouvrir veut dire remanier le code pour le rendre compréhensible par quelqu'un de complètement étranger au projet, mettre en place un espace Web de développement, des listes de diffusion et, souvent, écrire pour la première fois la documentation. Tout ceci représente beaucoup de travail. Et bien sûr, si des développeurs intéressés se présentent, il faudra les intégrer, répondre à leurs questions, tout cela peut prendre un certain temps avant que vous ne perceviez les bénéfices de leur présence. Comme l'a dit Jamie Zawinski en parlant des périodes troubles du début du projet Mozilla :
L'Open Source fonctionne, mais ce n'est vraiment pas la panacée. La morale de cette histoire c'est qu'on ne peut pas prendre un projet moribond et le saupoudrer de poudre de perlimpinpin « Open Source » pour que tout se mette à marcher par magie. Le développement logiciel c'est difficile. Les solutions ne sont pas si simples.
(extrait de http://www.jwz.org/gruntle/nomo.html)
Lésiner sur la présentation et la création de paquets en remettant cela à plus tard, une fois le projet sur les rails, sont des erreurs liées. La présentation et la création de paquets comportent un nombre important de tâches visant à faciliter l'approche. Pour rendre le projet accueillant aux néophytes, il faut écrire la documentation développeur et utilisateur, créer pour le projet un site Web informant les curieux, automatiser autant que possible la compilation et l'installation du logiciel, etc. Beaucoup de programmeurs considèrent malheureusement ce travail comme secondaire par rapport au code lui-même. Et ceci pour plusieurs raisons. Premièrement, c'est à leurs yeux une perte de temps car ils n'en tirent pas directement les bénéfices contrairement aux personnes moins familières avec le projet. Après tout, les gens qui développent le projet n'ont pas vraiment besoin qu'on leur prépare des paquets. Ils savent déjà comment installer, administrer et utiliser le logiciel qu'ils ont écrit. Deuxièmement, les compétences requises pour la présentation et la création de paquets sont souvent complètement différentes de celles requises pour écrire le code. Les gens ont tendance à se concentrer sur ce qu'ils connaissent le mieux, même s'ils peuvent rendre un meilleur service au projet en consacrant un peu de temps aux choses qui leur conviennent moins. Le Chapitre 2, Genèse d'un projet, examine en détail les questions de présentation et de création de paquets. Il explique pourquoi il est essentiel d'en faire une priorité dès le lancement du projet.
Vient ensuite l'idée fausse que l'Open Source n'a guère besoin de gestion de projet et, qu'inversement les techniques de direction utilisées pour les développements en interne fonctionneront également pour le projet Open Source. Le management dans un projet Open Source n'est pas toujours très visible, mais dans les projets réussis il est toujours présent en coulisse d'une manière ou d'une autre. Inutile de pousser la réflexion très loin pour s'en rendre compte. Un projet Open Source consiste en un assemblage fortuit de programmeurs, catégorie déjà réputée pour son indépendance d'esprit, qui ne se sont très probablement jamais rencontrés et qui peuvent y participer en ayant chacun des objectifs personnels différents. Il est facile d'imaginer ce que deviendrait un tel groupe sans management. À moins d'un miracle, il s'écroulerait ou éclaterait très vite. Les choses ne vont pas marcher d'elles-même, que nous le voulions ou non. Mais le management, aussi actif soit-il, est le plus souvent informel, subtil et voilé. La seule chose qui maintienne un groupe de développeurs ensemble est la croyance partagée qu'ils peuvent faire plus collectivement qu'individuellement. Dans ce cadre, le management a pour but principal de faire en sorte qu'ils continuent à le croire, en établissant des formes de communication, en s'assurant que des développeurs utiles ne sont pas marginalisés en raisons de caractéristiques personnelles et, de manière générale, en faisant en sorte que le projet reste un espace où les développeurs ont envie de revenir. Les techniques spécifiques pour réussir cela sont abordées dans le reste de l'ouvrage.
Enfin, il y a une catégorie générique de problèmes qu'on pourrait appeler « échecs de navigation culturelle ». Il y a dix ou même cinq ans, il aurait été prématuré de parler d'une culture mondiale du logiciel libre : plus maintenant. Une culture reconnaissable a émergé lentement et bien qu'elle ne soit pas monolithique (elle est autant sujette à la dissidence et aux factions que n'importe quelle culture géographiquement définie), elle est basée sur un noyau fondamentalement solide. La plupart des projets Open Source réussis affichent quelques-unes sinon toutes les caractéristiques de ce noyau. Ils récompensent certains types de comportements et en punissent d'autres, ils créent une atmosphère qui encourage la participation non planifiée (parfois au détriment de la coordination centralisée), ils possèdent leur propre conception de la politesse et de la brutalité pouvant différer foncièrement de celle qui prévaut ailleurs. Et, chose primordiale, les participants de longue date ont généralement intériorisé ces critères au point d'être plus ou moins unanimes sur les comportements attendus. Les projets qui échouent généralement s'écartent de manière significative de ce noyau, même involontairement, et n'ont pas de définition unanime de la constitution du comportement raisonnable par défaut. Ainsi, quand les problèmes surgissent, la situation peut se détériorer rapidement, les participants ne disposant pas d'un stock de réflexes culturels établis auxquels recourir pour résoudre les différends.
Cet ouvrage est un guide pratique et non une étude anthropologique ou historique. Cependant, une réelle connaissance des origines de la culture actuelle du logiciel libre est une base essentielle pour tout conseil pratique. Une personne qui en comprend la culture peut parcourir, en long et en large, le monde de l'Open Source, rencontrer maintes variantes locales des coutumes et des dialectes, tout en étant capable de participer partout avec aisance et efficacité. En revanche, pour quelqu'un ne comprenant pas cette culture, le processus d'organisation ou de participation à un projet sera difficile et plein de surprises. Le nombre de personnes qui développent des logiciels libres ne cessant de croître à toute allure, cette dernière catégorie ne désemplit pas. C'est en grande partie une culture de nouveaux migrants, et ça continuera à l'être pendant un certain temps. Si vous pensez être l'un d'eux, la section suivante vous fournit l'arrière-plan des discussions que vous entendrez plus tard, aussi bien dans ce livre que sur Internet (d'autre part, si vous travaillez dans le monde du libre depuis un moment, vous en savez peut-être déjà pas mal sur son histoire. Dans ce cas, n'hésitez pas à sauter la prochaine section).
Le partage des logiciels est aussi ancien que les logiciels eux-mêmes. Aux premiers temps des ordinateurs, les fabricants, sentant que les bénéfices économiques se trouvaient principalement dans la production de matériel, ne prêtèrent guère attention aux logiciels et leurs atouts financiers. Un grand nombre d'acheteurs de ces premières machines étaient des scientifiques ou des techniciens capables de modifier et d'améliorer eux-mêmes les logiciels livrés avec les machines. Parfois les clients distribuaient leurs correctifs non seulement aux fabricants, mais aussi aux propriétaires de machines semblables. Les fabricants toléraient, voire encourageaient ceci : pour eux, l'amélioration des logiciels, peu importe la source, rendait leurs machines plus attrayantes aux yeux d'autres acheteurs potentiels.
Bien que cette période ressemblât, sous de nombreux aspects, à la culture des logiciels libres d'aujourd'hui, elle en déviait sur deux points importants. Premièrement la standardisation du matériel n'était pas vraiment à l'ordre du jour. C'était une époque d'innovation florissante pour la fabrication d'ordinateurs, mais face à la diversité des architectures la compatibilité n'était pas une priorité. Ainsi, les logiciels écrits pour une machine ne fonctionnaient en général pas sur une autre. Les programmeurs avaient tendance à se spécialiser dans une architecture ou dans une famille d'architectures (alors qu'aujourd'hui, ils auraient plutôt tendance à se spécialiser dans un langage de programmation, ou une famille de langages, sachant pertinemment que leur savoir sera transférable sur n'importe quel système auquel ils se trouveraient confrontés). Comme leur expertise tendait à être spécifique à un type d'ordinateur, l'accumulation des savoirs avait pour effet de le rendre plus attractif à leurs yeux et à ceux de leurs collègues. C'était alors dans l'intérêt du constructeur de voir les codes et connaissances spécifiques à sa machine se répandre le plus possible.
Deuxièmement, l'Internet alors n'existait pas. Bien que les restrictions légales vis à vis du partage fussent moins fortes qu'aujourd'hui, elles étaient plus nombreuses sur le plan technique. Les moyens pour transporter les données d'un endroit à un autre étaient peu pratiques et encombrants, comparés à maintenant. Il existait des petits réseaux locaux, pratiques pour partager des informations entre employés du même laboratoire de recherche ou de la même entreprise. Mais certaines barrières restaient à surmonter si l'on voulait partager avec le monde entier tout en s'affranchissant des contraintes géographiques. Ces difficultés ont été surmontées dans de nombreux cas. Parfois des groupes entraient en contact les uns avec les autres indépendamment, en s'envoyant des disquettes ou des cassettes par courrier. Parfois les fabricants eux-mêmes centralisaient les correctifs. Un point positif étant qu'une grande partie des premiers développeurs travaillaient au sein d'universités où la publication des connaissances d'une personne est attendue. Mais les réalités physiques de l'échange de données entraînaient un temps de latence, un retard proportionnel à la distance (physique ou organisationnelle) que le logiciel avait à parcourir. Le partage souple et à grande échelle, comme nous le connaissons aujourd'hui, était impossible alors.
À mesure que l'industrie mûrissait, plusieurs changements liés se sont produits en même temps. La jungle des normes matérielles a progressivement permis l'émergence de quelques lauréats : lauréats grâce à une meilleure technologie, une meilleure stratégie voire la combinaison des deux. En même temps, et pas entièrement par hasard, le développement de langages de programmation dits de « haut niveau » signifiait que l'on pouvait écrire un programme une seul fois, dans un langage, et le voir automatiquement traduit (compilé) pour qu'il puisse fonctionner sur différents types d'ordinateurs. Les constructeurs de matériel n'ont pas manqué de voir les implications : un client pouvait, dès ce moment, entreprendre un travail considérable d'ingénierie logicielle sans s'enchaîner nécessairement à une architecture particulière. Ceci, couplé à une diminution des écarts de performances entre les différents ordinateurs (les conceptions les moins performantes étant évincées), faisait qu'un fabriquant qui misait tout sur le matériel pouvait s'attendre à voir baisser ses marges dans un futur proche. La puissance brute des ordinateurs n'était plus suffisante pour créer un avantage décisif, la concurrence s'est alors déplacée sur le terrain des logiciels. Vendre des logiciels, ou au moins leur donner la même importance qu'au matériel, devenait la nouvelle stratégie gagnante.
Cela signifiait que les fabricants devaient commencer à faire respecter le droit d'auteur sur leur code de manière plus stricte. Si les utilisateurs continuaient à partager et modifier le code de manière libre entre eux, ils pourraient reproduire certaines des améliorations désormais vendues en tant que « valeur ajoutée » par le fournisseur. Pire encore, le code partagé pourrait tomber entre les mains des concurrents. L'ironie est que tout ceci se passait à l'époque où Internet commençait à pointer son nez. Alors même que les obstacles au partage de logiciels tombaient, la mue du marché des ordinateurs l'a rendu économiquement indésirable, au moins du point de vue de n'importe quelle entreprise. Les fournisseurs ont renforcé leurs positions, soit en refusant aux utilisateurs l'accès au code faisant fonctionner leurs machines, soit en imposant des accords de confidentialité rendant tout partage impossible.
Alors que le monde du libre échange de code s'affaiblissait, l'idée d'une riposte germait dans l'esprit d'au moins un programmeur. Richard Stallman travaillait au laboratoire d'intelligence artificielle au MIT (Massachusetts Institue of Technology) dans les années 70 et au début des années 80, durant une période qui s'est révélée être l'âge d'or du partage de code. Le laboratoire avait une forte « éthique de hacker »,[3]et les gens n'étaient pas seulement encouragés à partager les améliorations qu'ils avaient pu apporter au système, c'était ce qu'on attendait d'eux. Comme Stallman écrivit plus tard :
Nous n'appelions pas nos logiciels « logiciels libres » parce que ce terme n'existait pas, mais c'est bien ce que c'était. Si des gens d'une autre université ou d'une entreprise voulait utiliser nos programmes, nous leur en donnions volontiers la permission. Si vous voyiez quelqu'un utiliser un programme intéressant que vous n'aviez jamais rencontré, vous pouviez toujours lui en demander le code source, pour pouvoir le lire, le modifier ou en piller une partie pour faire un nouveau programme.
Cette communauté utopique s'est effondrée autour de Stallman peu après 1980, quand le laboratoire a finalement été rattrapé par les changements qui s'opéraient dans le reste de l'industrie. Une startup débaucha de nombreux programmeurs du laboratoire pour développer un système d'exploitation proche de celui sur lequel ils travaillaient, mais désormais sous licence exclusive. Au même moment, le laboratoire faisait l'acquisition de nouveaux équipements livrés avec un système d'exploitation propriétaire.
Stallman voyait très bien où cette tendance les conduisait :
Les ordinateurs modernes de ce temps, comme le VAX ou le 68020 avaient leur propre système d'exploitation, mais ni l'un ni l'autre n'était libre, vous deviez signer un accord de confidentialité, même pour en obtenir une copie fonctionnelle.
Ce qui signifiait que la première démarche à faire pour utiliser un ordinateur était de promettre de ne pas aider son voisin. Une communauté coopérative était proscrite. La règle mise en place par les créateurs des logiciels propriétaires était : « Si vous partagez avec votre voisin vous êtes un pirate. Si vous désirez des changements suppliez nous de les faire ».
Mais Stallman n'était pas un hacker comme les autres et sa personnalité le poussa à s'opposer à cette tendance. Plutôt que de continuer à travailler dans un laboratoire décimé ou de trouver un emploi de programmeur dans l'une de ces nouvelles compagnies où les fruits de son travail seraient enfermés dans une boîte, il a démissionné pour lancer le projet GNU et la Free Software Foundation (FSF). Le but du projet GNU[4]était de développer un système d'exploitation pour ordinateur complètement libre et ouvert ainsi qu'un ensemble d'applications logiciels dans lequel les utilisateurs ne seraient jamais empêchés d'hacker ou de partager leurs modifications. Il entreprenait en fait de recréer ce qui avait été détruit au laboratoire d'intelligence artificielle mais à l'échelle mondiale et sans les points faibles à l'origine de la destruction de l'esprit du laboratoire.
En plus de travailler sur le nouveau système d'exploitation, Stallman conçut une licence dont les termes garantissent que son code restera libre à tout jamais. La GNU General Public License (GPL) est une pirouette légale bien pensée : elle dit que le code peut être copié ou modifié sans restriction et que les copies ou le travail dérivé ( c'est-à-dire les versions modifiées ) doivent être distribuées sous la même licence que l'original, sans y ajouter de restrictions. En fait, elle utilise les lois du droit d'auteur pour produire l'effet opposé du copyright traditionnel : plutôt que de limiter la diffusion du logiciel, elle empêche quiconque, même l'auteur, de la restreindre. Pour Stallman ça valait mieux que de simplement placer son code dans le domaine public. En appartenant au domaine public, n'importe quelle copie aurait pu être incorporée dans un programme propriétaire (ce qui s'est passé avec du code publié sous des licences trop permissives). Même si cette incorporation ne diminuerait en rien la disponibilité continue du code originel, cela aurait signifié que les efforts de Stallman auraient pu profiter à l'ennemi, le logiciel propriétaire. La GPL peut être vue comme une forme de protection pour le logiciel libre car elle empêche les logiciels non-libres de profiter du code sous licence GPL. La GPL et ses relations avec d'autres licences de logiciels libres sont présentées en détails dans le Chapitre 9, Licenses, Copyrights, and Patents.
Avec l'aide de nombreux développeurs, certains d'entre eux partageant l'idéologie de Stallman et d'autres voulant simplement voir un maximum de code libre disponible, le projet GNU commença à produire des équivalents libres pour beaucoup d'éléments importants d'un système d'exploitation. Grâce à la standardisation du matériel informatique et des logiciels, il était devenu possible d'utiliser les équivalents GNU sur des systèmes non-libres, et beaucoup l'ont fait. L'éditeur de texte GNU (Emacs) et le compilateur C (GCC) en particulier ont rencontré un succès important, rassemblant, non pour l'idéologie qu'ils véhiculaient mais simplement pour leurs mérites techniques, une grande communauté d'utilisateurs loyaux. À l'orée de 1990, GNU avait produit l'essentiel d'un système d'exploitation libre à l'exception du noyau (la partie sur laquelle démarre la machine et qui est en charge de la gestion de la mémoire, des disques et des autres ressources systèmes).
Malheureusement le projet GNU avait fait le choix d'une conception de noyau qui s'est révélée plus difficile à mettre en œuvre que prévu. Le retard qui s'ensuivit, empêcha la Free Software Foundation de sortir le premier système d'exploitation libre. La dernière pièce a, finalement, été mise en place par Linus Torvalds, un étudiant en informatique finlandais qui, avec l'aide de volontaires du monde entier, avait compilé un noyau libre de conception plus classique. Il le nomma Linux, lequel, une fois combiné aux programmes GNU existants, donna un système d'exploitation entièrement libre. Pour la première fois vous pouviez allumer votre ordinateur et travailler sans utiliser un seul logiciel propriétaire. [5]
La plupart des logiciels de ce nouveau système d'exploitation n'étaient pas produits par le projet GNU. En fait, GNU n'était même pas le seul groupe travaillant à l'élaboration d'un système d'exploitation libre (par exemple, le code qui deviendra NetBSD et FreeBSD était déjà en développement à cette époque). Mais l'importance de la Free Software Foundation n'était pas seulement dans le code écrit par ses membres, mais aussi dans leur discours politique. En mettant en avant le logiciel libre comme une cause à part entière, plutôt qu'une commodité, ils lui ont donné une dimension politique difficile à ignorer par les programmeurs. Même les gens en désaccord avec la FSF ont dû traiter de ce problème, parfois pour revendiquer une position différente. L'efficacité du message de la FSF tient au fait qu'il est lié au code grâce à la GPL et d'autres textes. Alors que le code se répand partout, le message se diffuse également.
Bien que la scène naissante du logiciel libre ait été très dynamique, peu d'activités furent aussi clairement idéologiques que le projet GNU de Stallman. L'un des plus importants était le projet Berkeley Software Distribution (BSD),une ré-implémentation graduelle du système d'exploitation Unix (qui jusqu'à la fin des années 70 fut un projet de recherche vaguement propriétaire chez AT&T) par des programmeurs de l'Université de Californie de Berkeley. Le groupe BSD ne prit pas ouvertement position sur la nécessité des programmeurs de s'unir et de partager, mais ils mirent en pratique cette idée avec style et enthousiasme en coordonnant un gros effort de développement coopératif grâce auquel les lignes de commande des utilitaires Unix, les librairies de code et finalement le noyau du système d'exploitation lui-même furent ré-écrits entièrement, principalement par des volontaires. Le projet BSD devint un exemple important de développement non-idéologique de logiciel libre et servit également de terrain d'entraînement à de nombreux développeurs qui continueront par la suite à être actifs dans le monde de l'Open Source.
Another crucible of cooperative development was the X Window System, a free, network-transparent graphical computing environment, developed at MIT in the mid-1980's in paUn autre nid de développement coopératif fut le système X Window, un environnement graphique, libre et transparent au réseau, développé au MIT au milieu des années 80 en partenariat avec des vendeurs de matériel ayant un intérêt commun à pouvoir proposer à leurs clients un système graphique. Loin de s'opposer aux logiciels propriétaires, la licence X permettait délibérément l'ajout d'extensions propriétaires au cœur libre du système, chaque membre du consortium souhaitant pouvoir améliorer la distribution X de base et, par ce moyen, obtenir un avantage concurrentiel sur les autres. X Windows[6]en lui même était un logiciel libre, mais essentiellement par volonté de placer les concurrents sur un même pied d'égalité, et non pas comme un désir quelconque de mettre un terme à l'hégémonie des logiciels propriétaires. Devançant le projet GNU de quelques années, TeX, le système libre de traitement de texte de Donald Knuth permettant la création de documents de grande qualité, en est un autre exemple. Il fut publié sous une licence permettant à quiconque de modifier et de distribuer le code mais qui interdisait de nommer le résultat « TeX » s'il n'avait pas passé une série de tests de compatibilité stricts ( c'est là un exemple de licence libre de « protection de marque déposée » que nous approfondirons dans le Chapitre 9, Licenses, Copyrights, and Patents). Knuth n'exprimait aucun avis, d'une façon ou d'une autre, sur la question de l'opposition des logiciels libres aux logiciels propriétaires : il cherchait simplement un meilleur traitement de texte pour achever son véritable but, un livre sur la programmation informatique, et ne voyait aucune raison de ne pas offrir son système au monde une fois celui-ci prêt.
Sans faire une liste de tous les projets et de toutes les licences, on peut dire qu'à la fin des années 80, il existait de nombreux logiciels disponibles sous une grande variété de licences. La diversité des licences reflétait une diversité équivalente des motivations. Même certains des programmeurs choisissant la GNU GPL n'étaient pas aussi déterminés idéologiquement que le projet GNU lui-même. Et s'ils appréciaient de travailler sur des logiciels libres, de nombreux développeurs ne considéraient pas les logiciels propriétaires comme un mal social. Quelques personnes ressentaient un besoin moral de débarrasser le monde des « logiciels panneaux d'affichage » (appellation de Stallman pour les logiciels propriétaires), mais d'autres étaient plutôt motivées par l'émulation technique ou le plaisir de travailler avec des collaborateurs partageant leurs idées, voire même, par le simple désir humain de gloire. Pourtant généralement, ces diverses motivations n'interagissaient pas de manière destructive. C'est en parti dû au fait que les logiciels, contrairement à d'autres œuvres créatives comme la prose ou les arts visuels, doivent réussir des tests semi-objectifs pour être considérés comme des succès : ils doivent fonctionner et ne pas trop comporter de bogues. Cela donne aux participants du projet une base commune, une raison et un cadre pour travailler ensemble sans trop se préoccuper des qualifications autres que techniques.
Les développeurs avaient une autre raison de rester unis : il s'est avéré que le code produit par le monde des logiciels libres était de très bonne qualité. Dans certains cas, ils étaient notablement techniquement supérieurs à leur équivalent non-libre le plus proche, dans d'autres cas ils étaient au moins comparables, et bien sûr, toujours meilleur marché. Alors que seulement quelques personnes auraient pu être motivées pour produire des logiciels libres sur des bases strictement philosophiques, bien plus l'étaient du fait des meilleurs résultats obtenus. De plus, il y avait toujours, parmi les utilisateurs, un certain pourcentage prêt à faire don de leur temps et de leurs compétences afin d'aider à entretenir et améliorer le logiciel.
Cette tendance à produire du bon code n'était certainement pas universelle, mais cela se produisait à une fréquence croissante dans les projets de logiciels libres du monde entier. Les entreprises tributaires de logiciels commencèrent progressivement à le remarquer. Beaucoup d'entre elles découvrirent qu'elles utilisaient déjà, sans le savoir, des logiciels libres pour leurs opérations quotidiennes (les dirigeants ne sont pas toujours au courant des choix de leur service informatique). Les sociétés entreprirent de s'impliquer davantage dans les projets de logiciels libres en mettant à disposition du temps et des équipements, voire même en finançant le développement. De tels investissements pouvaient, dans les meilleurs scénarii, se montrer très lucratifs par un coefficient de retour conséquent. Le commanditaire ne paie qu'un nombre réduit de programmeurs experts pour se consacrer à plein temps au projet, mais récolte les fruits de la collaboration de chacun, y compris du travail des bénévoles et des développeurs payés par d'autres sociétés.
Alors que le monde de l'entreprise prêtait de plus en plus attention aux logiciels libres, les programmeurs se trouvèrent confrontés à de nouveaux problèmes de représentation. L'un d'entre eux était le mot « free » lui-même. Entendant pour la première fois « free software », nombre de personne pensait, à tort, que cela signifiait « logiciel gratuit ». S'il est vrai que tous les logiciels libres ne coûtent rien,[7], tous les logiciels gratuits ne sont pas libres. Par exemple, durant la bataille des navigateurs dans les années 90 et dans la course aux parts de marché qu'ils se livraient, Netscape et Microsoft offraient leurs navigateurs Web gratuitement. Aucun des deux n'était libre dans le sens des « logiciels libres ». Vous ne pouviez pas obtenir le code source et, même si vous y parveniez, vous n'aviez pas le droit de le modifier ni de le redistribuer [8] Vous pouviez tout juste télécharger un exécutable et le lancer. Les navigateurs n'étaient pas plus libres que les logiciels sous film plastique achetés en magasin : tout au plus étaient-ils diffusés à prix inférieur.
La confusion sur le mot « free » est entièrement due à l'ambivalence malheureuse du terme en anglais. La plupart des autres langues font une distinction entre la notion de prix et de liberté (la différence entre gratuit et libre est évidente pour ceux parlant une langue romane par exemple). Mais l'anglais étant de facto la langue d'échange sur Internet, le problème spécifique à cette langue concerne, à un certain degré, tout le monde. L'incompréhension liée au mot « free » était telle que les programmeurs de logiciels libres ont fini par créer une formule en réponse : « C'est free (libre) comme dans freedom (liberté), pensez à free speech (liberté de parole), pas à free beer (bière gratuite) ». Reste que devoir l'expliquer sans cesse est fatigant. De nombreux programmeurs ressentaient, à juste titre, que l'ambiguïté du mot « free » rendait plus difficile la compréhension par le public de ce type de logiciels.
Cependant, le problème apparaissait plus profond que cela. Le mot « libre » était vecteur d'une connotation morale indéniable : si la liberté était une fin en soi, peu importait que les logiciels libres soient également meilleurs ou plus profitables à certaines sociétés dans certaines circonstances. Ce n'étaient là que les effets secondaires bienvenus d'une motivation qui, au fond, n'était ni technique ni commerciale mais morale. En outre, l'idée « Libre comme dans liberté » imposait une flagrante contradiction aux sociétés souhaitant soutenir certains logiciels libres dans un domaine particulier de leurs activités, mais voulant continuer à commercialiser des logiciels propriétaires dans d'autres branches.
Ces dilemmes touchèrent une communauté déjà promise à une crise d'identité. Les programmeurs qui écrivent des logiciels libres n'ont jamais réussi à se mettre d'accord sur le but final, s'il existe, du mouvement des logiciels libres. Même dire que les opinions vont d'un extrême à l'autre serait trompeur, car cela implique une vision linéaire au lieu de la dispersion multidimensionnelle existante. Cependant, on peut définir deux grands courants de pensée, si vous acceptez de passer outre les détails pour le moment. L'un des groupes partage la pensée de Stallman que la liberté de partager et modifier est la plus importante, et qu'en conséquence, si vous cessez de parler de liberté, vous abandonnez l'idée principale. Pour d'autres, c'est le logiciel qui compte et ils ne se voient pas dire que les logiciels propriétaires sont par définition mauvais. Certains programmeurs de logiciels libres, mais pas tous, pensent que l'auteur (ou l'employeur dans le cas de travail rémunéré) devrait avoir le droit de contrôler les termes de la distribution et qu'aucun jugement moral ne devrait été rattaché au choix de termes particuliers.
Pendant longtemps personne n'a vraiment eu à prêter attention à ces différences ou à leurs interférences, mais le succès grandissant des logiciels libres dans le monde de l'entreprise a rendu cette question inévitable. En 1998, le terme Open Source a été inventé, en tant qu'alternative à « libre », par une coalition de programmeurs devenue par la suite The Open Source Initiative (OSI).[9]. Pour l'OSI non seulement le terme « logiciel libre » était déroutant, mais le mot « libre » n'était qu'un symptôme d'un problème plus général : le mouvement avait besoin d'une stratégie de commercialisation pour s'adapter au monde de l'entreprise, et les discours sur les avantages moraux et sociaux du partage ne pénètreraient pas les conseils des sociétés. Selon eux :
L'Open Source Initiative est un programme de commercialisation des logiciels libres. C'est un argumentaire en faveur des « logiciels libres » qui s'appuie sur une solide base pragmatique plutôt que sur une idéologie dévote. La substance gagnante n'a pas changé, l'attitude et le symbolisme perdants, eux, ont changés. ...
Le point qui doit être exposé à la plupart des techniciens n'est pas le concept de l'Open Source, mais le nom. Pourquoi ne pas l'appeler, comme nous l'avons toujours fait, logiciel libre ?
Une raison simple est que le terme « logiciel libre » peut facilement prêter à confusion et mener au conflit. ...
Mais la vraie motivation de ce changement de nom est économique. Nous essayons maintenant de vendre notre concept au monde de l'entreprise. Nous avons un produit compétitif, mais notre positionnement, dans le passé, était très mauvais. Le terme « logiciel libre » n'a pas été compris correctement par les hommes d'affaires qui ont pris le désir de partage pour de l'anti-capitalisme, ou pire encore, pour du vol.
Les décideurs des principales grandes entreprises n'achèteront jamais un « logiciel libre ». Mais si nous prenons les mêmes idées, les mêmes licences de logiciel libre et que l'on remplace le nom par « Open Source » ? Alors ils achèteront. Certains hackers ont du mal à y croire, mais c'est parce que ce sont des techniciens qui pensent aux choses concrètes, palpables et qui ne comprennent pas l'importance de l'image quand vous vendez quelque chose.
Dans le monde des affaires, l'apparence est une réalité. L'apparence que nous voulons abattre les barricades et travailler avec le monde des affaires compte au moins autant que la réalité de notre comportement, nos convictions et nos logiciels.
(Tiré et traduit de http://www.opensource.org/advocacy/faq.php et http://www.opensource.org/advocacy/case_for_hackers.php#marketing)
La pointe de l'iceberg de la polémique apparaît dans ce texte. Il mentionne « nos convictions » mais évite intelligemment de citer précisément quelles sont ces convictions. Pour certains, ça peut être la conviction que le code développé selon un processus ouvert sera meilleur, pour d'autres ça peut-être la conviction que toutes les informations devraient être partagées. L'usage du mot « vol » fait (sûrement) référence à la copie illégale, dont beaucoup se défendent : ce n'est pas un vol si personne n'est dépossédé de son bien. On retrouve aussi le raccourci facile, mais injuste, entre logiciels libres et anti-capitalisme, sans débattre du bien fondé de cette accusation.
Rien de tout cela ne signifie que le site de l'OSI est incomplet ou trompeur. Il ne l'est pas. Au contraire, c'est la vitrine de ce qui manquait au mouvement du logiciel libre d'après l'OSI : une bonne stratégie commerciale où « bon » veut dire : « viable dans le monde des affaires ». L'Open Source Initiative a offert à beaucoup de gens exactement ce qu'ils cherchaient : un vocabulaire pour parler des logiciels libres avec un plan de développement et une stratégie commerciale, plutôt qu'une croisade idéologique.
L'apparition de l'Open Source Initiative a transformé l'horizon des logiciels libres. Elle a reconnu une dichotomie longtemps inavouée et, par là même, a forcé le mouvement à reconnaître qu'il avait autant une politique interne qu'externe. On voit aujourd'hui que les deux groupes ont dû trouver un terrain d'entente puisque la plupart des projets font participer des programmeurs des deux camps aussi bien que d'autres n'entrant pas clairement dans l'une ou l'autre des catégories. Cela ne veut pas dire que les gens ne parlent jamais de motivations idéologiques, on fait parfois référence aux manquements à la « morale de hacker » traditionnelle par exemple. Mais il est rare de voir un développeur de l'un deux mondes douter ouvertement des motivations profondes de ses collègues. La contribution transcende le participant. Si quelqu'un produit du bon code, personne ne lui demande s'il le fait pour des raisons morales, ou parce que son employeur le paie pour cela, ou parce qu'il étoffe son Curriculum Vitae ou quoique ce soit d'autre. L'évaluation et les critiques de la contribution se font sur des critères techniques. Même des organisations ouvertement politiques comme le projet Debian dont le but est d'offrir un environnement 100% libre (c'est-à-dire « libre comme dans liberté ») sont plutôt ouvertes à l'intégration de code non-libre et à la coopération avec des programmeurs qui ne partagent pas exactement les mêmes buts.
[2] SourceForge.net, un site d'hébergement populaire. Il contenait 79 225 projets enregistrés à la mi-avril 2004. On est bien sûr très loin de la quantité totale de projets de logiciels libres sur Internet: c'est juste le nombre ayant choisi d'utiliser SourceForge.
[3] Stallman utilise le mot « hacker » pour désigner « une personne qui aime programmer et qui adore faire le malin avec ça » mais pas « quelqu'un qui s'introduit dans les ordinateurs » comme le voudrait le nouveau sens.
[4] GNU est l'acronyme de « GNU is Not Unix » et « GNU » dans cette extension signifie... la même chose.
[5] Techniquement, Linux n'était pas le premier. Un système d'exploitation libre pour les ordinateurs compatibles IBM, appelé 386BSD, est sorti peu avant Linux. Cependant, il était bien plus compliqué de faire marcher 386BSD. Linux a créé des remous non seulement parce qu'il était libre mais aussi parce qu'il avait vraiment une bonne chance de faire marcher l'ordinateur sur lequel vous l'aviez installé.
[6] Ils préfèrent qu'il soit appelé le « Système X Window », mais en pratique on l'appelle « X Window » parce que les trois mots sont trop encombrants.
[7] On peut faire payer quelque chose en échange de copies d'un logiciel libre, mais comme on ne peut pas empêcher l'acheteur de le redistribuer gratuitement, le prix tend immédiatement vers zéro.
[8] Finalement le code source de Netscape Navigator a été publié sous une licence libre, en 1998, et deviendra la base du navigateur Web Mozilla. Voir sur http://www.mozilla.org/.
[9] La page Web de l'OSI est : http://www.opensource.org/.