Le développement des logiciels libres

Un projet de logiciel libre peut inclure n'importe lequel des éléments décrits ci-dessus, et pour être honnête, c'est le cas de quelques uns d'entre eux. Les versions commerciales de BSD, Bind et Sendmail sont des exemples d'un processus de développement logiciel standard, mais ils n'ont pas débuté de cette façon. Un véritable processus de développement logiciel nécessite énormément de ressources, et en lancer un représente, en général, un investissement que seul un retour peut justifier.

Le cas, de loin le plus fréquent, de développement d'un logiciel libre est celui où les gens concernés se régalent dans ce qu'ils font et veulent que leur travail soit aussi utile que possible. Et, pour ce faire, ils le diffusent sans rétribution et quelquefois sans restrictions sur sa distribution. Ces gars-là peuvent ne pas avoir accès à ce que l'on appelle des outils de « qualité commerciale » (tels que des analyseurs de code, des vérificateurs de limites et des contrôleurs de l'intégrité mémoire). Ils paraissent trouver la programmation, la réalisation de paquetage, et le prosélytisme particulièrement amusants, et pas l'AQ (Assurance Qualité), les DSL (Dossier de Spécification du Logiciel) et ils ne sont pas habituellement des champions des délais de réalisation courts.

Reprenons chacune des étapes du processus de développement d'un logiciel et voyons comment elles s'articulent dans un projet de logiciel libre, non financé, d'un travail de passionné.

Expression des besoins

Les développeurs de logiciel libre ont tendance à réaliser les outils dont ils ont besoin ou dont ils ont envie. Il arrive quelquefois que cela coïncide avec ce qu'ils font au travail et souvent ce sont ceux dont la tâche première est l'administration plutôt que le développement de logiciel. Si, après plusieurs versions, un système logiciel atteint la masse critique et devient autonome, il sera distribué sous forme de fichier archive via l'Internet et les utilisateurs pourront commencer, soit à demander l'ajout de fonctionnalités, soit à se mettre à en ajouter et à en faire profiter la communauté.

La constitution d'un « DSLL » (Dossier de Spécification d'un logiciel libre) s'effectue généralement grâce à une liste de diffusion ou à un groupe de discussion où utilisateurs et développeurs discutent directement. Le consensus se fait sur ce que les développeurs ont retenu de la discussion ou sur ce avec quoi ils sont d'accord. Si un consensus suffisant ne peut être obtenu, il va en résulter un « embranchement dans le code » où d'autres développeurs se mettront à diffuser leurs propres versions. L'équivalent du DSL dans le cas du logiciel libre peut être très enrichissant mais peut créer des conflits aigus dont la résolution n'est pas possible (ou pas tentée).

Conception préliminaire, au niveau système

Il n'y a pas, en général, d'étape de conception préliminaire dans un projet de développement d'un logiciel libre non financé. Cette étape est soit implicite, jaillissant toute entière et d'un seul coup de la cuisse de Jupiter, soit elle évolue avec le temps (comme le logiciel lui-même). Habituellement, avec les versions 2 ou 3 d'un logiciel libre, on voit apparaître une réelle architecture du système, même si celle-ci n'a pas été formalisée quelque part.

C'est ici, plutôt que n'importe où ailleurs que, par rapport aux règles normales du développement des logiciels, les logiciels libres ont gagné leur réputation d'être quelque peu farfelus. On peut compenser une absence de DSL ou même de démarche d'assurance qualité en ayant de très bons programmeurs (ou des utilisateurs particulièrement amicaux), mais, s'il n'y a pas eu de conception au niveau du système (même si c'est seulement dans la tête de quelqu'un), la qualité du projet résultant sera limitée.

Conception détaillée

