Page suivante Page précédente Table des matières

6. Les vertus du modèle de développement coopératif

Les logiciels libres sont élaborés selon un modèle de développement coopératif (ou communautaire) dont l'Internet constitue le support. En supprimant toute notion de distance, le réseau des réseaux constitue le vecteur idéal dans l'échange d'information à l'échelle de la planète. L'Internet a ainsi joué un rôle déterminant dans le succès des OSS.

Il est à première vue difficile d'imaginer qu'un modèle fondé sur l'utilisation du réseau comme moyen de communication entre développeurs puisse produire des logiciels de la qualité de GNU/Linux. Eric S. Raymond — autre grande figure du logiciel libre — a longuement décrit ce mode de développement dans un article intitulé la cathédrale et le bazar. La cathédrale y apparaît comme une métaphore des grandes entreprises où le développement des programmes est régi par les règles strictes du génie logiciel et du secret de fabrication. L'auteur l'oppose au bazar, illustrant ainsi l'apparent désordre qui règne sur l'Internet — support du modèle de développement communautaire.

6.1 Éclosion d'un projet libre

Nous avons précédemment fait allusion au fait que le développement de logiciels libres n'est pas une activité philanthropique. Tout projet libre viable est initié sur la base d'un besoin réel qu'a son créateur : « Tout bon logiciel commence par gratter un développeur là où ça le démange ». Les appels à collaboration qui visent à créer une équipe de développement autour d'une simple idée aboutissent rarement. Le développeur doit initialement fournir de quoi susciter l'intérêt du reste de la communauté. Il se positionnera alors naturellement en responsable de projet — assurant à la fois le (co-)développement et les activités périphériques.

6.2 Logiciels libres et génie logiciel

L'académie (imaginaire) du génie logiciel nous enseigne que le développement d'un programme complexe s'effectue selon un cycle parfaitement défini et maîtrisé — le processus étant supervisé dans le respect des préceptes de l'assurance qualité. Les théoriciens de la gestion de projet et du génie logiciel ont doté les équipes de développeurs d'outils sophistiqués dédiés au calcul des charges et des délais, à la planification des tâches ou à la validation du code source. Ils soulignent l'importance des documents associés à chaque phase du développement et insistent sur la notion de traçabilité. Que deviennent ces préceptes dans l'univers des OSS ?

Considérée comme un Art, la programmation (le codage, en jargon informatique) constitue l'essentiel de l'activité du développeur de logiciels libres. Le hacker est un être sensible aux charmes de la technologie et à l'esthétique des implémentations. Le code est l'expression des compétences et de la personnalité du développeur passionné. C'est à travers lui qu'il obtient la reconnaissance de ses pairs, qu'il « se fait un nom » sur l'Internet. Loin d'être négligeable, cette quête d'identité constitue une réelle source de motivation chez les développeurs et explique en partie pourquoi ces bénévoles sont prêts à mettre leurs compétences au service de la communauté.

Dans l'élaboration d'un logiciel libre, les phases amont du cycle de développement — conception préliminaire et détaillée — se réduisent souvent au strict minimum et ne sont que rarement documentées. L'accent est mis sur l'implémentation et l'architecture se dessine au fil des versions du logiciel. Dans l'univers du logiciel libre, on n'hésite pas à réécrire tout ou partie d'un code source jugé inadéquat. Au final, ce processus itératif — bien que pénalisant pour ce qui est des délais — engendre un codé épuré, performant et stable.

Notons que l'absence de pression financière permet également de prendre quelques distances avec les méthodes conventionnelles du génie logiciel. Le coût des erreurs de conception (ou de codage) s'exprime avant tout en terme de « retard ».

Les distributions libres contiennent principalement le code source des programmes et les indispensables fichiers README qui les rendent exploitables. Toutefois, les détails de conception peuvent être obtenus sur simple demande auprès de « l'équipe de développement » — des contributeurs.

Si l'approche académique — adoptée par les cathédrales — est la seule voie possible vers la qualité, comment expliquer le niveau de stabilité général des OSS ? Le bazar suivrait-il les lois de la physique en démontrant qu'il existe un ordre dans le chaos ? Si on se réfère aux propos des utilisateurs de logiciels libres, il semble que ce soit le cas.

