IntroductionLa 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
totalSourceForge.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.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 )
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 , 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).HistoriqueLe 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.L'avènement des logiciels propriétaires et des logiciels
libresÀ 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.Résistance conscienteAlors 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
»,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.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.
(tiré de )
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 GNUGNU est l'acronyme de « GNU is Not Unix »
et « GNU » dans cette extension signifie... la même
chose.é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 .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. 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é.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.Résistance accidentelleBien 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 WindowsIls 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.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 ). 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.« Libre » contre « Open Source »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,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., 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
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 . 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).La page
Web de l'OSI est : .. 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
et )
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.La situation actuelleQuand vous dirigez un projet de logiciel libre, vous n'aurez pas
besoin de discuter de lourds problèmes philosophiques tous les jours.
Les programmeurs n'auront pas à cœur de rallier tous les participants du
projet à leurs idées sur tous les sujets (ceux qui insistent là dessus
se retrouvent rapidement incapables de travailler sur un projet). Mais
vous devez savoir que la question « libre » contre « Open Source »
existe, au moins pour éviter de dire des choses inamicales à certains
des participants, mais aussi parce que comprendre les motivations des
développeurs est la meilleure manière, la seule
manière en un certain sens, de diriger un projet.Le logiciel libre est une culture par choix. Pour y naviguer avec
succès, vous devez comprendre pourquoi les gens ont fait le choix d'y
participer en premier lieu. Les manières coercitives ne fonctionnent
pas. Si les gens ne sont pas heureux au cœur d'un projet, ils vont
simplement s'en écarter pour en rejoindre un autre. Le logiciel libre
est remarquable, même au sein des communautés de volontaires, par la
légèreté de l'investissement. La plupart des gens engagés n'ont jamais
vraiment rencontrés d'autres participants face à face, et donnent
simplement un peu de leur temps quand ils en ressentent l'envie. Les
moyens usuels, par lesquels les humains établissent des liens entre eux
et forment des groupes qui durent, sont restreints à leur plus simple
expression : des mots écrits transmis par des fils électriques. À cause
de cela, la formation d'un groupe soudé et dévoué peut prendre du temps.
Inversement, un projet peut facilement perdre un volontaire potentiel
dans les cinq premières minutes de présentation. Si un projet ne fait
pas bonne impression, les nouveaux venus lui donnent rarement une
seconde chance.La brièveté, ou plutôt la brièveté
potentielle, des relations est
peut-être l'obstacle le plus intimidant au commencement d'un nouveau
projet. Qu'est ce qui persuadera tous ces gens de rester groupés
suffisamment longtemps pour produire quelque chose d'utile ? La réponse
à cette question est suffisamment complexe pour être le sujet du reste
de ce livre, mais si elle devait être exprimée en une seule phrase, ce
serait :
Les gens doivent sentir que leur relation à un
projet, et leur influence sur celui-ci, est directement
proportionnelle à leurs contributions.
Aucune catégorie de développeurs, ou de développeurs potentiels,
ne devrait se sentir mise à l'écart ou être discriminée pour des raisons
non-techniques. Les projets portés par une société et/ou des
développeurs salariés doivent y faire particulièrement attention, le
aborde ce sujet plus en détail. Bien sûr, cela ne
veut pas dire que, si vous ne bénéficiez pas du financement d'une
société, vous n'avez à vous soucier de rien. L'argent n'est que l'un des
nombreux facteurs pouvant influencer le succès d'un projet. Il y a aussi
les questions de choix du langage, de la licence, du processus de
développement, du type précis d'infrastructure à mettre en place, de la
manière de rendre public la base du projet de manière efficace et bien
plus encore. Commencer un projet du bon pied est le sujet du prochain chapitre.