Genèse d'un projet

Genèse d'un projet 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 )

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 (), à 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... Observez d'abord 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) : . 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. Revue de paquetage 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. Choisir un nom adéquat 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 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 à et . 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 ), 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. Fixer des finalités claires 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. Préciser que le projet est libre 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 plus loin dans ce chapitre, et les questions de licences sont discutées en détail dans le . 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. Lister les fonctionnalités et pré-requis 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. Informer sur le statut de développement 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. Alpha et Bêta Le terme alpha désigne en général une première version avec laquelle les utilisateurs peuvent travailler et qui possède déjà toutes les fonctionnalités attendues, mais qui possède des bogues connus. L'utilité principale de livrer un logiciel en alpha est de générer des retours de telle façon que les développeurs sachent sur quoi travailler. L'état suivant, bêta, désigne un logiciel dont tous les bogues sérieux ont été corrigés mais qui n'a pas encore été testé suffisamment pour devenir une version validée. L'objectif de publier une version bêta est soit de devenir la version finale, si aucun nouveau bogue n'est détecté, soit de fournir des retours précis aux développeurs pour qu'il puisse atteindre la version finale rapidement. La différence entre alpha et bêta est souvent à l'appréciation des projets. Téléchargements 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 , et les détails de la standardisation des procédures de compilation et d'installation sont détaillés dans et . La gestion de configuration logicielle et les systèmes de gestion de tickets 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 du . 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 du . 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 canaux de communication 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 du , 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. Le guide du développeur 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 du , 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 pour un exemple de guide du développeur particulièrement exhaustif, ou 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 plus loin dans ce chapitre. La documentation 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. Maintenir une FAQ Une FAQ ("Foire Aux Questions" ou "Frequently Asked Questions" en anglais) est probablement l'un des meilleurs investissements en terme de retour sur investissement dans le domaine de la documentation. Les FAQs reflètent les questions que les utilisateurs et développeurs se posent réellement - à l'opposé des questions que vous pouvez supposer qu'ils se posent - et ainsi, une FAQ correctement gérée tend à fournir à ceux qui la consulte l'information exacte qu'ils recherchent. Une FAQ est en général le premier endroit consulté en cas de problème, avant même le manuel officiel, et c'est probablement le document qui a le plus de chance d'être référencé depuis les autres sites. Malheureusement, il est impossible de produire une FAQ au début d'un projet. Les bonnes FAQ ne s'écrivent pas, elles croissent naturellement. Elles sont par définition des documents réactifs, évoluant en réponse à l'usage au jour le jour du logiciel. Comme il est impossible d'anticiper correctement les questions des utilisateurs, il est également impossible de s'assoir et d'écrire une FAQ de zéro. Pour cette raison, ne gaspillez pas votre temps à tenter de le faire. Vous pouvez néanmoins trouver utile de mettre en place un canevas vierge, de façon à signifier qu'il existe un emplacement par défaut où les gens peuvent contribuer aux questions et aux réponses une fois le projet en route. A ce stade, le plus important n'est pas sa complétude, mais sa facilité d'utilisation : une FAQ facile à alimenter sera alimentée. (La maintenance d'une FAQ est un problème non trivial et curieux, elle est développée plus en avant dans du .) Mise à disposition de la documentation 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 du ). 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 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 du pour plus d'information. Échantillons et captures d'écrans 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. Les captures d'écran La réalisation de captures d'écran pouvant se révéler décourageante avant d'avoir un peu de pratique, voici quelques instructions pour les produire. Utilisez le logiciel The Gimp, ouvrez Fichier->Acquisition->Capture d'écran, sélectionnez Fenêtre simple ou écran complet , puis cliquez sur OK. A partir de ce moment, The Gimp capturera la fenêtre sélectionnée ou l'écran complet au prochain clic de souris. Rognez ou redimensionnez l'image si nécessaire en utilisant les instructions à . 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. Hébergement sur une forge 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 du pour plus de détail sur les avantages et inconvénients des forges, ainsi qu'une liste des sites qui offrent ces services. Choisir une licence et la mettre en oeuvre Ce paragraphe est un guide très court et basique sur le choix d'une licence. Consultez pour saisir les implications légales des différentes licences et l'impact qu'une licence peut avoir pour fusionner votre logiciel avec du code issue d'autres projets. Il existe de nombreuses licences pouvant être choisies. La plupart, que nous omettrons, ne seraient probablement pas appropriées à votre projet, couvrant des besoins spécifiques de sociétés ou individus . Nous nous restreindrons simplement aux licences les plus courantes, étant fort probable que l'une d'entre elle vous conviendra. Les licences "Faites ce que vous voulez" Si vous ne voyez pas d'objections à ce que votre code soit potentiellement utilisé dans les logiciels propriétaires, utilisez une licence MIT/X ou dérivées. Il s'agit de la plus simple de plusieurs licences minimalistes qui n'apporte pas grand chose de plus que la mention du copyright (sans restriction du droit de copie) et la spécification explicite que le produit est utilisé sans garantie d'aucune sorte. Voir pour plus de détail. La GPL Si vous ne désirez pas que votre code puisse être utilisé dans des programmes propriétaires, utilisez la GNU General Public License (). La GPL est assurément la licence libre la plus largement reconnue dans le monde actuellement. C'est un net avantage, puisque les utilisateurs et contributeurs y sont familiarisés, et ne dépenseront donc pas de temps supplémentaire à lire et comprendre votre licence. Voir du pour davantage de précisions. Comment mettre en oeuvre cette licence au projet Une fois la licence choisie, vous devez la préciser sur la page Web de garde du projet. Nul besoin d'inclure le texte de la licence à cet endroit; fournissez simplement le nom de la licence, et prévoyez un lien vers la licence complète située sur une autre page. Vous explicitez ainsi quelle licence vous prévoyez d'utiliser pour le logiciel, mais c'est insuffisant en terme juridique. Le logiciel lui même doit en effet contenir la licence. La façon standard de le mettre en oeuvre et d'incorporer un fichier texte de licence nommé COPYING (ou LICENSE), et d'ajouter une courte notice dans l'entête de chaque fichier source, fournissant la date du copyright, le détenteur, la licence et pour finir l'endroit ou le texte complet de la licence peut être obtenu. Il y a bien des variantes possibles, nous fournissons donc un unique exemple ici. La licence GNU GPL requiert d'ajouter une telle notice en entête de chaque fichier source : Copyright (C) <année> <nom de l'auteur> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Cette notice ne spécifie pas explicitement que la copie de la licence que l'utilisateur reçoit avec le logiciel se trouve dans le fichier COPYING, mais c'est en général l'endroit utilisé (vous pouvez modifier l'entête pour le spécifier directement). Elle fournit également une adresse géographique à partir de laquelle demander une copie de la licence. Une autre méthode commune est de fournir un lien vers une page Web comprenant le texte de la licence. Utilisez simplement votre jugement et pointez vers l'endroit le plus adéquat pour obtenir une copie de façon permanente, ce qui peut être n'importe où sur votre site Web. En général, la notice que vous utilisez n'aura pas exactement le contenu de l'exemple plus haut. L'important est d'y faire figurer les données obligatoires : détenteur du copyright, date, nom de la licence et moyen d'accès au texte de la licence. Donner le ton Jusqu'ici, nous avons décrit des tâches réalisées à un moment précis de la mise en place du projet : choisir une licence, concevoir le site Web initial, etc. Mais les aspects les plus importants dans le démarrage d'un projet sont dynamiques. Choisir une adresse de liste de diffusion est facile ; s'assurer que les conversations sur cette liste ne dérivent pas et restent productives est une problématique complètement différente. Si le projet est ouvert au monde après des années de développement propriétaire fermé, son processus de développement va changer, et vous aurez à préparer les développeurs actuels à ce changement. Les premiers pas sont les plus difficiles, car le projet manque de décisions prises et de reflèxes. La stabilité d'un projet ne vient pas seulement de règles formalisées, mais d'une atmosphère collective difficile à saisir et qui se développe au cours du temps. On trouve souvent des règles écrites, mais elles se bornent souvent à une distillation de préconisations tacites, évoluant régulièrement et servant de guide effectif au projet. Les règlements écrits définissent moins la culture du projet qu'ils la décrivent, et encore souvent de façon approximative. Il y a plusieurs raisons à cela. Les embauches et les hauts niveau de rotation en entreprise ne sont pas si dommageables pour les normes sociales qu'on pourrait le penser au premier abord. A partir du moment où les changements ne sont pas trop rapides, il y a toujours des périodes de recouvrement dans lesquelles les nouveaux arrivés apprennent les méthodologies, puis les mette en pratique eux mêmes. Voyez comment les comptines d'enfants passent les siècles. Les enfants d'aujourd'hui chantent à peu près les mêmes refrains que d'autres enfants il y des siècles, bien qu'aucun ne soit encore vivant. Les enfants les plus jeunes entendent chanter leurs camarades plus âgés, puis les chantent à leur tour. Les enfants ne sont pas engagés dans un programme conscient de transmission, évidemment, mais la raison pour laquelle les chansons survivent est assurément le fait qu'elles sont transmises régulièrement et de façon répétitive. L'échelle de temps des logiciels libres ne peut être mesuré en siècles (nous le saurons un jour), mais les dynamiques de transmission sont globalement les mêmes. Le niveau de rotation est néanmoins plus élevé, et doit se voir compensé par un effort de transmission plus actif et délibéré. Cet effort est soutenu par le fait que les gens attendent et recherchent naturellement les normes sociales. C'est la façon dont les humains fonctionnent. Dans tout groupe unit par une cause commune, les gens recherchent instinctivement des comportements qui leur permettrait de se voir identifiés comme membre du groupe. Le but des guides est d'amorcer des comportements de groupe utiles au projet. Une fois mis en place, ils se perpétuerons seuls le plus souvent. Vous trouverez dans ce qui suit des exemples spécifiques de ce qu'il est possible de faire pour prendre les bonnes décisions. Cette liste n'a pas pour ambition l'exhaustivité mais simplement de montrer qu'une ambiance collaborative aide rapidement et considérablement un projet. Chaque développeur peut travailler seul, mais vous pouvez faire en sorte qu'ils aient le sentiment de travailler en équipe, dans la même pièce. Plus les développeurs le ressentiront, plus ils passeront de temps sur le projet. Je choisi ces exemples particuliers qui apparurent dans le projet Subversion (), pour lequel j'ai participé et que j'ai observé depuis le tout début. Ils ne sont pas spécifiques à Subversion; de telles situations sont communes dans les projets libres, et doivent être considérés comme des opportunités de démarrer les choses du bon pied. Évitez les discussions privées Même après avoir rendu le projet publique, vous et les autres fondateurs serez souvent tentés de résoudre les questions complexes en petit comité via un canal privé. C'est spécialement vrai au début du projet, alors qu'il y a tant de décisions importantes à prendre et, en général, si peu de volontaires qualifiés pour les prendre. Tous les inconvénients évidents des listes de discussion publiques vont alors apparaître de façon très palpable : le délai inhérent aux conversations par courriel, le besoin de réserver suffisamment de temps pour qu'un consensus se forme, l'embarras à devoir répondre aux volontaires naïfs qui pense comprendre tous les problèmes mais qui ne les comprennent pas (tous les projets ont ce genre de personnes ; quelques fois elles sont les contributeurs stars de l'année d'après, quelque fois ils restent naïfs ); ceux qui ne comprennent pas que vous désirez seulement résoudre le problème X alors qu'il leur semble évident que ce problème est un sous-ensemble d'un problème Y, et ainsi de suite. La tentation de prendre des décisions toutes portes fermées et de les présenter comme faits accomplis, ou au moins comme de fermes recommandations d'un groupe de votants uni et influent, est en effet très grande. Ne le faites pas. Aussi longues et lourdes que ces discussions publiques puissent paraître, elles sont presque toujours préférable sur le long terme. Prendre d'importantes décisions en privé est comme utiliser un repoussoir à contributeurs sur votre projet. Aucun volontaire sérieux ne restera dans un environnement ou un conseil secret prend toutes les décisions importantes. En outre, les discussions privées ont des effets de bord bénéfiques en plus de la simple résolution d'un éphémère problème technique : La discussion aide à former les nouveaux développeurs. Vous ne savez jamais combien d'yeux suivent la conversation ; même si la plupart des gens n'y participent pas, beaucoup peuvent la suivre silencieusement, glanant des informations sur le logiciel. La discussion vous entraîne aussi dans l'art d'expliquer des problèmes techniques aux gens qui ne sont pas encore autant familiarisés avec le logiciel que vous l'êtes. Il s'agit d'une compétence qui requiert de la pratique, et vous ne pouvez obtenir cette compétence en parlant seulement avec les gens qui en savent déjà autant que vous. La discussion et ses conclusions seront disponibles dans les archives publiques pour toujours, rendant possible de démarrer de nouvelles discussions sans partir de zéro. Voir du . Enfin, il faut mettre dans la balance la possibilité que quelqu'un sur la liste fasse une réelle contribution à la conversation. C'est difficile de dire si c'est probable, tout dépend de la complexité du code et du degré de spécialisation requis. Mais, si vous permettez l'anecdote, je suppute que c'est plus probable qu'on peut le penser intuitivement. Sur le projet Subversion, nous (les fondateurs) étions en face de ce que nous croyions être un ensemble de problèmes complexes et profonds, sur lesquels nous avions réfléchi dur depuis des mois, et nous doutions franchement que quelqu'un sur la nouvelle liste de diffusion puisse apporter une contribution utile à la discussion. Alors, nous avons emprunté la voie de la facilité et nous avons commencé à batailler sur des idées techniques via des courriels privés, jusqu'à ce qu'un observateur du projet Nous n'avons pas encore abordé le sujet des crédits, mais simplement pour appliquer à moi-même ce que je prêche plus tard : le nom de l'observateur était Brian Behlendorf, et ce fut lui qui pointa l'importance général de conserver toutes les discussions publiques à moins qu'il y ait un besoin explicite de confidentialité. présenti ce qui ce passait et demanda que la discussion soit déplacée sur la liste publique. Nous le fîmes, un peu à reculons il est vrai, et nous furent sidérés par le nombre de commentaires pertinents et par les suggestions qui en ont résultées. Dans de nombreux cas, les gens apportèrent des idées qui ne nous étaient jamais venues à l'esprit. Il apparut qu'il y avait des gens très pointus sur cette liste ; ils étaient simplement à attendre le bon appât. Il est vrai que les discussions qui ont suivies prirent plus de temps que si la conversation était restée privée, mais elles furent tellement plus productives que cela justifiait largement cette rallonge. Sans descendre aux généralités telle que "le groupe est toujours meilleur que l'individu" (nous avons tous rencontré suffisamment de groupes pour le savoir), nous pouvons mettre l'accent sur le fait que les groupes excellent vraiment dans certaines activités. La revue par pair massive est une ; générer un grand nombre d'idées en est une autre. La qualité des idées dépend de la qualité intellectuelle des contributeurs, bien entendu, mais vous ne connaissez pas le type de penseurs auquel vous vous adressez avant de les avoir stimulés avec un problème coriace. Bien sûr, certains discussions doivent rester privées, ce livre en donnera des exemples. Mais le principe directeur devrait être : s'il n'y a pas de vrai raison pour que ce soit privé, ça doit être publique. Y arriver requiert des actions effectives. Il n'est pas suffisant de s'assurer que vos propres messages vont dans une liste publique, vous devez aussi guider les conversations inutilement privées des autres vers la liste. Si quelqu'un démarre une discussion privée, et qu'il n'y aucune raison que cette discussion reste privée, c'est à vous d'ouvrir une méta-discussion immédiatement sur la liste. Ne commentez même pas le sujet initial tant que vous n'avez pas déplacé la conversation dans un endroit publique, à moins de vous assurer que la confidentialité est requise. Si vous procédez de la sorte sur le long terme, les gens saisiront le message assez rapidement et utiliseront la liste publique par défaut. Tuez l'agressivité dans l'oeuf Vous devez assurer une politique de tolérance zéro contre les comportements agressifs ou insultants, et ce dès les tous premiers message de la liste publique du projet. La tolérance zéro ne signifie pas de prendre des mesures automatiques. Vous n'avez pas, par exemple, à supprimer quelqu'un de la liste de diffusion quand il attaque un autre contributeur, ou de lui enlever le droit de commit parce qu'il a tenu des propos déplacés (en théorie, vous pouvez éventuellement en arriver là, mais seulement après que tous les autres moyens aient échoués -ce qui n'est pas le cas, par définition, lorsque le projet démarre). La tolérance zéro signifie simplement qu'aucun mauvais comportement ne demeurera sans réponse. Par exemple, si quelqu'un envoi un message mélangeant un commentaire technique avec une attaque ad hominem envers un autre développeur du projet, il est impératif que vous répondiez à l'attaque ad hominem en premier et dans une question spécifique, et seulement après à la question technique. Il est malheureusement très facile, et régulier, que les discussions constructives dérivent en de véritables pugilats. Les gens ont tendance à dire par courriel ce qu'il ne diraient jamais face à face. Le sujet de discussion amplifie seulement cet effet : dans un débat technique, les gens pensent souvent qu'il n'y a qu'une bonne réponse à une question donnée, et que tout désaccord avec cette réponse peut seulement s'expliquer par l'ignorance ou la stupidité de celui qui l'exprime. Il n'y a qu'un pas entre qualifier de stupide la proposition technique de quelqu'un et le qualifier de stupide lui-même. Il est en fait souvent difficile de déterminer ou fini le débat et ou commence l'attaque personnelle ; c'est la raison pour laquelle les réponses drastiques ou les punitions ne sont pas une bonne idée. Lorsque vous pensez que le débat s'envenime, envoyez plutôt un message mettant l'accent sur l'importance de conserver la discussion amicale, sans accuser quiconque d'être délibérément agressif. De tels messages de "bonne conduite" ont néanmoins tendance à sonner comme une leçon de maîtresse de maternelle :

