Table des matières
Le modèle d'initialisation des projets libres a été décrit par Eric Raymond dans son papier de référence La cathédrale et le bazar. Il y écrit :
Tout bon logiciel commence par gratter un développeur là où ça le démange.
(cf http://www.linux-france.org/article/these/cathedrale-bazar/cathedrale-bazar_monoblock.html )
Notez que Raymond n'a jamais dit qu'un projet libre n'apparaît que lorsque qu'un développeur se démange. Il dit plutôt que de bons logiciels sont produits lorsque l'initiateur possède un intérêt personnel à voir son problème résolu; Le corollaire de ce principe appliqué au logiciel libre est le fait qu'une problématique personnelle est la motivation la plus fréquente au démarrage d'un projet.
Cette règle est toujours valable mais moins qu'en 1997, lorsque Raymond l'a formulée. Aujourd'hui, un phénomène se développe : le développement ex nihilo par d'importantes organisations -incluant des organismes à but lucratifs- de grands projets libres gérés de façon centralisée. La production de code par des développeurs isolés afin de répondre à un besoin précis est toujours un modèle très répandu mais ce n'est plus le seul.
L'avis de Raymond n'est reste pas moins très clairvoyant. L'intérêt direct des concepteurs du logiciel demeure la condition essentielle de son succès car ils l'utilisent eux-mêmes. Si le logiciel ne répond pas au besoin initial, la personne ou l'organisation le développant éprouvera de la frustration dans ses tâches quotidiennes. Par exemple, le projet OpenAdapter (http://www.openadapter.org/), à l'initiative de la banque d'investissement Dresdner Kleinwort Wasserstein et dont l'objet est le développement d'un framework d'intégration des systèmes financiers hétérogènes aurait difficilement pu provenir de la démangeaison d'un particulier. Il s'agit d'une démangeaison à un niveau institutionnel. Mais cette démangeaison est issue directement de l'expérience de cette institution et de ses partenaires, donc si ce projet les soulage, ils seront les premiers à s'en rendre compte. Ce mode de fonctionnement permet de produire un logiciel adéquat parce que les échanges entre utilisateurs et producteurs permettent d'alimenter un cercle vertueux. Le programme est avant tout écrit par eux et pour eux ; ils peuvent donc répondre à leur problématique. Il a été écrit pour résoudre un problème particulier, et a ensuite été partagé avec d'autres, comme si le problème avait été une maladie et le programme son antidote dont la distribution a pour effet d'en éradiquer l'épidémie.
Ce chapitre décrit la manière de fournir au monde un nouveau projet libre, mais la plupart de ses recommandations pourrait tout aussi bien s'appliquer à l'industrie pharmaceutique. Les objectifs sont très similaires : vous voulez décrire clairement ses capacités thérapeutiques, sa posologie et vous assurer qu'ils tomberont entre de bonnes mains. Mais dans le cas d'un logiciel, vous désirez également attirer certains patients afin qu'ils se joignent à l'effort de recherche pour améliorer le principe actif au bénéfice de tous.
La production de logiciel libre est une tache bipolaire. Le logiciel doit acquérir de nouveau utilisateurs mais également de nouveaux développeurs. Ces deux taches ne sont pas nécessairement ambivalentes mais la différence dans leurs objectifs complexifie la façon de présenter initialement le projet. Certaines informations sont utiles aux deux audiences, certaines leur sont spécifiques. Néanmoins, les deux types d'information doivent respecter le principe de présentation échelonnée, dans le sens où le niveau de détail présenté à chaque étage doit correspondre scrupuleusement à l'effort et au temps consenti par le lecteur. Une augmentation de l'effort doit assurer en contrepartie une récompense proportionnelle. Lorsqu'il y a perte de corrélation entre les deux, les gens perdent rapidement la foi dans le projet et stoppent leurs investissements.
Le corollaire de ce principe est le fait que l'apparence compte. Les développeurs en particulier n'aiment pas cette idée. Leur attachement au fond plutôt qu'à la forme est souvent brandi comme une marque de professionnalisme. Ce n'est pas un hasard si tant de développeurs exhibent une réelle antipathie pour le marketing et les relations publiques ; pas plus que le fait que les graphistes professionnels sont souvent horrifiés par le résultat auquel arrivent les développeurs livrés à eux mêmes.
C'est déplorable car il existe des situations où la forme est le fond et la présentation d'un produit en fait partie. Par exemple, l'apparence du site Web d'un projet est la première chose qu'un visiteur va en retenir. Cet aspect du site est pris en compte avant le contenu en tant que tel, bien avant que tout texte soit lu ou les liens activés. Aussi injuste que cela puisse paraître, les gens ne peuvent se refréner de former leur opinion au premier regard. L'apparence d'un site fourni au visiteur le degré de soin apporté à organiser la présentation. Les humains possèdent une antenne particulièrement sensible pour détecter le niveau d'effort consenti. La plupart d'entre nous peuvent en un simple coup d'oeil s'avancer sur le fait qu'un site soit une simple concaténation d'informations ou le fruit d'une réflexion mûrie. Le site est le premier indicateur exposé par le projet et l'impression qu'il dégage s'appliquera au reste du projet par association mentale.
Ainsi, bien que ce projet se concentre sur le contenu servant au démarrage d'un projet, gardez en tête que l'apparence compte également. Sachant qu'un site Web doit s'adresser à deux publics -les utilisateurs et les développeurs- une attention particulière doit être apportée à la clarté et à l'adéquation du message. Bien que le conception de sites Web ne soit pas le sujet de ce livre, un principe est à retenir, en particulier si le site s'adresse à des audiences distinctes : les visiteurs doivent directement savoir où pointe un lien avant de cliquer dessus. Par exemple, il doit être évident, simplement en regardant les liens vers la documentation utilisateur, qu'ils conduisent bien à la documentation utilisateur, et non -par exemple- à la documentation interne des développeurs. L'un des rôles d'un projet est de fournir de l'information, mais également du confort. Le simple fait de retrouver des informations standards à un endroit attendu rassure les utilisateurs et les développeurs qui veulent décider de s'impliquer ou pas. Le projet signifie ainsi qu'il prend ses responsabilités, qu'il anticipe les questions, et qu'il a fait un effort pour y répondre avec un minimum d'exigence pour l'intervenant. En constituant cette atmosphère de préparation, le projet envoie un message clair : "Votre temps ne sera pas gaspillé si vous vous impliquez" : exactement ce que les gens veulent entendre...
Avant de démarrer un projet libre, une règle de base est à respecter :
Vérifiez toujours qu'un projet existant ne répond pas déjà à votre besoin. Il est possible voire probable que quelqu'un ait déjà traité votre problématique. Si tel est le cas, et que le code a été publié en licence libre, il serait peu judicieux de réinventer la roue. Il y a bien entendu des exceptions à cette règle : si le but du projet est principalement didactique ou s'il concerne un domaine de niche si réduit qu'il n'y a aucune chance que quelqu'un ait pu le traiter avant vous. Mais en général, il ne coûte rien de vérifier et le jeu en vaut largement la chandelle. Si les moteurs de recherche classiques ne retournent aucun résultat, jetez un coup d'oeil aux sites d'information traitant des logiciels libres (ce point sera développé ultérieurement) ou dans les registres de la FSF (Free Software Foundation) : http://directory.fsf.org/.
Même si vous ne trouvez pas exactement ce que vous aviez en tête, il est possible de détecter un projet similaire pour lequel une collaboration serait plus fructueuse que de partir seul de zéro.
Finalement, vous avez regardé autour de vous, n'avez rien trouvé qui corresponde à votre besoin et vous avez décidé de démarrer un nouveau projet.
Et maintenant ?
L'aspect le plus difficile du lancement d'un projet libre est de transformer une vision personnelle en vision universelle. Même si vous ou votre organisation avez parfaitement cerné le besoin, l'exprimer de façon compréhensible au reste du monde peut s'avérer être un travail conséquent. Il est néanmoins fondamental de prendre le temps de le faire. Les fondateurs du projet doivent fixer ses objectifs, ce qui implique de fixer ses limites -aussi bien les fonctionnalités qu'il assurera que celle qu'il n'assurera pas- et ainsi de coucher ses finalités sur papier. Cette étape se déroule en général sans difficultés majeures bien qu'elle puisse quelque fois révéler des hypothèses cachées voire des désaccords sur la nature du projet, ce qui est une bonne chose : mieux vaut résoudre les divergences en amont. L'étape suivante est d'empaqueter le projet à destination du grand public, ce qui s'avère être un travail titanesque.
Ce qui rend ce travail si laborieux est le fait qu'il consiste à formaliser et documenter des concepts que tout le monde connaît déjà -"tout le monde" désignant les intervenants actuels du projet. De ce fait, aucun bénéfice immédiat n'en est retiré pour ces derniers. Aucun besoin de fichier LISEZ-MOI qui décrirait le projet, pas plus que d'un dossier de conception ou d'un manuel utilisateur. Aucun besoin d'organiser le code source selon les standards (tacites mais universels) du libre, toute organisation est bonne puisqu'elle leur convient, qu'ils y sont déjà familiarisés et qu'il savent comment exécuter le code de toute manière. De même, il est sans gravité -pour eux- que les principes généraux d'architecture demeurent non documentés : ils les connaissent déjà.
Les nouveaux arrivants de leur coté ont grand besoin de ces documents, mais heureusement pas tous simultanément. Il n'est pas obligatoire de fournir toutes les ressources imaginables en pré-requis du projet. Dans un monde parfait, peut-être, tout nouveau projet libre apparaîtrait avec un dossier de conception impeccable, un guide utilisateur exhaustif (avec le détail des fonctionnalités restant à implémenter et déjà disponibles), un code source superbe et empaqueté de façon portable pour fonctionner sur toutes les plates-formes et ainsi de suite. En réalité, assurer tout ceci serait inacceptablement coûteux en ressource et il s'agit de toute façon de tâches pouvant raisonnablement être réalisées en cours de projet par des volontaires.
Ce qui est incontournable néanmoins est que suffisamment d'investissements ait été assurés sur la présentation du projet pour lever la barrière de l'inconnu auprès des nouveaux venus. Imaginez cet investissement comme la première étape d'un processus de bootstrap qui apporterait au projet le quanta minimal d'énergie d'activation. J'ai entendu parler de ce concept sous le nom d'énergie d'hacktivation , c'est à dire la quantité d'énergie qu'un nouveau venu consomme avant de produire à son tour quelque chose d'utile au projet. Le seuil d'énergie d'hacktivation requis doit être le plus bas possible. C'est là votre première tâche que de limiter au maximum ce niveau d'énergie pour encourager les gens à s'investir.
Chacun de ces sous-chapitres décrivent un aspect important du démarrage d'un nouveau projet. Ils sont globalement présentés dans l'ordre où les visiteurs les rencontrent, bien que l'ordre dans lequel vous les avez mis en place puisse différer. Traitez les comme une check-list. Vérifiez quand vous démarrez un nouveau projet, pour chaque point, qu'il a été traité, où au moins que vous savez apprécier les conséquences si tel n'a pas été le cas.
Mettez vous à la place d'une personne qui aurait entendu parlé de votre projet pour la première fois, peut être après l'avoir découvert à l'issue d'une laborieuse recherche de solution à sa problématique. Le premier contact avec le projet se fera au travers de son nom.
Un bon nom ne fera pas systématiquement le succès d'un projet, pas plus qu'un mauvais son échec (un très mauvais y conduira mais nous pouvons supposer que personne ne tente de faire échouer son propre projet volontairement). Néanmoins, un mauvais nom peut ralentir l'adoption d'un projet, soit parce que les gens ne le prennent pas au sérieux, soit parce qu'il est difficile à mémoriser.
Un bon nom:
Donne une idée immédiate du champs d'action d'un projet ou au moins y est lié de façon évidente de telle sorte que quelqu'un connaissant le projet et son domaine se souviennent immédiatement de son nom.
Est facile à mémoriser. Il est clair que la langue de Shakespeare est devenue le standard de facto de la communication sur Internet. "Facile à mémoriser" signifie en réalité "Facile à mémoriser pour un anglophone". Les noms issus de jeux de mots liés à la prononciation locale par exemple seront totalement opaques pour la plupart des lecteurs anglophones. Si le jeu de mot est particulièrement saisissant ou plaisant, il peut tout de même être conservé; gardez simplement en tête que de nombreuses personnes lisant le nom n'entendront pas intérieurement ce qu'un lecteur natif entendrait.
Est distinct du nom d'autres projets et n'enfreint pas des marques déposées. Il s'agit simplement de bonnes manières et de bon sens juridique. Ce n'est pas une bonne idée que de créer de la confusion, il est déjà suffisamment difficile de garder une trace de tout ce qui est déjà disponible sur Internet pour ne pas nommer les choses de la même façon. Les liens mentionnés précédemment dans la section intitulée « Observez d'abord » sont utiles pour vérifier si un autre projet utilise déjà le nom que vous aviez à l'esprit. Des recherches de marques déposées sont également disponibles à http://www.nameprotect.org/ et http://www.uspto.gov/.
Est de préférence disponible en tant que nom de
domaine .com,
.net, et
.org. Il est conseillé d'en
réserver un (probablement le .org) en tant que site officiel
du projet ainsi que les deux autres pour éviter le
cyber-squatting de tiers qui désirerait tirer profit de la
notoriété du projet. Même si vous prévoyez de faire héberger
le projet par une forge (voir la section intitulée « Hébergement sur une forge »), vous pouvez
enregistrer les noms de domaines du projet et les rediriger
vers le site de la forge. Ceci aide les utilisateurs à
mémoriser les URL.
Une fois que le site Web a été trouvé, la seconde chose que les visiteurs font en général est de rechercher une courte description du projet ou de sa finalité pour déterminer (en moins de trente secondes) s'ils désirent ou non en savoir plus. Cet abstract doit être clairement visible au sein de la page de garde du site, de préférence juste sous le nom du projet.
La description doit être concrète, concise et, par dessus tout, courte. Voici un exemple à suivre :
Créer, en tant que communauté, la suite bureautique de référence au niveau international qui fonctionnera sur toutes les plates-formes majeures et qui assurera l'accès à l'ensemble de ses fonctionnalités et données sous la forme d'une API orientée composants et d'un format fichier de type XML.
En quelques mots, les points principaux sont révélés tout en s'appuyant largement sur les connaissances actuelles du lecteur. En précisant "en tant que communauté", ils affirment qu'aucun organisme privé ne dominera le développement ; "international" signifie que le logiciel permettra aux utilisateurs de travailler dans différentes langues et données régionalisées ; "toutes les plates-formes majeures" ajoute qu'il sera portable sous Unix, Macintosh, et Windows. Le reste signale que les architectures interopérables et les formats ouverts forment une part importante des principes directeurs du projet. Il n'est pas explicitement dit que ce projet est une alternative à la suite bureautique Microsoft Office mais la plupart des visiteurs auront lu entre les lignes. Même si cette description peut sembler quelque peu verbeuse au première abord, elle s'avère en fait exhaustive : les mots "suite bureautique" sont concrets pour les utilisateurs familiers de ce type de logiciel, on s'appuie sur la connaissance présumée du lecteur (probablement au tant qu'utilisateur de MS Office) pour assurer la concision du message.
La description des finalités dépend en partie de son auteur, pas seulement du logiciel en tant que tel. Dans l'exemple précédent d'OpenOffice.org, il est utile d'utiliser les mots "en tant que communauté" car le projet était initialement principalement porté par Sun Microsystems. En précisant ainsi la nature du projet, Sun indique qu'il est sensible à la crainte qu'il puisse dominer le processus de développement et la feuille de route. De cette façon, en exposant clairement la prise en compte du problème, c'est une grande partie du problème lui-même qui disparaît. De leur coté, les projets qui ne sont pas soutenus par un unique organisme n'aura probablement pas à appuyer sur cet aspect puisque le mode de développement communautaire est la norme dans ce domaine, il n'y a donc pas d'impératif à le lister comme élément des principes directeurs.
Les visiteurs toujours intéressés après avoir consulté les finalités désirerons ensuite obtenir d'avantage de détail, peut être le guide utilisateur ou de développement, et voudront éventuellement télécharger quelque chose. Mais ils doivent d'abord avoir la certitude qu'il s'agit d'un logiciel libre.
La page de garde doit indiquer sans ambiguïté que le projet est libre. Ceci peut sembler évident mais vous seriez surpris du nombre de projets qui oublient de le mentionner. J'ai déjà vu des projets dont la page de garde non seulement ne mentionnait pas la licence sous laquelle le projet était distribué mais pas même qu'il était libre. Quelque fois, cette information cruciale est reléguée dans la page de Téléchargement ou la page réservée aux développeurs, voire à d'autres endroits nécessitant plus d'un clic de souris à atteindre. Dans des cas extrêmes, la licence n'est pas donnée du tout et le seul moyen de l'obtenir est de télécharger le logiciel et de regarder à l'intérieur.
Ne commettez pas cette erreur qui peut coûter des développeurs et utilisateurs potentiels. Affichez clairement, juste sous les finalités, que le projet est "libre" ou "open source" et précisez la licence exacte. Un guide de prise en main rapide pour choisir une licence est donnée dans la section intitulée « Choisir une licence et la mettre en oeuvre » plus loin dans ce chapitre, et les questions de licences sont discutées en détail dans le Chapitre 9, Licenses, Copyrights, and Patents.
A cette étape, notre visiteur a déterminé -probablement en moins d'une minute- s'il est suffisamment intéressé pour dépenser, disons, cinq minutes de plus à approfondir ce projet. Les paragraphes suivants décrivent ce qui devrait rencontrer durant ces cinq minutes supplémentaires.
Il s'agit d'une courte liste des fonctionnalités principales du logiciel (si des fonctions ne sont pas encore opérationnelles, vous pouvez les lister à condition de préciser "prévu" ou "en cours"), ainsi que l'environnement technique nécessaire à son exécution. Imaginez cette liste de fonctionnalités/pré-requis comme ce que vous répondriez à quelqu'un vous demandant un bref résumé du logiciel. Cette liste est une extension naturelle des finalités. Par exemple, pour cette mission :
Créer un moteur d'indexation et de recherche textuel utilisable via une riche API permettant aux développeurs de fournir des services de recherche dans de grandes quantités de fichiers texte.
La liste fonctionnalités/pré-requis fournirait les détails afin de clarifier cette mission.
Fonctionnalités:
Recherche dans des fichiers texte, HTML et XML
Recherche de mots ou de phrases
(prévu) Recherche approchante
(prévu) Mise à jour incrémentale des index
(prévu) Indexation de sites Web distants
Pré-requis:
Python 2.2 et supérieur
Suffisamment de disque pour stocker les index (approximativement le double de la taille des données indexées)
Disposant de ces informations, les visiteurs peuvent rapidement déterminer si ce logiciel leur convient. Ils peuvent également décider ou non de proposer leurs services en tant que développeurs.
Les gens apprécient toujours de connaître l'état d'un projet. Pour les nouveaux projets, ils veulent connaître le fossé entre les promesses et la réalité courante. Pour les projets mâtures, c'est l'activité de maintenance qui les intéresse : fréquence de nouvelles versions, réactivité face aux tickets d'incidents, etc.
Pour répondre à toutes ces questions, il est conseillé de fournir une page de statut du développement listant les objectifs du projet à court terme et ses besoins (par exemple, il peut rechercher un développeur disposant d'une expertise particulière). Cette page fournit également un historique des versions antérieures, munie d'une liste de fonctionnalités, pour que les visiteurs puissent se faire une idée de ce que le projet appelle "avancement" et à quelle vitesse effective il correspond.
Ne craignez pas de paraître en plein chantier et ne vous laissez pas tentés par un enjolivement du statut. Tout le monde sait qu'un logiciel évolue par paliers; il n'y a aucune honte à affirmer "Ceci est un logiciel en alpha avec des bogues connus. Il démarre et fonctionne la plupart du temps mais utilisez-le à vos risques et périls". Un tel langage ne rebute pas le type de développeurs dont vous avez besoin à cette étape. De même, du coté des utilisateurs, il n'y a rien de pire que de les attirer avant que le logiciel soit prêt pour eux. Une réputation d'instabilité est très difficile à rattraper une fois acquise. L'humilité paye sur le long terme : il est toujours préférable pour un logiciel d'être plus que moins stable qu'attendu et les bonnes surprises assurent le bouche à oreille.
Le logiciel devrait être distribué en code source dans un format standard. Lorsqu'un projet démarre, les distributions de binaires (exécutables) ne sont pas obligatoires à moins que le projet possède tant de dépendances ou de pré-requis de compilation que le faire fonctionner nécessite un effort considérable. (Mais dans ce cas, le projet aura des problèmes à recruter des développeurs de toute manière !)
La procédure d'installation doit être aussi simple, standard et peu économe en ressource que possible. Si vous tentez d'éradiquer une maladie, vous ne distribueriez pas le médicament de façon à qu'il nécessite une seringue de taille non standard pour être administré. De la même façon, les logiciels doivent se conformer à des standards de construction et d'installation; plus ils dévient du standard, plus d'utilisateurs et de développeurs abandonnent, perplexes.
Cela semble évident mais beaucoup de projets ne daignent standardiser leur procédure d'installation que très tard dans le projet, se disant qu'ils auront l'occasion de le faire à tout moment: "Nous verrons l'empaquetage lorsque le code sera mieux fini". Ce qu'ils ne réalisent pas est qu'en mettant de coté ce travail rébarbatif, ils allongent en réalité la phase de réalisation du code, parce qu'il découragent les développeurs qui -sinon- y auraient contribué. De façon plus insidieuse, ils ne savent pas qu'ils perdent tous ces développeurs car il s'agit d'une accumulation de non-événements : quelqu'un visite le site Web du projet, télécharge le logiciel, tente de le compiler, échoue dans cette entreprise et s'en va. Qui saura que cela s'est produit, excepté la personne elle-même ? Personne du projet ne réalisera que cette motivation et cette compétence a été gaspillée.
Le travail ennuyeux avec un bon retour sur investissement devrait toujours être réalisé tôt pour abaisser suffisamment la barrière d'accès au projet.
Lorsque vous publiez une version téléchargeable, il est vital de lui donner un numéro de version unique pour que les gens puissent comparer deux versions et savoir immédiatement laquelle précède l'autre. La numérotation de version est discutées au paragraphe la section intitulée « Release Numbering », et les détails de la standardisation des procédures de compilation et d'installation sont détaillés dans la section intitulée « Packaging » et Chapitre 7, Packaging, Releasing, and Daily Development.
Télécharger les distribution de sources est satisfaisant pour simplement installer et utiliser le logiciel, mais n'est pas suffisant pour déboguer ou ajouter de nouvelles fonctionnalités. Les extractions de sources journalières sont utiles, mais pas d'une fréquence adéquate pour favoriser l'émergence d'une communauté de développeurs. Les gens ont besoin d'accéder en temps réel aux sources dans leur état courant et le moyen de leur offrir ce service est d'utiliser un système de Gestion de Configuration Logicielle (GCL). Le fait de fournir un accès anonyme aux sources en GCL est un signe -à la fois dirigé vers les utilisateurs et vers les développeurs- que ce projet fait un effort particulier pour fournir aux gens ce dont ils ont besoin pour participer. Même si vous ne pouvez proposer la GCL tout de suite, laissez une indication que vous allez le faire sous peu. L'infrastructure de gestion de configuration logicielle est développée en détail dans la section intitulée « Les logiciels de gestion de versions » du Chapitre 3, L'infrastructure technique.
Il en va de même de la gestion de tickets. Son importance ne réside pas seulement dans son utilité pour les développeurs mais également pour les observateurs du projet. Pour beaucoup, la mise à disposition d'une base de donnée d'incidents est l'un des indicateurs les plus forts du sérieux d'un projet. D'ailleurs, la qualité apparente d'un projet est directement proportionnelle au nombre de tickets saisis. Ceci peut semble contradictoire mais gardez à l'esprit que le nombre de bogues dépend de trois choses : le nombre absolu de bogues inclus dans le logiciel, le nombre d'utilisateurs du logiciel, et la facilité avec laquelle les utilisateurs peuvent reporter leurs incidents. Sur ces trois facteurs, les deux derniers sont les plus significatifs. Tout logiciel d'une certaine taille et complexité contient un nombre indéterminé de bogues attendant d'être découverts. La vraie question est de savoir comment le projet gère l'enregistrement et la priorisation de ces tickets. Un projet avec une base d'incidents importante et correctement gérée (les bogues sont pris en compte rapidement, les doublons sont identifiés, etc..) donne une meilleure impression qu'un projet dénué de gestion de tickets ou doté d'une base de donnée quasiment vide.
Bien entendu, votre projet contiendra au départ peu de bogues, et il n'y a pas à s'en inquiéter. Si la page de statut met l'accent sur la jeunesse du projet et que les gens observant la base de bogues constatent que la plupart des incidents sont récents, ils pourront en conclure que le projet possède un bon niveau d'enregistrement de tickets et ne seront pas excessivement alarmés par le faible nombre absolu de tickets enregistrés.
Notez que les outils de gestion de ticket ne sont pas seulement utilisés pour suivre les incidents mais également les demandes de fonctionnalités, les évolutions de la documentation et bien d'autres choses encore. Nous ne détaillons pas davantage la gestion de ticket car ce point est développé dans la section intitulée « Bug Tracker » du Chapitre 3, L'infrastructure technique. Du point de vue de la présentation du projet, l'important est de posséder un outil de gestion de tickets et de s'assurer que ce fait est visible dès la page de garde du site Web.
Les visiteurs apprécient de savoir comment joindre les personnes responsables du projet. Fournissez les adresses des listes de diffusion, des chambres de discussion (chat), les canaux IRC et autres forums où les personnes liées au projet sont accessibles. Précisez clairement que vous et les autres auteurs du projet sont inscrits sur ces listes de diffusion afin que les utilisateurs constatent qu'il existe un moyen simple de contacter les développeurs. Notez que votre présence sur les listes n'implique pas de répondre à toutes les questions ou d'implémenter toutes les demandes de fonctionnalités. Sur le long terme, la plupart des utilisateurs n'utiliseront pas ces canaux de toute manière, mais ils seront rassurés de savoir qu'il pourraient le faire en cas de besoin.
Dans les prémisses du projet, il n'y a pas de besoin à séparer les forums utilisateurs et développeurs. Il est nettement préférable que ces deux populations se parlent l'une à l'autre, dans une seule "pièce". Parmi les utilisateurs de la première heure, la distinction est floue entre développeurs et utilisateurs. Le ratio développeurs sur utilisateurs est en général bien plus élevé à cette étape que plus tard dans le projet. Bien que vous ne puissiez compter chaque utilisateur comme quelqu'un désirant travailler sur votre projet, vous pouvez estimer qu'une bonne partie est intéressée pour suivre les discussions sur le développement comme moyen de saisir la direction du projet.
Ce chapitre traitant seulement à ce stade de la façon de démarrer un projet, il est suffisant de dire que ces canaux de communications doivent exister. Plus loin, dans la section intitulée « Handling Growth » du Chapitre 6, Communications, nous étudierons comment où et comment monter de tels forums, les façon de les gérer ou de les modérer, et comment séparer les forums utilisateurs et développeurs, lorsque le temps est venu, et sans créer un fossé infranchissable.
Quelqu'un cherchant à contribuer au projet commencera par rechercher le guide du développeur. Ces guides sont davantage sociaux que techniques : ils expliquent comment les développeurs interagissent les uns avec les autres et avec les utilisateurs, et au final comment les choses se font.
Ce sujet est couvert en détail dans la section intitulée « Writing It All Down » du Chapitre 4, Social and Political Infrastructure, mais le contenu général du guide du développeur est le suivant :
des pointeurs vers les forums pour interagir avec les autres développeurs
des instructions sur la façon de reporter des bogues et soumettre des patchs
des indications sur le fonctionnement du projet- est-ce une dictature bienveillante ? Une démocratie ? Quelque chose d'autre ?
A propos, il n'y a pas de sous-entendu péjoratif au mot "dictature". C'est tout à fait acceptable de fonctionner en mode tyrannie où un développeur particulier a un droit de veto sur toute modification. Beaucoup de projets fonctionnent de cette manière avec succès. L'important est que le projet l'exprime clairement et au grand jour. Une tyrannie prétendant être une démocratie fera fuir les gens ; une dictature se présentant comme telle fonctionnera bien aussi longtemps que le dictateur est compétent et possède la confiance de l'équipe.
Voir http://subversion.apache.org/docs/community-guide/ pour un exemple de guide du développeur particulièrement exhaustif, ou http://www.openoffice.org/dev_docs/guidelines.html pour un exemple de guide plus large se concentrant d'avantage sur la gouvernance et l'esprit du projet et moins sur les considérations techniques.
Le sujet distinct de fournir une introduction à la programmation du logiciel est discutée dans la section intitulée « La documentation développeurs » plus loin dans ce chapitre.
La documentation est essentielle. Il doit exister quelque chose même si c'est rudimentaire et incomplet. C'est encore une tâche à classer dans la catégorie "déplaisant" déjà évoquée plus tôt et qui est souvent le premier écueil pour les projets libres. Définir des finalités et une liste de fonctionnalités, choisir une licence, synthétiser un statut d'avancement - tout ceci constituent des tâches plutôt légères et souvent faites une fois pour toutes. La documentation, de son coté, n'est jamais réellement achevée et c'est peut être la raison pour laquelle les gens rechignent quelque fois à son écriture.
L'effet le plus insidieux est que l'usage de celui qui écrit la documentation est l'exact inverse de celui qui la consulte. Le contenu documentaire le plus important pour les utilisateurs initiaux comprend les choses les plus élémentaires : comment installer rapidement le logiciel, un aperçu de la façon dont il fonctionne et, peut être, des guides pour réaliser les tâches les plus courantes. C'est précisément les éléments que les auteurs connaissent parfaitement, si bien qu'il est très difficile pour eux d'acquérir le point de vue des utilisateurs, puis de détailler laborieusement des étapes leur semblant évidentes au point d'être inutiles à mentionner.
Il n'existe pas de solution toute prête à ce problème. Quelqu'un doit simplement s'asseoir et démarrer quelque chose, puis de le faire lire par des utilisateurs lambda pour tester sa qualité. Utilisez un format simple, facile à éditer comme le HTML, le texte brut, Textinfo ou des variantes de XML : quelque chose de léger et permettant des mises à jours rapides et au fil de l'eau. Ce critère ne concerne pas seulement la productivité de l'auteur original mais également à long terme de ceux qui joindront le projet plus tard et qui désireront maintenir cette documentation.
Une façon simple de s'assurer que la documentation initiale sera réalisée est de limiter son périmètre à l'avance. Un bon moyen de le déterminer est de s'assurer qu'il respecte les critères minimaux suivants:
Dire clairement au lecteur quelle expertise technique il est sensé avoir.
Décrire simplement et de façon exhaustive la procédure d'installation du logiciel, et fournir assez tôt dans le manuel un diagnostique d'auto-contrôle ou une simple commande pour confirmer que tout est correctement configuré. La documentation de prise en main est d'une certaine façon plus importante que le guide d'utilisation complet. Plus un utilisateur consent d'efforts à installer et démarrer le logiciel, plus il persistera à faire marcher les fonctionnalités avancées qui sont moins bien documentée. Lorsque les gens abandonnent, ils le font tôt, il faut donc concentrer les efforts de support aux phases de démarrage.
Donner un style tutoriel à la description des tâches courantes. Bien entendu, plusieurs exemples pour plusieurs taches serait préférable, mais votre temps est probablement limité. Sélectionnez une tache et décrivez là de façon exhaustive. Une fois que quelque le logiciel peut être utilisé pour une tâche, les utilisateurs commenceront à explorer les autres de façon autonome, et - si vous êtes chanceux - commenceront à alimenter la documentation par eux-même. Ce qui nous conduit au point suivant...
Notifiez les endroits où la documentation est incomplète. En montrant au lecteur que vous êtes conscient des manques, vous vous alignez sur son point de vue. Votre empathie rassure les utilisateurs sur le fait que qu'il n'auront pas à lutter pour convaincre de l'importance de cette tâche. Ces notifications ne sont pas un engagement à les remplir à une date donnée, il faut plutôt les considérer comme des demandes ouvertes aux volontaires.
Le dernier point est fondamental et peut s'appliquer au projet dans sa globalité et pas seulement la documentation. Une énumération détaillée des problèmes connus est la norme dans le monde du libre. Nul besoin d'exagérer les défauts du projet, il s'agit simplement de les identifier scrupuleusement et dépassionné lorsque le contexte le requiert (par exemple dans la documentation, l'outil de gestion de tickets ou sur une liste de diffusion). Personne ne le prendra comme du défaitisme ni comme un engagement à résoudre les problèmes à une date butoir, sauf si le projet l'exprime explicitement. Puisque tous les utilisateurs peuvent découvrir des incident par eux-même, il est nettement préférable pour eux d'être préparés psychologiquement : ainsi le projet donnera une image de bonne gestion.
La documentation doit être accessible de deux endroits : en ligne (directement depuis le site Web), mais également dans la distribution téléchargeable du logiciel (voir la section intitulée « Packaging » du Chapitre 7, Packaging, Releasing, and Daily Development). Elle doit être en ligne, sous un format navigationnel, car les gens lisent souvent la documentation avant de télécharger l'applicatif, celle-ci leur permettant de décider ou non de l'utiliser. Mais elle soit aussi accompagner le logiciel en partant du principe que son téléchargement doit fournir (c'est à dire localement) tout ce qui est utile à son utilisation ultérieure.
En ce qui concerne la documentation en ligne, veillez à fournir un lien qui affiche la documentation entière dans une unique page HTML (apposez une note comme "monolithique", "tout en un" ou "page unique" à coté du lien pour que les gens ne soient pas étonnés de la durée du chargement). Cette façon de faire est utile, en particulier pour réaliser des recherches d'un mot ou d'une phrase spécifique dans l'ensemble de la documentation. Les gens savent souvent ce qu'ils cherchent mais pas la section à consulter. Pour de tels utilisateurs, rien de plus frustrant que de tomber sur une page HTML de table des matières, puis une page d'introduction, d'installation et ainsi de suite. Lorsque la documentation est ainsi découpée, la fonction recherche de leur navigateur est inutile. Le style page par page est utile pour ceux qui connaissent à l'avance la section désirée ou qui parcours la documentation de A à Z séquentiellement, mais ce n'est pas la façon la plus courante d'y accéder. De façon bien plus fréquente, quelqu'un de familiarisé avec le logiciel revient pour chercher un mot ou une phrase spécifique. Ne pas leur fournir une telle possibilité leur rend la vie plus difficile.
La documentation développeurs est écrite pour aider les programmeurs à comprendre le code, de façon à l'étendre ou à le réparer. Elle est distincte du guide du développeur discuté plus tôt et qui est davantage social que technique. Le guide du développeur précise comment les programmeurs travaillent ensemble alors que la documentation développeur explicite comment ils travaillent avec le code en tant que tel. Les deux sont souvent réunis en un seul pour des raisons de facilité (comme l'exemple donné plus tôt), mais ce n'est pas une obligation.
Cette documentation étant très utile, il n'y a pas de raison de la différer à une version donnée. Il est suffisant pour démarrer que les auteurs originaux soient disponibles et désirent répondre aux questions sur le code. En fait, avoir à répondre encore et encore aux mêmes questions est la motivation la plus courante pour écrire la documentation. Mais même avant sa rédaction, des contributeurs déterminés peuvent se contenter du code. La force qui conduit les gens à passer du temps à comprendre du code est le fait que ce code produit quelque chose d'utile pour eux. S'ils ont foi dans cette utilité, ils prendront le temps de comprendre le fonctionnement du code; et inversement, s'ils ne l'ont pas, aucune quantité de documentation ne sera suffisante pour les retenir.
Ainsi, si vous n'avez le temps d'écrire de la documentation que pour une population, écrivez là pour les utilisateurs. Toute documentation utilisateur est également une documentation développeur : tout programmeur prévoyant de travailler sur un logiciel doit préalablement l'avoir pris en main. Ensuite, lorsque vous observez que les programmeurs posent régulièrement les mêmes questions, prenez le temps d'écrire des documents leur étant dédiés.
Certains projets utilisent des wikis pour leur documentation initiale, voire leur documentation principale. Selon mon expérience, ceci ne fonctionne vraiment que si le wiki est activement édité par un groupe restreint de personnes qui s'accordent sur la façon d'organiser la documentation et sur un sorte de "ton" qu'elle doit avoir. Voir la section intitulée « Wikis » du Chapitre 3, L'infrastructure technique pour plus d'information.
Si le projet propose une interface graphique ou produit un artéfact distinctif, mettez en avant des exemples sur le site Web du projet. Dans le cas d'une IHM, il s'agit de captures d'écrans; pour les artéfacts, il peut s'agir également de captures d'écrans ou de fichiers bruts. Dans les deux cas, vous assurez une gratification instantanée : une simple capture d'écran est plus convaincante que des paragraphes de description ou de bavardages sur les listes de diffusion, car une capture d'écran est la preuve sans ambiguïté que le logiciel fonctionne. Il peut être bogué, difficile à installer, être insuffisamment documenté, mais cette capture est la preuve qu'il est possible de le faire fonctionner, à condition d'y mettre un effort suffisant.
Il y a bien d'autres choses que vous pouvez mettre sur le site Web de votre projet, si vous en avez le temps, ou si pour une raison une autre, c'est particulièrement approprié : une page de nouvelles, une page d'historique, une page de liens vers des sites associés, une fonction de recherche dans le site, un lien de donation, etc. Aucune n'est impérative au démarrage, mais gardez les en tête pour l'avenir.
Certains sites proposent un hébergement gratuit et une infrastructure pour les projets libres : une zone Web, un outil de gestion de configuration logiciel, un outil de gestion de ticket, des référentiels de téléchargement, des forums de discussion, des sauvegardes automatiques, etc. Les détails varient d'un site à l'autre, mais les mêmes services de base sont offerts par tous. En utilisant l'un de ces sites, vous obtiendrez beaucoup gratuitement, mais vous perdrez, bien entendu, le contrôle fin sur l'expérience utilisateur. La forge décide quelle logiciel le site utilise, et peut contrôler ou au moins influencer l'aspect des pages Web.
Voir la section intitulée « Canned Hosting » du Chapitre 3, L'infrastructure technique pour plus de détail sur les avantages et inconvénients des forges, ainsi qu'une liste des sites qui offrent ces services.