Monter un projet pas à pas
Cet article n'est pas une suite de mon précédent article "soyez acteur d'un logiciel libre", mais il sera dans la même lignée. Le précédent article avait pour but de donner des idées à ceux qui veulent participer sans avoir un projet. Celui-ci aura pour but de décrire le tout début d'un projet et de montrer qu'il n'est pas besoin d'être toute une équipe de développement pour commencer.

Droit de réponse
Avant de rentrer dans le vif du sujet, je vais reprendre quelques courriers électroniques qui m'ont été envoyés suite au précédent article.

Première question: j'ai envie de monter un projet. Mais comment savoir s'il n'existe pas déjà un projet similaire?
A mon avis, la question ne se pose pas tout à fait en ces termes. Il faut plutôt se demander s'il n'existe pas un projet répondant au besoin que l'on a, et rechercher une solution. S'il n'existe pas de solution adaptée, alors il faut effectivement monter le projet. Si une solution existe, soit elle convient et on la prend, soit elle ne convient pas tout à fait et on l'adapte. Tout cela pour dire que ça ne vaut pas toujours le coup de réinventer la roue.

Notez cependant que, suivant votre philosophie concernant les logiciels et les logiciels libres en particulier, si vous trouvez votre bonheur mais qu'il faut payer, n'hésitez pas à démarrer un projet similaire à celui qui existe, afin d'avoir une solution libre par la suite. Cela offre de plus l'énorme avantage que vous avez déjà un modèle. Inconvénient : il ne faut pas copier le modèle mais seulement s'en inspirer !

La question devient maintenant de savoir comment rechercher une solution à un problème. Il existe plusieurs manières de faire. Certains sites référencent un grand nombre de logiciels. Je citerai http://freshmeat.net, qui peut être considéré comme complet, mais il en existe d'autres du même style. Ainsi, si l'on cible un peu plus, http://www.gnome.org comprend une bonne liste d'applications Gnome. Le site correspondant pour KDE existe sûrement, mais ne le connaissant pas, je me contenterai de citer http://www.kde.org (désolé pour les fans de KDE, mais étant un programmeur Gnome, je ne suis pas parfait ;-).

A côté des sites d'applications, il ne faut évidemment pas louper les moteurs de recherche généraux. Et souvent, indiquer une jolie phrase en anglais scolaire donne de bons résultats. Bizarrement même, les résultats sont la plupart du temps meilleurs si vous donnez une phrase complète contenant vos mots clefs, plutôt que de ne donner que ses mots clefs. Les moteurs de recherche seraient-ils intelligents ?

D'autres méthodes existent aussi : si on trouve une application ayant de nombreux points communs avec celle qu'on recherche, on peut envoyer un mail à l'auteur pour lui demander s'il ne connaît pas la solution au problème, et en étant un peu fouine, lui demander dans quelle mesure on pourrait faire évoluer son logiciel pour répondre au besoin. Cela devient une excellente manière de participer à un projet existant en apportant une grande valeur ajoutée au projet en question !

Enfin, pour ceux qui ont des amis ou des cyber-amis, il suffit de leur demander ce qu'ils en pensent !

Seconde question: Je viens d'être promu coordinateur d'un projet existant ; comment faire savoir que ce n'est plus l'autre mais moi qui gère le projet ?
Pas facile ! Il suffirait d'envoyer un mail à toute la planète, mais je ne crois pas qu'il existe d'alias pour joindre tous les possesseurs de boîte aux lettres électronique. Si quelqu'un connaît cet alias, j'ai une blague à faire à un copain...

A défaut, il faut l'annoncer partout où les utilisateurs peuvent le lire. Sur le site Web, il faut faire passer une "news" s'il y a des news sur le site. Et il faut rechercher toutes les occurrences du nom du précédent coordinateur pour les remplacer par le nom du nouveau. Idem dans tous les fichiers du projet. Si le projet a aussi une liste de diffusion, il faut y faire passer le mot, et éventuellement renouveler si personne n'a réagi.

Surtout, il faut que l'ancien coordinateur joue le jeu. Il devrait au minimum soit répondre qu'il n'est plus coordinateur et indiquer l'adresse de votre boîte aux lettres électronique, ou soit alors vous faire suivre le courrier. Le mieux est de faire les deux. Ensuite, c'est avec le temps que cela vient. Les utilisateurs habitués comprendront vite qui répond rapidement et efficacement aux mails et qui n'y répond pas. Les moins habitués mettront un peu plus de temps. Les nouveaux ne sauront pas qu'il y a eu changement et verront sur le site Web directement le nom du nouveau coordinateur.