Tout d'abord, veillons à éviter les potentielles attaques ad hominem; par exemple celle de qualifier la conception de la couche sécurité de J. de "naïve et ignorante des principes de base de la sécurité informatique". Ce peut ou non être vrai, mais c'est hors propos. J. a fait cette proposition de bonne foi. Si elle présente des lacunes, analysons les, et nous les corrigerons ou nous proposerons une nouvelle architecture. Je suis persuadé que M. n'avait pas l'intention de blesser J., mais la phrase était maladroite et nous essayons de rester constructifs. Maintenant, sur la proposition en elle-même, je pense que M. avait raison de dire que...

Bien que pompeux, ce style de réponse a un effet non négligeable. Si vous reprenez avec constance les débordements, mais sans demander de faire ou de d'accepter des excuses, vous laisser aux gens la possibilité de garder la tête froide et de montrer leur meilleur jour en se comportant de façon plus appropriée la fois suivante. Un des secrets est de ne jamais faire de cette méta-discussion le sujet principal. Elle doit toujours être traitée séparément, comme préface dans votre réponse. Notifiez en passant que "les choses ne se traitent pas de cette manière ici", mais retombez tout de suite sur le sujet initial pour laisser la possibilité aux gens de répondre quelque chose en rapport. Si quelqu'un proteste qu'il ne mérite pas votre réprimande, refusez simplement de répondre à cette escalade. Vous pouvez soit ne pas répondre (si vous pensez qu'il s'agissait simplement d'un accès d'humeur), soit dire que vous êtes désolé si vous avez réagit trop vivement et qu'il est difficile de percevoir toutes les nuances dans un courriel, puis revenez au sujet principal. N'insistez jamais pour exiger des excuses, que ce soit de façon publique ou privée, de quelqu'un qui s'est mal comporté. C'est une bonne chose s'il décide de son propre chef d'envoyer une excuse, mais en exiger ne cause que du ressentiment. L'étiquette doit être reconnue comme l'un des comportements du groupe. Cela aide le projet car les développeurs peuvent être dissuadés de participer (même des projets sur lesquels ils aimeraient travailler) par les polémiques. Vous pouvez même ne jamais vous en rendre compte; quelqu'un peut scruter la liste, constater qu'il faut être armé d'une cuirasse pour participer au projet, et donc décider de ne pas s'y investir du tout. Garder les forums amicaux est une question de vie ou de mort sur le long terme, et c'est bien plus facile à faire tant que le projet est encore jeune. Une fois que l'étiquette rentre dans les moeurs, vous n'aurez plus à être le seul à la promouvoir, elle le sera par tous. Pratiquez la revue par pairs L'une des meilleurs bonnes pratiques pour favoriser le développement d'une communauté productive est de permettre aux gens d'observer leur code les uns les autres. Un peu d'infrastructure technique est requise pour y arriver, en particulier il faut activer l'envoi de courriels sur commit (voir pour plus de détails). Le but est d'émettre un courriel contenant les annotations et les changements (diff) de chaque commit de code (voir du ). La revue de code est la pratique consistant à consulter ces courriels au fil de l'eau en y recherchant des bogues ou de possibles améliorations. C'est en général de cette façon qu'est réalisée la revue de code dans les projets libres. Dans des projets plus centralisés, cette revue peut également se faire en réunissant plusieurs personnes et en analysant des listings de code source à la recherche de problèmes spécifiques ou de patrons de conception à mettre en place. La revue de code répond simultanément à plusieurs objectifs. Il s'agit de l'exemple le plus évident de revue par pairs dans le monde du libre, et elle aide à assurer un bon niveau de qualité au logiciel. Chaque bogue incorporé dans la version finale l'a été parce qu'il n'a pas été détecté à temps ; ainsi, plus d'yeux observent les commits, plus le nombre de bogues sera limité. Mais ce processus sert aussi un autre but plus indirect : il conforte les gens dans l'idée que ce qu'ils font a de l'importance, puisqu'il est évident que personne ne prendrait le temps de faire une revue s'il ne se souciait de son effet sur le programme. Les gens produisent leur meilleur travail quand ils savent que d'autres l'évalueront. Les revues doivent être publiques. Même lorsque j'ai été assis avec d'autres développeurs dans la même pièce physique, et que l'un d'entre nous avait fait un commit, nous prenions garde à ne pas faire la revue verbalement, mais de l'envoyer plutôt sur la liste. Tout le monde profite de cette revue. Les gens suivent les commentaires et quelque fois y découvrent des erreurs, et même si ce n'est pas le cas, cela leur rappelle que la revue est une activité régulière, comme laver la vaisselle ou tondre la pelouse. Dans le projet Subversion, la revue de code n'a pas été initialement un exercice régulier. Il n'y avait aucune garantie que chaque commit serait revu, même on pouvait consulter une modification si elle se trouvait dans notre champs d'action. Les bogues se glissaient sans difficulté alors qu'ils aurait pu et auraient du être filtrés. Un développeur nommé Greg Stein, qui connaissait la valeur de la revue par pair d'un ancien travail, décida qu'il allait montrer l'exemple en faisant la revue de chaque commit arrivant dans le référentiel. Chaque modification était rapidement suivie d'un courriel de Greg envoyé à la liste développeur dans lequel il disséquait le commit, analysait les problèmes potentiels, et proposait quelque fois un peu de code bien tourné. Instantanément, il attrapa des bogues et des méthodes de programmation non optimales qui autrement auraient glissées sans que personne ne s'en rende compte. Il est à noter qu'il ne s'est jamais plaint d'être le seul à faire ces revues, même s'il y consacrait une quantité de temps importante. Il en chantait simplement les louanges dès qu'il le pouvait. Assez rapidement, d'autres personnes, moi compris, commencèrent à l'imiter. Quelle était notre motivation ? Non pas que Greg avait jeté l'opprobre sur nous, mais il avait prouvé que la revue de code était une façon intelligente de dépenser son temps, et que chacun pouvait contribuer autant au projet en analysant le code des autres qu'en écrivant du code soi-même. Une fois qu'il l'eu démontré, ceci devint le comportement par défaut, au point qu'un commit sans réaction aurait causé de l'angoisse à son émetteur, et qu'il aurait demandé sur la liste si quelqu'un avait déjà pu faire la revue. Plus tard, Greg trouva un travail qui ne lui laissait peu de temps pour Subversion, et du arrêter ses revues régulières, mais cette coutume était si bien enracinée en nous tous qu'elle est toujours activement pratiquée depuis un temps immémorial. Commencez à faire des revues depuis le premier commit. Les types de problèmes les plus faciles à détecter de cette façon sont les vulnérabilités de sécurité, les fuites mémoire, les manques de commentaires ou de documentation d'API, les effets de bord, les erreurs de conception dans la hiérarchie d'appels, et d'autres problèmes qui nécessitent un minimum de recul pour être détectés. Néanmoins, même les problèmes à plus grande échelle comme l'incapacité à mutualiser du code à un seul endroit devient visible à force de revues, parce que le souvenir des revues précédentes renseigne les revues courantes. Ne vous inquiétez pas si vous ne trouver rien à commenter, ou si vous de maîtrisez pas assez toutes les parties du code. Il y aura souvent quelque chose à dire sur tout commit ; même si vous ne trouvez rien à redire, quelque chose peut faire l'objet d'un commentaire admiratif. L'important est de rendre clair le fait que chaque développeur sache que ce qu'il fait est vu et compris. Bien entendu, la revue du code n'absout pas les programmeurs de leur responsabilité à vérifier et à tester leurs modifications avant de commiter; personne ne devrait dépendre de la revue pour détecter des problèmes qu'on aurait dû trouver soit-même. Lorsque vous ouvrez un projet propriétaire, soyez attentif à la gestion du changement Si vous libérez un projet existant, sur lequel travaillent des développeurs actifs et accoutumés à travailler dans un environnement propriétaire, assurez vous que tous comprennent qu'un changement important va en suivre, et de votre coté, vérifiez que vous êtes en mesure de faire face leurs réactions. Représentez vous la situation telle qu'ils la perçoivent : tout le code et les décisions sur la conception sont faites par un groupe de développeurs qui connaissent tous plus ou moins autant le logiciel, qui reçoivent la même pression du même management, et qui connaissent leurs forces et faiblesses respectives. Vous leur demandez soudain d'exposer leur code pour qu'il soit scruté par des étrangers ne formant leur jugement que sur le résultat final, et sans prendre en compte la pression de la hiérarchie qui a pu forcer certaines décisions. Ces étrangers posent de nombreuses questions, des questions qui déstabilisent les développeurs lorsqu'ils réalisent que la documentation sur laquelle il avait tant travaillé est toujours inadéquate (c'est inévitable). Ajoutez le fait que tous ces arrivants sont inconnus et sans visage... Si l'un des développeurs manquait d'assurance, imaginez à quel point ce sentiment se trouvera exacerbé quand des nouveaux contributeurs lui désigneront des faiblesses dans son code, et pire, devant ses collègues. A moins de disposer d'une équipe de développeurs parfaits, c'est inévitable, en fait cela se produira probablement pour tous. Non pas qu'ils soient de mauvais programmeurs, c'est simplement qu'au dessus d'une certaine taille un projet a des bogues et la revue par pairs permettra de les détecter (voir précédemment dans ce chapitre). Dans le même temps, les nouveaux arrivants ne seront pas eux mêmes sujets à la revue par pairs puisqu'ils ne peuvent produire de code tant qu'ils ne sont pas suffisamment familiers du projet. Pour vos développeurs, cela peut être pris comme une situation de critique unilatérale. Il y a donc danger de voir apparaître une mentalité d'assiégés parmi les vétérans. La meilleure façon de l'éviter est de prévenir le groupe de ce qui va arriver. Expliquer lui que l'inconfort initial est parfaitement normal, et rassurez en assurant que les choses iront en s'améliorant. Certains de ces messages peuvent rester privés, avant que le projet ne soit ouvert. Mais vous pouvez également trouver utile d'informer sur la liste publique qu'une nouvelle méthode de développement pour le projet se met en place, et qu'un temps d'adaptation sera nécessaire. La meilleur chose que vous puissiez faire est de piloter par l'exemple. Si vous constatez que vos développeurs ne répondent pas suffisamment aux questions des débutants, leur demander simplement d'y répondre plus ne fera pas avancer les choses. Ils peuvent manquer de discernement entre ce qui nécessite une réponse ou pas, ou ne pas savoir comment prioriser le travail de développement face à la nouvelle charge amenée par cette communication externe. Le moyen de les faire participer est de participer vous mêmes. Soyez sur la mailing liste publique, et répondez y à des questions. Si vous n'avez pas l'expertise pour répondre à une question, désignez clairement un développeur qui la possède, et vérifiez qu'il fournira une solution ou au moins une réponse. Il peut être naturellement tentant sur le long terme de glisser vers des discussion privées, ce qui constituait après tout la situation antérieure. Assurez vous de vous inscrire sur les mailing listes internes sur lesquelles cela peut se produire pour être en mesure de demander à déplacer ces discussions vers la mailing liste publique. Il existe d'autres considérations de long terme à prendre en compte lorsqu'on ouvre un projet propriétaire. explore les techniques de management permettant de faire travailler avec succès contributeurs bénévoles et salariés, et discute de la nécessité d'un travail juridique consciencieux lorsqu'on ouvre une base de code privée qui peut contenir du code écrit ou "détenu" par d'autres tiers. Annoncer le projet Une fois le projet présentable -non pas parfait, simplement présentable- vous êtes prêt à l'annoncer Ubi et orbi. C'est en fait un processus très simple : allez sur , cliquez sur Submit en haut de la barre de navigation, et saisissez un formulaire d'annonce de votre nouveau projet. Freshmeat est l'endroit que tout le monde scrute pour les annonces de nouveaux projets. Veillez simplement à garder un oeil sur ce site pour observer l'évolution du bouche à oreille. Si vous connaissez des listes de diffusion ou des newsgroups pour lesquelles une annonce de votre projet serait pertinente et intéressante, postez y un message, mais soyez attentif à n'envoyer qu'un unique message par forum, et en dirigeant les personnes vers votre propre liste (en fixant l'entête Reply-to à l'adresse de votre propre liste). Les messages doivent être courts et aller droit à l'essentiel : To: discuss@lists.example.org Subject: [ANN] Projet Scanley d'indexeur textuel Reply-to: dev@scanley.org Ceci est un message unique d'annonce de création du projet Scanley, un indexeur textuel libre et un moteur de recherche doté d'une riche API à destination des programmeurs désirant proposer des services de recherche pour de grandes collections de fichiers texte. Scanley fonctionne, est toujours en développement actif, et recherche des développeurs et des testeurs. Site du projet: http://www.scanley.org/ Fonctionnalités : - Recherches texte, HTML et XML - Recherche de mots ou de phrases entières - (prévu) Recherches approchantes - (prévu) Mise à jour incrémentales des index - (prévu) Indexation de sites Web distants Pré-requis : - Python 2.2 ou supérieur - Suffisamment d'espace disque pour les index (approximativement 2 x la taille des données traitées) Pour davantage d'informations, veillez consulter scanley.org. Merci, -J. Random (Voir du pour des conseils sur la façon d'annoncer les versions suivantes et les autres événements du projet.) Il existe actuellement un large débat dans le monde du libre sur la nécessité ou pas de démarrer avec du code fonctionnel, ou si un projet peut bénéficier du fait d'être encore en conception. J'ai longtemps pensé que démarrer avec un code fonctionnel était le plus important facteur de réussite d'un projet, étant ce qui différencie les vrais projets des gadgets, et que des développeurs sérieux ne seraient attirés que car quelque chose de suffisamment concret. Il s'avéra que ce n'est pas le cas. Dans le projet Subversion, nous avons démarré avec un document de conception, un noyau de développeurs intéressés et en contact, beaucoup de tapage, et aucun code fonctionnel. A ma grande surprise, le projet acquis des participants actifs dès son démarrage, et au moment ou nous obtinrent du code fonctionnel, un nombre assez grand de volontaires étaient déjà largement impliqués. Subversion n'est pas le seul exemple ; le projet Mozilla a également été lancé sans code fonctionnel, et a atteint aujourd'hui le statut de navigateur Web très populaire. Face à l'évidence, j'eus à ravaler mes certitudes sur la nécessité absolue de disposer de code fonctionnel pour lancer un projet. Un code fonctionnel est encore la meilleure fondation d'un projet pour son succès, et c'est une bonne règle que d'attendre d'en disposer avant de l'annoncer. Il existe néanmoins des circonstances où le faire en avance est utile. Je pense qu'il faut au moins proposer un document de conception correct, ou un cadre de développement (bien entendu ils pourront être modifiés par des retours des visiteurs) mais il doit y avoir quelque chose de concret, de plus tangible que de simples bonnes intentions, pour que les gens s'y fassent les dents. Une fois que vous avez fait votre annonce, n'attendez pas qu'une horde de volontaires rejoignent immédiatement votre projet. En général, le résultat d'une telle annonce se résume à quelques questions de politesse, quelques inscriptions sur la liste de diffusion, et tout continue à peu près comme avant. Mais sur le long terme, vous noterez une progression constante de la participation à la fois en nouveaux contributeurs de code et d'utilisateurs. Faire l'annonce est seulement planter la graine : il peut falloir un temps considérable pour que la nouvelle croissent et se répande. Si le projet donne constamment en retour à ceux qui s'y investissent, la nouvelle se répandra car les gens aiment partager lorsqu'ils trouvent quelque chose de valable. Si les choses se passent bien, les dynamiques de réseau de type exponentielles transformeront lentement le projet en une communauté complexe, où vous ne connaîtrez pas nécessairement le nom de tous et où vous ne pourrez plus suivre chaque conversation. Le chapitre suivant concerne la façon de travailler dans cet environnement.