La démarche des développeurs de l'Internet rompt une fois de plus avec l'ordre établi et les détracteurs de l'Open Source trouvent ici de quoi alimenter leur scepticisme.

6.3 Des utilisateurs actifs

Les utilisateurs jouent un rôle déterminant dans le processus de développement des OSS. L'exploitation dynamique d'une application, qui consiste à proposer de nouvelles fonctionnalités ou à identifier les bogues, constitue une forme de contribution non négligeable à l'élaboration des programmes. On parle d'utilisateurs actifs. La rédaction de documentation est une autre voie de contribution couramment empruntée. Dans le registre des relations avec les utilisateurs, Eric S. Raymond prodigue aux développeurs les conseils suivants :

Traiter les utilisateurs comme des co-développeurs est le chemin le moins semé d'embûches vers une amélioration rapide du code et un débogage efficace.

Si vous traitez vos bêta-testeurs comme ce que vous avez de plus cher au monde, ils réagiront en devenant effectivement ce que vous avez de plus cher au monde.

Il est presque aussi important de savoir reconnaître les bonnes idées de vos utilisateurs que d'avoir de bonnes idées vous-même. C'est même parfois préférable.

Distribuez tôt. Mettez à jour souvent. Et soyez à l'écoute de vos clients.

Étant donné un ensemble de bêta-testeurs et de co-développeurs suffisamment grand, chaque problème sera rapidement isolé, et sa solution semblera évidente à quelqu'un (loi de Linus).

6.4 Réactivité de la communauté

L'ouverture du code confère un privilège aux utilisateurs de logiciels libres : celui de bénéficier rapidement des mises à jour corrigeant les bogues résiduels et les éventuelles failles de sécurité.

La découverte de la faille de sécurité réseau TearDrop fut l'occasion d'évaluer le temps de réponse de la communauté de l'Internet. Ce défaut affectait la couche IP des systèmes MS-Windows (95 et NT) et la famille des Unix — dont Linux. Les utilisateurs de GNU/Linux et des autres systèmes libres ont obtenu le patch correctif dans les jours qui suivirent la découverte du bogue. Cet exemple tend à démontrer la validité de la loi de Linus.

La réactivité du modèle de développement coopératif est bien supérieure à celle du modèle propriétaire.

6.5 Sécurité des systèmes

L'exemple précédent illustre un autre intérêt du modèle coopératif : la sécurité. Le contrôle du contenu des logiciels à l'échelle planétaire tente de prévenir toute introduction volontaire d'un code dont la fonction serait de créer un accès clandestin aux systèmes — un cheval de Troie. La communauté veille !

Avec le développement de l'Internet, la sécurité des réseaux devient un enjeu majeur. L'ouverture du code source des programmes assurant le transit de l'information apparaît alors comme une nécessité.

6.6 Pérennité des logiciels