Démarrez votre projet
Votre projet est au stade de code source. Vous savez le compiler et vous avez écrit un court fichier, habituellement README ou INSTALL, voire les deux, pour indiquer comment le compiler. Si vous pensez aller plus loin, il faut faire une pause au niveau programmation. En effet, vous en êtes au point où vous pouvez montrer quelque chose. Il faut le montrer et attirer des gens qui vous feront part de leurs remarques, qui vous demanderont probablement si le projet permettra ceci ou cela dans le futur, ou même si vous avez de la chance, qui vous proposeront de l'aide tout de suite. Attention, suivant l'intérêt du projet, ce genre de retour peut arriver dans le mois qui suit ou pas avant un an. Il ne faut surtout pas se décourager.

Montrez votre projet
Pour montrer votre projet, pas besoin de faire les salons, ni de contacter les agences de publicité. Un simple site Web suffit. Mais comment faire un site Web ? La première chose est de trouver de l'espace disque chez un hébergeur. La plupart des fournisseurs d'accès à Internet (FAI en français, ISP en anglais) fournissent un espace disque qui varie de 20 Mo à 100 Mo. Donc, si vous vous connectez à Internet avec votre modem, renseignez-vous chez votre FAI pour savoir comment il héberge les pages Web de ses abonnés.

Le Web
Faites vos pages Web
On va partir du principe que vous n'avez pas de site Web personnel et que vous connaissez le HTML de base. Si vous avez déjà un site Web personnel, sautez quelques paragraphes. Si vous ne connaissez pas le HTML, trouvez-vous un bon bouquin ou un didacticiel sur Internet suivant vos goûts.

La page principale, habituellement nommée index.html, devra être une sorte de sommaire. Faites ici plutôt un site Web personnel et un sous-site consacré à votre projet. Le sommaire contiendra donc un lien ou plus vers des pages de contenu personnel, et un lien vers les pages de votre projet. Attention, maintenir un site Web demande beaucoup de boulot. Ne mettez donc que des informations qui ne seront pas désuètes dans 15 jours et évitez de construire un énorme site qui sera impossible à gérer par la suite. Un site Web agréable à visiter autant qu'il est agréable à maintenir ne contiendra que votre CV ou description sommaire de votre personne et des liens vers des choses qui vous tiennent vraiment à c ur, tel que le projet.

L'intérêt d'avoir une page principale qui fasse sommaire permet aussi de mettre un lien pour chacun de vos projets si un seul ne vous suffit pas. D'ailleurs, quand on se lance, on ne s'arrête pas quand le projet est stable: on prend part à d'autres projets.

Les pages Web du projet : le contenu
Maintenant, on passe aux choses sérieuses : le sous-site du projet.
Le site du projet doit contenir plusieurs informations capitales :
- Le nom du projet.
- Une description du projet d'environ cinq phrases : il faut que le lecteur ne soit pas fatigué de lire avant même d'avoir déchiffré le premier mot.
- Les pré-requis (bibliothèques nécessaires à la compilation, langage du code source...).
- Le nom de l'auteur (ou des auteurs) : vous (et vos partenaires?). Ne pas oublier l'email. Il faut pouvoir vous joindre.
- Un lien vers une page contenant le ChangeLog.
- Un lien vers la page où l'on peut télécharger votre logiciel.
- Une note concernant la compilation, la configuration et le lancement de votre programme.

Le nom du projet est un nom qui doit être retenu facilement. Il doit aussi attirer l'attention. Par contre, au niveau légal, il ne faut pas reprendre un nom existant, et de plus en plus, les noms simplement ressemblants deviennent risqués. Le nom du projet peut résumer le projet en lui-même. C'est le cas par exemple de gnome-libs qui, comme son nom l'indique, contient les bibliothèques de base du projet gnome. Mais le nom du projet peut aussi être complètement sans rapport avec son contenu. Qui va se douter que Python est un langage de programmation orienté objet ? Bref, à vous de choisir. Il n'existe pas de loi ni de statistiques en la matière.

La description. Elle doit être facile à repérer sur la page. Et comme c'est du texte, elle ne doit pas être rébarbative à lire. Donc, elle doit être courte, pas forcément exhaustive (quoique) mais résumer la raison d'être du projet.

Les autres éléments doivent figurer sur la page principale, au moins sous forme de liens. Si le visiteur intéressé veut vous joindre, il doit pouvoir facilement identifier soit votre nom et votre adresse électronique, soit un lien hypertexte vers la page des contacts. De même, les pré-requis et la note explicative sur la compilation, configuration et lancement du programme se trouvent souvent sur la même page, facilement accessibles, aussi facilement accessibles que la page de téléchargement.

