Amorçage

Il est essentiel pour la santé d'un projet à code ouvert de profiter d'un élan grâce auquel il d'évoluera, et de répondre à de nouveaux défis. Le monde du logiciel ne connaît rien de statique, et chaque composant majeur restera maintenu et amélioré. L'un des avantages de ce modèle est qu'il réduit la quantité de développement attribuée à chaque groupe. Vous avez donc besoin d'autres développeurs actifs.

Durant la phase de détermination de la demande vous rencontrerez probablement un groupe d'autres entreprises et de personnes suffisamment intéressés pour former un noyau de développeurs. Exposez-leur les grandes lignes de votre stratégie, sans la fixer. Il peut être utile de créer une liste de diffusion pour discuter de ce projet avant de fixer quoi que ce soit. Ce groupe émettra probablement des idées pertinentes et dressera une liste de ses propres ressources mobilisables.

Dans le cas d'un projet peu ambitieux les volontaires pourront ne s'engager qu'à essayer votre produit et rester abonnés à la liste de diffusion. Il faudra, sinon, quantifier les ressources disponibles.

Voici les ressources minimum pour un projet de complexité modérée, comme par exemple le développement d'un outil générique de gestion d'un panier d'achats sur le Web, ou d'un nouveau type de serveur réseau implémentant un protocole simple. Je décrirai ci-après les rôles et types de compétences.

Rôle 1 : Coordination de l'infrastructure

Une personne installera et maintiendra la liste de diffusion et ses listes d'abonnés, le serveur Web, le serveur CVS (Concurrent Versioning System), la base de données des bogues, etc.

  • Mise en place : 100 heures

  • Maintenance : 20 heures/semaine

Rôle 2 : Coordinateur du code

Quelqu'un chargé de la coordination des engagements et responsable de la qualité du code implémenté. Il gérera aussi les corrections apportées par des tiers et résoudra les incompatibilités entre ces contributions et les bogues que leur intégration rend patents. Cela s'ajoute à tout développement dont il peut être chargé.

  • Mise en place : 40-200 heures (suivant le temps nécessaire pour nettoyer le code avant qu'il soit rendu public).

  • Maintenance : 20 heures/semaine

Rôle 3 : Maintenance de la base de données des bogues

Bien qu'il ne s'agisse pas ici d'assurer de l'assistance technique non rémunérée, il reste important que le public dispose d'un moyen sûr d'expédier aux développeurs leurs questions et les rapports de bogues. Au sein d'une organisation libre les développeurs ne sont, bien entendu, pas tenus de répondre à tous les messages reçus mais doivent déployer des efforts raisonnables afin de répondre aux remarques pertinentes. La maintenance de la base de données des bogues sera la première ligne de soutien, quelqu'un étudiera donc régulièrement les rapports et supprimera les questions auxquelles la documentation répond et les stupidités puis transmettra aux développeurs les descriptions de problèmes réels.

  • Mise en place : juste assez pour apprendre à connaître le code.

  • Maintenance : 10-15 heures/semaine

Rôle 4 : Maintenance de la documentation et du site Web

Les responsables de projets de logiciels libres négligent souvent ce poste et l'abandonnent donc parfois aux ingénieurs ou à des personnes souhaitant réellement contribuer mais n'ayant pas les connaissances techniques nécessaires. Elle reste même souvent simplement vacante. En admettant que nous ne cultivions pas le secret il faut admettre qu'un logiciel doit, afin de gagner sans cesse de nouveaux utilisateurs, bénéficier des efforts d'intervenants capables de publier de l'information destinée aux utilisateurs potentiels. Cela aide à réduire le nombre de rapports de bogues redondants car procédant de déficiences de la documentation, et encourage aussi de nouvelles personnes à connaître le code puis à y contribuer à leur tour. L'importance d'un document décrivant l'architecture interne du logiciel est capitale, et celle d'un exposé des procédures ou classes principales du code l'est presqu'autant.

  • Mise en place : 60 heures (en présumant que peu de code ait été documenté).

  • Maintenance : 10 heures/semaine

Rôle 5 : Stratège/évangéliste/commercial

Une personne capable de susciter un élan pour le projet en trouvant d'autres développeurs, demandant à des utilisateurs potentiels spécifiques d'essayer le logiciel, trouvant d'autres entreprises candidates pour adopter cette nouvelle plate-forme, etc. Il ne s'agit pas ici seulement de marketing ou de prospection commerciale, mais d'une mission d'ordre technique dont le responsable présentera sa capacité à percevoir clairement le rôle du projet dans une perspective d'ensemble.

  • Mise en place : assez pour connaître le projet

  • Maintenance : 20 heures/semaine

Ces cinq rôles occupent presque trois personnes à plein temps. En réalité un groupe de personnes partageant les responsabilités pourront partager les responsabilités afférentes, et certains projets survivront, sitôt les premiers obstacles de publication franchis, alors que le niveau d'implication moyen des participants ne dépasse pas cinq heures hebdomadaires. Mais au début du projet les développeurs doivent concentrer leurs efforts comme s'il s'agissait d'un classique projet industriel d'entreprise.

Ces cinq rôles n'assureront aucun nouveau développement, tout cela ne relève que de la maintenance. Si vous ne trouvez pas assez de ressources auprès de collègues et de partenaires pour assurer tout cela ainsi qu'un nombre suffisant de nouveaux développeurs chargés du travail de base (jusqu'à ce que de nouvelles recrues se présentent) vous devriez reconsidérer la publication du code de votre projet.