Tribune Libre: Ténors de l'Informatique Libre | ||
---|---|---|
Page précédente | Chapitre 10. La stratégie commerciale fondée sur les logiciels Open Source | Page suivante |
Le projet Apache dispose d'outils de conduite partagée du développement, bien entretenus et fort efficaces.
Le plus important parmi ceux-ci est CVS ou « Concurrent Versioning System » (un « Système de gestion des révisions »). Il s'agit d'une collection de programmes maintenant un répertoire de code partagé puis assurant sa mise à jour au gré des modifications en mémorisant les dates et les noms de leurs auteurs. De nombreuses personnes agissent ainsi simultanément sur le même programme sans se gêner mutuellement. Le processus de déverminage s'en trouve aussi facilité du fait que CVS rend possible d'examiner un à un tous les changements survenus afin de trouver l'origine exacte d'un bogue donné. Le code client de CVS, disponible pour toutes les plates-formes majeures, fonctionne tout-à-fait correctement via des lignes téléphoniques et sur des connexions longues distances. SSH en assure si nécessaire la confidentialité tout en gérant les habilitations.
Le projet Apache n'utilise pas seulement CVS pour mettre à jour le code source mais aussi pour mettre à jour le fichier STATUS dans lequel nous plaçons toutes les questions importantes et les descriptions commentées et raisonnées d'innovations majeures, et même les résultats de scrutins liés à chaque question-clé. CVS enregistre aussi les bulletins de vote émis lors des prises de décisions du groupe, maintient les documents de notre site Web, gère la documentation de développement, etc. En bref, il constitue à la fois notre coffre-fort et notre livret de gestion du savoir. Sa simplicité peut effrayer (la plupart des logiciels de cette catégorie sont chers et très touffus) mais, en pratique, est l'une de ses plus grandes qualités. Tous ses composants, côté serveur comme côté client, sont libres.
Un projet aux sources libres doit offrir un solide ensemble de forums de discussion à ses développeurs et utilisateurs. Le logiciel utilisé importe peu (nous employons Majordomo, mais Ezmlm ou Smartlist ou n'importe quel équivalent rendrait autant de services). Il faut consacrer une liste à chaque sous-groupe cohérent de développeurs, de sorte qu'ils sélectionnent eux-même les thèmes traités et restent proches. Créer, de plus, une liste séparée pour chaque projet grâce à laquelle le serveur CVS diffuse des avis de changements effectués est aussi très important car cela offre aux participants le moyen d'examiner au fur et à mesure les modifications effectuées. Cette approche invite tout un chacun à respecter les standards de codage et facilite la recherche des bogues. Mieux vaut séparer les listes des utilisateurs de celles des développeurs, et peut-être même, si le nombre de participants augmente, le noyau des développeurs activistes des autres. Préserver les archives des listes disponibles publiquement afin de laisser les utilisateurs y chercher des réponses à leurs questions.
Un projet bien mené comprend aussi un outil de suivi des bogues et des versions. Dans le cadre du projet Apache nous utilisons un outil GNU appelé GNATS. Il gère parfaitement plus de 3000 rapports de bogues, et les corrections correspondantes. Vous voulez trouver un outil grâce auquel de nombreuses personnes pourront répondre à des rapports de bogues, certaines en se spécialisant sur des éléments donnés du projet, capable de diffuser des informations par la messagerie électronique et d'interagir grâce à cette dernière plutôt qu'exclusivement via le Web. Adoptez un outil facile à exploiter et automatisable, afin que les développeurs répondent de façon aisée (la plupart d'entre eux n'apprécient guère cette phase) et aussi de sorte qu'ils retrouvent facilement tout bogue déjà découvert. Cette base de données deviendra de fait le dépôt de la connaissance périphérique à votre projet. Une telle base de données doit permettre de répondre à la traditionnelle question « Pourquoi tel comportement est-il une fonctionnalité et non un bogue ? »
L'approche Open Source n'est pas la panacée éliminant à l'avance toute menace. Non seulement parce que des conditions favorables restent toujours nécessaires, mais aussi parce que la gestion d'un développement en cours exige une extraordinaire somme de travail. Dans de nombreux cas vous devrez, en tant que promoteur d'un nouveau projet, agir un peu comme le docteur Frankenstein, mélangeant ici des éléments et appliquant là une tension électrique afin de donner vie à votre création. Bonne chance.
Page précédente | Début | Page suivante |
Quelle licence adopter ? | Remonter | La définition de l'open source |