Le DCD (Dossier de Conception Détaillée) constitue une autre victime de l'absence de rétribution et de la volonté de se faire plaisir des gens qui développent des logiciels libres. Certains aiment travailler sur un DCD mais, en général, prennent tout leur plaisir lorsqu'ils le font dans leur travail journalier. La conception détaillée devient un effet de bord du développement : « Je sais que j'ai besoin d'un analyseur, donc, je vais en écrire un ». La documentation des interfaces de programmation des applications (API) sous la forme de symboles externes, dans des fichiers d'en-tête ou dans des pages de man est optionnelle et peut devenir inexistante si cette interface n'est pas destinée à être publiée ou utilisée en dehors du projet.

C'est vraiment regrettable car cela rend inaccessible pas mal de très bons codes qui, autrement, pourraient être réutilisables. Même les modules qui ne sont pas réutilisables ou étroitement liés au projet pour lequel ils ont été créés, et dont les interfaces de programmation ne font pas partie des éléments à délivrer, devraient vraiment avoir des pages de man pour expliquer ce qu'ils font et comment les appeler. C'est extrêmement utile pour ceux qui veulent améliorer le code, puisqu'ils doivent commencer par le lire et le comprendre.

Implémentation

C'est la partie amusante. L'implémentation est la partie que les programmeurs préfèrent ; c'est ce qui les fait veiller alors qu'ils devraient dormir. L'occasion d'écrire du code constitue la motivation première de pratiquement tous les efforts de développement de logiciel libre qui ont eu lieu. Si l'on se concentre sur cet aspect du développement logiciel à l'exclusion des autres, il apporte une très grande liberté d'expression.

C'est dans le développement de logiciels libres que la plupart des programmeurs expérimentent de nouveaux styles, que ce soit un style d'indentation, une manière de donner un nom aux variables ou « un essai d'économie d'utilisation de la mémoire » ou « un essai d'économie de cycles CPU » ou ce que vous voulez. Et il y a quelques extraits d'une grande beauté qui attendent dans des archives un peu partout, où un programmeur a essayé avec succès un nouveau style.

Un effort pour un logiciel libre non financé peut avoir autant de rigueur et de qualité qu'on le veut. Les utilisateurs exploitent le code s'il est fonctionnel et la plupart des gens ne font pas attention au fait que le développeur a changé de style trois fois pendant la phase de réalisation. Les développeurs y font en général attention, ou apprennent à le faire après un certain temps. Devant une telle situation, les commentaires de Larry Wall, selon qui la programmation est un art, prennent toute leur signification.

La principale différence dans une réalisation de logiciel libre non financé vient de ce que la revue du code est informelle. Il n'y a généralement pas de supérieur ou de pair pour regarder le code avant qu'il ne soit diffusé. Il n'y a habituellement pas de test unitaire, de non-régression ou quoi que ce soit d'autre.

Intégration

L'intégration, dans un projet logiciel libre, consiste habituellement à écrire quelques pages de man, à s'assurer que le logiciel se construit sur tous les systèmes auxquels le développeur a accès, à nettoyer le fichier « Makefile » pour le débarrasser de toutes les commandes superflues qui se sont accumulées pendant la phase d'implémentation, à écrire un LISEZMOI, à faire une archive, à la télécharger sur un site ftp anonyme quelque part et à poster une annonce dans la liste de diffusion ou le forum de discussion des utilisateurs concernés.

Notons que le groupe de discussion comp.sources.unix a été ranimé en 1998 par Rob Braun et qu'il constitue l'endroit idéal pour poster des annonces concernant de nouveaux paquetages de logiciels libres ou des mises à jour de logiciels existants. Il fonctionne également comme archive de dépôt.

Il n'y a pas, habituellement, de plan de test au niveau du système et pas de tests unitaires. En fait, pour ce qui est des logiciels libres, les efforts consentis pour les tests en général sont très limités (des exceptions existent, telles que Perl et PostgreSQL). Cependant, comme nous allons le voir, ce manque des tests avant diffusion n'est pas une faiblesse.

Tests in situ