Les pages Web du projet : la forme
Tout d'abord, respectez la net-iquette. Ne faites pas de pages trop longues. Ne mettez pas une tonne d'images. Evitez les "frames" que trop souvent, les internautes n'aiment pas.

Les images sont un aspect délicat du site. En effet, le site, donc le projet, pour être d'autant plus attractif, doit contenir des captures d'écran. Mais ces images ne doivent pas être trop longues à charger sous peine de voir le visiteur s'en aller avant d'avoir vu quoi que ce soit. Le moyen le plus simple est d'avoir une page avec les captures d'écran, et un lien vers cette page sur la page principale du projet. Cependant, suivant le nombre de captures d'écrans, il peut être de bon goût de réaliser une interface de navigation en plusieurs pages, avec deux ou trois captures d'écran sur chaque page. Vous pouvez aussi mettre des petites vignettes qui, lorsqu'on clique dessus, renvoient vers une image plus grande. A vous de voir quelle énergie vous voulez consacrer à la réalisation de votre site Web.

Les liens hypertexte ont leur importance aussi. Je viens de parler du lien vers les captures d'écran, et plus haut, du lien vers les contacts. On peut se représenter les liens comme des questions de la part du visiteur, et les réponses consistent en la page pointée par le lien. Pour me faire mieux comprendre, voici une illustration : le visiteur tombe sur la page principale. Il va par exemple se demander à quoi ressemble l'interface graphique du logiciel. Question : "screenshots ?". Donc, le lien vers les captures d'écran doit exister, être facilement repérable et s'appeler "screenshots". Puis il va vouloir vous contacter. Question : "email ?" ou "contact ?", voire "authors ?". Le lien vers la page contenant votre adresse électronique portera donc un de ces trois noms.

Comment rendre facilement repérables ces liens correspondant aux questions du visiteur ? Une solution classique et de bon goût est de mettre la liste de ces liens en haut à droite ou à gauche, en colonne. En ligne, on peut les mettre juste après le nom du projet, voire avant : tout en haut. On peut aussi les mettre en ligne tout en bas, mais cela oblige le visiteur à faire défiler le texte jusqu'en bas.

Les pages Web du projet : la maintenance
Le site Web que vous construisez devra être le plus simple possible. En effet, suivant vos besoins futurs, il est probable que vous deviez le réécrire entièrement pour lui donner un nouveau look et surtout pour vous faciliter les tâches de maintenance.
Je n'aborderai donc pas vraiment la question de la maintenance du projet ici. Simplement, il vous faudra vous adapter à vos propres besoins en utilisant des technologies plus avancées par la suite comme les archaïques CGI, le PHP (ou JSP pour les fans), voire une technologie de plus grande ampleur comme Zope ou concurrent.
Bref, ne voyez pas trop grand dès le début : c'est une perte inutile d'énergie, et surtout, vous voudrez probablement reprendre rapidement le développement même de votre projet.

Les fichiers téléchargeables
Le répertoire de téléchargement
Ces fichiers sont habituellement le code source. Quand on commence un projet, il est inutile de s'attaquer directement à une arborescence CVS avec interface Web et autres choses que l'on peut voir sur des sites comme http://savannah.gnu.org ou http://sourceforge.net. Un simple répertoire contenant tous les fichiers suffit. Souvent, on va penser à un répertoire disponible en ftp. C'est le plus logique car le ftp est conçu pour transférer des fichiers ainsi que son nom l'indique. Cependant, les hébergeurs fournissent volontiers de l'espace disque accessible en http, mais pas forcément en ftp. Donc, si vous avez accès à de l'espace disque visible avec ftp, profitez-en. Sinon, un simple répertoire qu'on appellera généralement "download" suffira. Ensuite, c'est à l'intérieur de ce répertoire que vous mettrez vos archives publiques. Ne mettez pas de fichier index.* à l'intérieur : cela permet au serveur Web d'en afficher le contenu sans que vous ayez quoi que ce soit à faire. Cela facilite la maintenance car vous n'avez pas à éditer de fichier contenant des hyperliens vers les fichiers téléchargeables.

Les astuces du serveur Apache
Si votre hébergeur a choisi le serveur Web Apache et qu'il ne s'est pas trop éloigné de la configuration par défaut, vous pouvez profiter de certaines fonctionnalités. Ainsi, si le répertoire de téléchargement contient un fichier texte portant le nom HEADER, il en affichera le contenu avant la liste des fichiers. Idéal pour présenter le contenu du répertoire, ou plutôt pour dire qu'il contient les archives de votre projet, sa licence et un éventuel avertissement. De même, après la liste des fichiers, le serveur Web affichera le contenu du fichier texte README s'il existe.