Le monde des OSS dispose d'une gigantesque bibliothèque de code source d'excellente qualité. Fonctionnant en libre service (dans la mesure où l'on en respecte les licences), le code qu'elle contient est régulièrement réutilisé comme base de travail (ou comme didacticiel) et procure donc de solides fondations aux nouveaux projets. Selon Eric Raymond : « Les bons programmeurs savent quoi écrire. Les grands programmeurs savent quoi réécrire (et réutiliser) ». Le logiciel libre s'est ainsi constitué un patrimoine inestimable qui, protégé par les licences de l'Open Source, restera dans la « famille ». La licence Open Source est le garant de la pérennité du travail accompli. Ce qui est disponible aujourd'hui le sera demain.

Afin de respecter l'esprit du modèle coopératif, un développeur animé par le sentiment du devoir accompli (ou dont l'enthousiasme s'émousse) se doit de passer le relais. Souvent, un volontaire compétent, issu de la communauté des utilisateurs du logiciel devenu orphelin, se proposera de le maintenir. Et le « miracle » du logiciel libre s'accomplira de nouveau...

Force est de constater que rien ne garantit que les choses se passeront ainsi.

Constatons d'abord qu'une solution propriétaire développée par une société ayant « pignon sur rue » n'offre pas davantage de garantie. Le devoir qu'a une entreprise de suivre ses produits n'est qu'un devoir moral. Il est rare qu'elle y soit juridiquement contrainte. Ses utilisateurs devront donc subir tout retournement de sa stratégie commerciale — avec comme conséquence possible l'abandon du produit. Les solutions propriétaires n'offrent ainsi aucune garantie en terme de pérennité du produit.

Notons ensuite que l'utilisateur de logiciel libre, disposant du code source de l'application, pourra envisager : de mobiliser des ressources humaines pour maintenir le logiciel, de faire appel à une société de services, ou encore d'employer l'auteur. Pour ce qui est des solutions propriétaires, l'abandon du produit est souvent inéluctable. Les plus fortunés pourront négocier le rachat du code source, les autres devront vivre avec l'espoir que le produit trouve un repreneur.

Même si elle ne constitue pas une assurance « tous risques », la disponibilité du code est la seule source de pérennité pour un logiciel. L'utilisation rationnelle d'un logiciel libre ne représente pas une menace pour l'entreprise.

6.7 Les standards ouverts

Soucieux d'assurer un maximum de transparence à ses utilisateurs, le logiciel libre se développe sur la base de standards ouverts — tels que TCP/IP ou CORBA. Les architectures logicielles érigées sur ces standards constituent une réelle approche modulaire des systèmes. On peut alors substituer à un composant obsolète un logiciel exploitant le même type d'interface sans déstabiliser l'ensemble de l'architecture. Cette substitution peut s'effectuer indépendamment de l'origine respective des deux produits. L'utilisation des standards ouverts offre actuellement le plus haut niveau de compatibilité entre les différents produits du marché — qu'ils soient libres ou propriétaires.

À l'opposé, le choix d'une solution propriétaire contraint souvent l'utilisateur à construire l'ensemble de son système sur un standard dont le fournisseur est — par le jeu des brevets (parfois) et des licences propriétaires (souvent) — le seul à exploiter la technologie. La substitution opérée précédemment devient impossible en dehors de l'offre de ce même fournisseur. Le danger est de devoir mettre à jour la totalité des composants si l'éditeur propose désormais une solution incompatible avec la précédente — cas malheureusement assez fréquent.

Au-delà des considérations techniques, cette approche place le client dans une situation de totale dépendance qui va à l'encontre des règles de libre concurrence. Afin de conserver une marge de manoeuvre confortable, il sera toujours préférable d'opter pour une solution compatible avec les standards ouverts.

Des projets libres concurrents exploitent ainsi des technologies communes. Une éventuelle migration de l'un vers l'autre s'en trouve grandement facilitée. L'état d'esprit est tel que les développeurs iront parfois jusqu'à s'assurer de leur réelle compatibilité. C'est ainsi que les responsables des projets GNOME et KDE se sont entendus sur la manière d'exporter leurs objets. Une application KDE pourra accueillir et manipuler un objet issu d'une application GNOME et réciproquement. La rivalité s'exprime alors sur le terrain des performances et des fonctionnalités offertes à l'utilisateur. Une concurrence saine et loyale qui maintient la variété de l'offre.

6.8 La garantie

Avec la pérennité des produits, la notion de garantie est également un thème de préoccupation courant. La garantie concerne ici l'application des fonctionnalités du logiciel aux données de l'utilisateur et ses éventuelles conséquences sur leur intégrité.

Il est bien évident que l'on ne peut pas attendre d'un bénévole — le développeur de logiciel libre — qu'il engage sa responsabilité en garantissant son produit. Intolérable pour l'entreprise ?

Rappelons que les termes de la garantie de MS-Windows 95 en limitent la durée à 90 jours et qu'elle ne couvre nullement les dommages que pourrait occasionner son utilisation. Elle nous assure simplement que le logiciel devrait pour l'essentiel — c'est le terme employé — se comporter conformément aux performances décrites dans le(s) manuel(s) l'accompagnant. Nous voilà rassurés !

Nous venons — certes — de nous surprendre à participer au lynchage collectif de Microsoft. Cela illustre toutefois le fait que les éditeurs propriétaires ne s'engagent pas plus que les développeurs bénévoles en matière de garantie du produit. Quelle conclusion en tirer si ce n'est, une fois de plus, que l'utilisation d'un logiciel libre ne constitue pas un risque plus important que celle des solutions propriétaires? Les versions stables des logiciels libres sont parfaitement identifiées et leur disponibilité est largement annoncée.

Le recours aux compétences d'une société de services proposant des solutions construites sur du logiciel libre peut constituer une forme de garantie. En engageant la responsabilité de son entreprise, le prestataire « garantit » les fonctionnalités du produit.

6.9 L'assistance technique

Dans le modèle coopératif, la charge que représente l'assistance technique aux utilisateurs est répartie entre l'équipe de développeurs et les utilisateurs eux-mêmes. L'Internet sert évidemment de support à ce service. Les forums (ou groupes) de discussion sont des lieux d'échanges du savoir et de l'expérience de chacun.

La documentation « rédigée » est toutefois abondante et son internationalisation progresse rapidement. Le Linux Documentation Project concentre les principaux efforts de documentation de GNU/Linux.

Pour l'industriel, le fait qu'un logiciel libre soit un produit lié à une personne physique (et non à une personne morale) constitue une autre source de « perturbation cérébrale ». Qui représente le produit ? Qui en assure le support ? Qui est mon interlocuteur privilégié ? Où est-il ? Dois-je rechercher moi-même l'information sur l'Internet ?

Pour répondre à cette demande, de nouvelles sociétés de services jouent le rôle d'interface entre l'univers quelque peu virtuel du logiciel libre et celui des entreprises. Dans ce domaine, l'offre est croissante. Les OSS sont ainsi générateurs d'activité économique dans le domaine du service.

À propos de représentativité... Sous l'angle commercial, la notion de représentativité est associée à celle d'image de marque. « La Red Hat » — une distribution américaine de Linux — a construit son succès commercial sur ce concept. Red Hat a ainsi progressé en terme de représentativité de GNU/Linux. Ces derniers temps, la tendance est d'associer Red Hat à GNU/Linux, comme GNU/Linux est associé à l'ensemble des OSS. La variété de l'offre participe au succès du logiciel libre et l'apparition d'une situation de monopole dans la distribution de Linux serait perçue comme un échec.

6.10 Du rôle des OSS

Le modèle coopératif, tel que nous l'avons présenté, ne semble pas pouvoir répondre aux demandes marginales, à la spécificité de chacun. Les projets de masse constituent son domaine de prédilection. Il démontre tout son potentiel dans le développement et la maintenance des outils communs : systèmes, réseaux, environnements graphiques, applications de base. Ce dont tout le monde a besoin.

Est-ce réellement la vocation des développeurs de l'Internet que de développer les applications de métier ? Certes non. C'est principalement sur ce créneau que l'industrie du logiciel à un rôle à jouer. En prise directe avec les entreprises, souvent positionnées sur des marchés ciblés, les sociétés commerciales ont des arguments que le logiciel libre n'a pas.

La vocation première du logiciel libre est certainement d'agir là où la transparence est nécessaire.

6.11 Organisation macroscopique

La communauté du logiciel libre n'est pas un groupe marchant au pas d'un commandement centralisé. Nul n'a d'autorité sur l'ensemble. Elle tente avant tout de n'adopter que des choix techniques guidés par une analyse objective des propositions soumises par ses membres. Bien que moins structurée, cette organisation présente des similitudes avec l'approche retenue dans le système des RFC (Request For Comments).

Un des dangers potentiels de l'approche communautaire est de voir les projets diverger au détriment de la compatibilité — de ne pas maintenir la cohérence de l'ensemble. Dans ce registre, le projet Linux Standard Base a pour vocation de promouvoir un certain nombre de standards dans l'architecture des distributions Linux (API système). Le but est d'accroître le niveau de compatibilité entre les différentes distributions du système.

Toutefois, l'harmonisation de l'offre n'est pas une préoccupation majeure. Chaque distribution cible un certain profil d'utilisateur : de l'expert au novice, du serveur au poste client. Pour la communauté de l'Internet, la diversité de l'offre participe à la stabilité du modèle coopératif et prévient les situations de monopole. Elle constitue également un « espace d'expression » de la personnalité de chacun. L'uniformité nuit à la créativité.


Page suivante Page précédente Table des matières