Le logiciel libre non financé bénéficie des meilleurs tests au niveau système, sauf si nous y incluons les tests de la NASA sur les robots destinés à aller dans l'espace. Cela vient simplement du fait que les utilisateurs ont tendance à être beaucoup plus amicaux lorsqu'ils n'ont rien à payer, et les utilisateurs faisant autorité (souvent eux-mêmes développeurs) sont souvent plus serviables lorsqu'ils peuvent lire et corriger le code source de quelque chose qu'ils emploient.

Le manque de rigueur constitue l'essence des tests de terrain. Le génie logiciel impose aux utilisateurs qui réalisent les tests d'essayer des cas d'utilisation intrinsèquement imprévisibles au moment où le système a été conçu et réalisé ; en d'autres termes, des expériences réelles d'utilisateurs réels. Les projets de logiciels libres non financés sont proprement imbattables dans ce domaine.

La « revue des pairs » de dizaines ou de centaines d'autres programmeurs traquant les bogues en lisant le code source plutôt qu'en utilisant simplement des paquetages exécutables constitue un autre avantage dont profitent les projets de logiciels libres. Quelques uns des lecteurs rechercheront les failles de sécurité et certaines de celles qui seront découvertes ne seront pas signalées (en dehors du cercle des pirates), mais ce risque est faible par rapport à l'avantage de voir un nombre incalculable d'étrangers lire le code source. Ces étrangers peuvent réellement faire travailler le développeur plus tard le soir qu'aucun patron ou aucun chef ne pourrait ou ne voudrait l'imposer.

Maintenance et assistance

« Oh là là, désolé », voilà ce que l'on répond habituellement à un utilisateur qui découvre un bogue, ou, « Oh là là, désolé, et merci ! » si celui-ci ajoute la correction du bogue. Les développeurs de logiciels libres font le tri des bogues à la réception des messages « Hé, ça marche chez moi ». Cela vous paraît chaotique, ça l'est. Le manque d'assistance peut empêcher certains utilisateurs de vouloir (ou de pouvoir) utiliser les programmes issus du monde des logiciels libres non financés, mais cela peut également créer des occasions pour des cabinets de conseil ou des distributeurs de logiciels de vendre des contrats d'assistance et/ou de vente de versions améliorées et/ou de vente de versions commerciales.

Lorsque la communauté des éditeurs d'Unix s'est trouvée confrontée à la demande pressante, de la part de ses utilisateurs, de fournir des logiciels libres pré-intégrés dans leurs systèmes de base, leur première réaction a été de dire « Eh bien, d'accord, mais nous n'en assurerons pas l'assistance ». Le succès d'entreprises comme Cygnus™ a été dû à son ré-examen rapide de cette position, mais le fossé entre les cultures est vraiment très profond. Les éditeurs de logiciels traditionnels, y compris les éditeurs d'Unix, ne peuvent tout simplement pas planifier la fourniture de contrats d'assistance si de nombreuses personnes inconnues modifient librement les logiciels.

Quelquefois, la réponse consiste à reprendre le logiciel en interne, en le faisant entrer dans le cycle normal de l'assurance qualité avec les tests unitaires et les tests au niveau du système, l'analyse de couverture du code et tout le reste. Cela peut entraîner une ingénierie inverse du DSL et du DCD pour fournir une référence à l'assurance qualité (i.e., quelles fonctionnalités doivent être testées). D'autres fois, la réponse consiste à réécrire les termes du contrat d'assistance en remplaçant « résultats garantis » par « meilleurs efforts ». Finalement, le marché de l'assistance sera occupé par ceux qui pourront fédérer tous cette foule d'étrangers, dans la mesure ou parmi eux il y a des gens bien, nombreux, qui écrivent du logiciel de qualité, et que la « culture logiciel libre » est, dans de nombreux cas, la plus efficace pour fournir le niveau de fonctionnalité que les utilisateurs désirent réellement (comme en témoigne Linux par rapport à MS-Windows).