Un simple fichier texte vous semble basique et vous préféreriez du HTML ? Rien de plus facile ! N'utilisez pas de fichiers HEADER et README, mais HEADER.html et README.html. Bien sûr, le contenu de ces deux fichiers ne sera plus du texte ASCII mais du HTML ! Cela permet de personnaliser un peu plus le site en changeant par exemple la couleur de fond.

Avec un peu de chance, vous pouvez aussi changer la configuration locale du serveur au niveau de votre répertoire en mettant des options dans le fichier .htaccess. Voyez la documentation du serveur Apache (site http://httpd.apache.org) pour ces options. Je vous en donnerai tout de même une sympa :

AddDescription "ma description" archive-0.0.1.tar.gz

Cela ajoute une description pour le fichier archive-0.0.1.tar.gz. On peut utiliser des jokers (par exemple archive*.tar.gz) pour décrire le nom du fichier.

La numérotation des versions
Le choix du numéro de version est un peu anarchique. Personnellement, je considère une application en 0.0.x en stade alpha, c'est-à-dire qu'il n'y a pas encore tout ce qu'il faut pour que l'application soit un minimum conviviale à installer et à configurer. A partir de la version 0.1.0, on a une application correcte, mais qui n'a pas encore toutes les fonctionnalités prévues. Elles viendront au fur et à mesure. Les version en 0.99.x ne doivent plus évoluer au niveau des fonctionnalités et seules les corrections de bogues doivent justifier un changement de version. Au lieu d'une version en 0.99.x, on peut aussi avoir une version 1.0RCx (Release Candidate), mais pour commencer avec les RC, il faut être plus ou moins sûr qu'il n'y en aura pas beaucoup. Personnellement, je préfère la notation 0.99.x. De plus, une version RCx permet d'avoir une pré-version 1.0 dans laquelle il peut manquer quelques traductions ou fichiers annexes (comme les fichiers de démarrage pour un démon). Et lorsqu'on a la version 1.0, on recommence comme avant mais avec un 1 devant, à la place du 0 !

Une remarque importante : une fois que vous avez mis une archive sur le Web, il n'est plus question de la retirer sous prétexte que vous avez oublié quelque chose dedans ou que vous venez de découvrir et corriger un bogue, même deux minutes après avoir monté l'archive sur le Web. En effet, un utilisateur peut déjà avoir téléchargé l'archive et ne comprendra plus rien si l'archive disparaît ou pire, si elle est remplacée. Dans ce cas, il faut tout simplement créer une nouvelle version.

Faites connaître votre projet
Annoncez-vous
Maintenant que votre projet est présentable, et surtout que vous disposez d'un site Web permettant de le présenter, il ne vous reste plus qu'à vous faire connaître. Annoncez-vous sur les sites de type http://freshmeat.net. Et relisez le paragraphe du début, mais en vous disant que maintenant, ce n'est plus vous qui avez un problème à résoudre et une solution à trouver mais quelqu'un d'autre. Il va se poser les mêmes questions que vous au début. Prenez les devants et annoncez-vous partout où vous avez/auriez cherché au début, dans la mesure où c'est possible naturellement.

Ayez un projet vivant
Un projet vivant, c'est un projet qui bouge. Donc, un projet où l'on peut remarquer des différences suffisamment pour qu'on ne le considère pas comme endormi ou mort. Le meilleur moyen étant d'avoir une section "news", il faut savoir l'alimenter. Et au début, quoi de mieux qu'un résumé de l'avancement de votre projet à chaque fois que vous développez ?


Conclusion
Vous avez démarré votre projet. Vous avez monté votre site Web. La planète peut maintenant entendre parler de vous. Pas besoin d'en faire plus pour l'instant. Il ne vous reste plus qu'à reprendre votre éditeur de texte et votre compilateur et continuer vos activités de développeur en attendant le facteur. Ne vous découragez surtout pas si le facteur ne vient pas tout de suite : il faut du temps pour qu'un utilisateur intéressé vous repère et ait quelque chose à vous dire. Bref, au boulot, et donnez de la vie à votre projet !

L'auteur
Yves Mettier, consultant CMG-Admiral, participe activement au développement des logiciels libres avec en particulier, la coordination des projets GTKtalog et GMemLogger, ainsi que de nombreuses contributions dont la traduction en français du lecteur de mails Cronos II.
Mail: ymettier@libertysurf.fr

Références:
freshmeat
http://freshmeat.net

gnome.org
http://www.gnome.org

www.kde.org
http://www.kde.org

sourceforge
http://www.sourceforge.net

Savannah
http://savannah.gnu.org/