De Framalang Wiki.

Chapitre 1 : Introduction

Page d'accueil du projet

Chapitre 3 : Infrastructure technique

---

Sommaire 1 Chapitre 2 : Bien démarrer 1.1 Commencez avec ce que vous avez 1.1.1 Choisissez un bon nom 1.1.2 Définissez clairement vos objectifs 1.1.3 Indiquez que le projet est libre 1.1.4 Liste des fonctionnalités et pré-requis 1.1.5 Avancement du développement 1.1.6 Téléchargements 1.1.7 Gestion de versions et accès au système de suivi de bogues 1.1.8 Les voies de communications 1.1.9 Les directives développeurs 1.1.10 Documentation 1.1.10.1 Disponibilité de la documentation 1.1.10.2 La documentation développeur 1.1.11 Exemples de réalisations et captures d'écran 1.1.12 Forges 1.2 Choisir une licence et l'appliquer 1.2.1 Les licences à « tout faire » 1.2.2 La licence GPL 1.2.3 Comment appliquer une licence à votre logiciel 1.3 Donner le ton 1.3.1 Évitez les discussions privées 1.3.2 Tuez la vulgarité dans l'œuf 1.3.3 Effectuez une inspection visible du code 1.3.4 Soyez attentifs à l'amplitude des changements lorsque vous libérez un projet fermé 1.4 Annoncer

Chapitre 2 : Bien démarrer

Eric Raymond, dans un article maintenant célèbre sur les processus Open Source intitulé « The Cathedral and the Bazaar » [NdT : La cathédrale et le bazar], décrit les étapes classiques du lancement d'un projet de logiciel libre. Il y écrit :

Tout bon logiciel commence par gratter un développeur là où ça le démange.

(d'après http://www.catb.org/~esr/writings/cathedral-bazaar/)

Remarquez que Raymond ne dit pas que les projets Open Source se font seulement quand quelques individus ont une démangeaison. Il dit plutôt que tout bon logiciel est d'abord la réponse à une démangeaison d'un programmeur. La pertinence de ceci dans le monde du logiciel libre est que les besoins personnels sont les motivations les plus fréquentes pour commencer un projet. C'est encore la motivation de base de la plupart des projets libres, mais moins qu'en 1997 quand Raymond a écrit ces mots. Aujourd'hui nous voyons des organisations, y compris des entreprises (dont le but est de faire des profits) commencer à partir de rien de grands projets dont la direction est centralisée. Le programmeur isolé, écrivant des bouts de code pour résoudre un problème précis et réalisant que le résultat obtenu peut être largement étendu, est encore à la base de nombreux nouveaux logiciels libres, mais ce n'est plus la seule version de l'histoire.

L'idée de Raymond est cependant toujours très perspicace. Il faut que les créateurs du programme aient un réel intérêt à le voir aboutir car ils l'utilisent eux même : c'est une condition essentielle. Si le logiciel ne fait pas ce qu'il est supposé faire, la personne ou l'organisation productrice ne sera pas satisfaite dans son travail au quotidien. Par exemple, pour le projet OpenAdapter (http://www.openadapter.org/), lancé par la banque d'investissement Dresdner Kleinwort Wasserstein comme un cadre Open Source pour l'intégration de systèmes d'informations financières disparates, on peut difficilement dire qu'il réponde au besoin particulier d'un quelconque développeur. Il répond au besoin d'une institution. Mais ce dernier est l'expression concrète d'une insatisfaction de l'institution et de ses partenaires. En conséquence, si le programme faillit à sa tâche, ils le sauront. Cette configuration produit de bons logiciels car la boucle de rétroaction mène dans la bonne direction. Le programme n'est pas écrit pour être vendu à quelqu'un afin qu'il puisse résoudre son problème. Il est écrit pour résoudre son propre problème puis être partagé avec tous, un peu comme si le problème était une maladie et le logiciel le médicament dont la distribution est censée éradiquer l'épidémie.

Ce chapitre traite de la présentation au public d'un nouveau projet de logiciel libre, mais de nombreuses recommandations sembleraient familières aux organisations de santé distribuant des médicaments. Les buts sont très similaires : vous voulez expliquer de manière simple ce que le médicament fait, le mettre entre les mains des personnes concernées et vous assurer que ceux qui le reçoivent savent bien l'utiliser. Mais dans le cas des logiciels, vous voulez aussi inciter certains destinataires à rejoindre la recherche en cours pour améliorer le médicament.

La distribution de logiciels libres comporte deux facettes : le logiciel doit trouver des utilisateurs et des développeurs. Ces deux besoins ne sont pas forcément antagonistes même s'ils rendent la présentation initiale du projet plus compliquée. Certaines informations sont utiles aux deux publics, d'autres le sont uniquement à l'un ou à l'autre. Les deux types d'informations devraient répondre au principe de présentation adaptée, ce qui signifie que le degré de détail présenté à chacun devrait correspondre directement à la somme de temps et d'efforts consentis par le lecteur. Un effort plus important devrait toujours être récompensé à sa juste valeur. Quand le retour sur investissement n'est pas satisfaisant, les gens peuvent rapidement perdre la foi et arrêter de s'investir.

Le corollaire de ceci est que les apparences comptent. Les programmeurs, en particulier, sont souvent sceptiques à ce sujet. Leur amour pour le fond plutôt que pour la forme est presque une source de fierté professionnelle. Ce n'est pas un hasard si tant de programmeurs montrent de l'antipathie envers le marketing et les relations publiques, ou si les graphistes de métier sont souvent horrifiés par ce que les développeurs peuvent produire.

C'est très dommage car il existe des situations, et la présentation d'un projet en est une, où la forme fait partie du tout. Par exemple, l'une des premières choses que retient un visiteur à propos d'un projet est l'aspect de son site Web. Cette information est absorbée avant que le vrai contenu du site ne soit compris, avant que le texte ne soit lu ou que le visiteur ne clique sur les liens. Même si cela peut être injuste, les gens ne peuvent s'empêcher de se forger une première impression. L'apparence du site montre l'application apportée à la présentation du projet. Les humains ont des antennes très sensibles pour détecter le souci du détail. La plupart d'entre nous peut dire en un coup d'œil si un site Web a été assemblé à la va vite ou s'il a été mûrement réfléchi. C'est la première information que votre projet montre et l'impression qu'elle crée pèsera sur le reste du projet par association.

En conséquence, alors que ce chapitre du livre porte sur le contenu à la base de votre projet, souvenez-vous que son apparence compte également. Étant donné que le site Web s'adresse à deux types de visiteurs, les utilisateurs et les développeurs, une attention particulière doit être apportée à sa clarté et sa concision. Bien que ça ne soit pas le meilleur endroit pour traiter de la conception d'une page Web, un principe est suffisamment important pour être mentionné ici, particulièrement quand le site s'adresse à plusieurs publics (qui peuvent se chevaucher) : les gens devraient avoir une vague idée de la direction d'un lien avant de cliquer dessus. Par exemple, il devrait être évident en regardant les liens vers la documentation utilisateur qu'ils renvoient bien à la documentation utilisateur et non pas, disons, à la documentation développeur. Diriger un projet consiste à la fois à fournir des informations mais aussi à rassurer. La simple présence de certaines offres standards, à l'endroit attendu, rassure les utilisateurs et les développeurs qui décident s'ils vont ou non s'impliquer. Cela montre que le projet a une ligne de conduite définie, qu'il a anticipé les questions que les visiteurs peuvent se poser, et qu'il a fait l'effort d'y répondre de manière simple. En se montrant bien préparé, le projet envoie un message : « Vous n'allez pas perdre votre temps en nous rejoignant », ce qui est exactement ce que les gens veulent entendre.

Regardez d'abord autour de vous

Avant de commencer un projet Open Source, faites attention à ceci :

Regardez toujours autour de vous afin de savoir s'il n'existe pas déjà un projet correspondant à ce que vous souhaitez. Il y a de bonnes chances que, peu importe le problème à résoudre, quelqu'un ait déjà pris l'initiative avant vous. Si le problème a été résolu et son code rendu public, sous une licence libre, vous n'avez aucune raison de réinventer la roue. Il y a bien sûr des exceptions : si vous voulez débuter un projet à des fins d'expérience pédagogique, un code pré-existant ne vous aidera pas, ou encore : le projet que vous avez en tête est si spécialisé que vous savez qu'il y a peu de chance qu'un autre l'ait déjà fait. Il n'y a, en général, aucune raison de ne pas effectuer de recherche, le gain peut être énorme. Si les moteurs de recherche sur Internet ne retournent aucune réponse, tentez votre chance sur http://freshmeat.net/ (un site rassemblant les nouvelles à propos de projets Open Source dont je parlerai plus longuement par la suite), sur http://www.sourceforge.net/ et dans le répertoire des logiciels libres de la Free Software Foundation à l'adresse http://directory.fsf.org/. Même si vous ne trouvez pas exactement ce que vous recherchiez, vous pourriez découvrir un projet s'en approchant suffisamment pour qu'il soit plus logique d'y ajouter une fonctionnalité en le rejoignant que de commencer à partir de rien et par vous même.

Commencez avec ce que vous avez

Vous avez cherché mais n'avez rien trouvé correspondant à votre besoin, vous êtes donc décidé à commencer un nouveau projet.

Que faire maintenant ?

La partie la plus difficile du lancement d'un projet de logiciel libre est la transposition d'une vision personnelle en une vision publique. Vous, ou votre organisation, savez parfaitement ce que vous voulez, mais expliquer ce but de manière compréhensible au monde entier représente un travail important. Il est essentiel cependant de prendre le temps de le faire. Vous et les autres membres fondateurs devez décider d'une définition précise du projet (c'est-à-dire, décider de ses limites, ce qu'il ne réalisera pas aussi bien que ce qu'il fera) et écrire une déclaration d'objectif (ou mission). Cette partie n'est, en général, pas trop compliquée bien qu'elle puisse révéler des non-dits et même des désaccords à propos de la nature du projet, ce qui est une bonne chose : mieux vaut résoudre ces problèmes maintenant que plus tard. L'étape suivante est de préparer la présentation du projet au public ; une véritable corvée.

Ce qui rend cette étape si laborieuse est qu'il s'agit ici principalement d'organiser et de documenter des choses que tout le monde connait déjà, « tout le monde » signifiant ici ceux qui ont déjà été impliqués dans un projet. Par conséquent, pour les gens s'occupant de cette tâche, il n'y a pas de gain immédiat. Ils n'ont pas besoin de fichier « Lisez moi » décrivant le projet, ni des fiches techniques ou de la documentation utilisateur. Ils n'ont pas besoin d'une arborescence du code établie avec attention selon des standards officieux mais largement utilisés pour la distribution du code de logiciels. Peu importe comment le code source est organisé, ils s'y retrouveront, ils y sont déjà habitués de toute façon et si le code fonctionne, ils savent l'utiliser. Peu importe aussi pour eux si les bases architecturales du projet restent non documentées, ils y sont déjà familiers.

Les nouveaux arrivants, d'un autre côté, ont besoin de ces informations. Heureusement, ils n'ont pas besoin de tout, tout de suite. Il n'est pas nécessaire de donner accès à toutes les sources possibles avant de rendre le projet public. Dans un monde parfait, peut-être, chaque nouveau projet Open Source commencerait avec un modèle de document exhaustif, un manuel utilisateur complet (avec des avertissements pour les fonctionnalités prévues mais pas encore implémentées), un beau code bien assemblé et portable, capable de fonctionner sur n'importe quelle plateforme, etc. En réalité, s'occuper de tous ces détails prendrait un temps considérable, serait rédhibitoire : de toute façon, c'est un travail pour lequel on peut espérer recevoir de l'aide des volontaires une fois le projet sur les rails.

Il est nécessaire cependant de s'investir suffisamment dans la présentation afin que les débutants puissent surmonter les premiers obstacles dus à leur manque d'habitude. Il faut le voir comme le premier pas pour lancer le projet du bon pied en lui apportant une sorte d'énergie d'activation minimale. Certains appellent ce seuil l'énergie d'hacktivation : l'énergie totale qu'un débutant doit fournir avant de recevoir quelque chose en retour. Le mieux étant une énergie d'hacktivation la plus basse possible. Votre première tâche sera d'abaisser cette énergie d'hacktivation à un niveau encourageant les gens à s'engager.

Chacune des sections suivantes décrit un aspect important du commencement d'un nouveau projet. Ils sont plus ou moins présentés dans l'ordre d'apparition pour un nouveau visiteur, même si, bien sûr, votre ordonnancement peut être différent. Vous pouvez vous en servir comme d'une liste de contrôle. Quand vous commencez un projet, suivez cette liste et assurez vous que chaque point soit traité, ou qu'au moins vous soyez confiant quant aux conséquences potentielles si vous décidiez d'en écarter un.

Choisissez un bon nom

Mettez-vous à la place de quelqu'un venant de découvrir votre projet, peut-être en le trouvant par hasard lors d'une recherche de logiciel en vue répondre à un besoin. La première chose qu'il verra est le nom du projet.

Un bon nom ne fera pas automatiquement de votre projet un succès et un mauvais ne le condamne pas (enfin, un très mauvais nom peut le faire, mais nous partons de l'hypothèse que personne ici ne tente intentionnellement de faire échouer son projet). Quoiqu'il en soit, un mauvais nom peut ralentir l'adoption du projet, soit parce que les gens ne le prennent pas au sérieux, soit simplement parce qu'ils ont du mal à le retenir.

Un bon nom :

• Donne une idée de ce que le projet fait, ou présente au moins clairement son domaine : ainsi, quelqu'un connaissant le nom et la teneur du projet, se le remémorera rapidement par la suite.
• Est simple à mémoriser. Ici, on ne peut ignorer que l'anglais est devenu le langage par défaut sur Internet : « simple à mémoriser » signifie « simple à mémoriser pour quelqu'un parlant anglais ». Les jeux de mots dépendants de la prononciation du locuteur dans cette langue, par exemple, seront obscurs pour les nombreux lecteurs pour qui l'anglais n'est pas la langue maternelle. Si le jeu de mot est particulièrement bien trouvé et facile à mémoriser, cela peut quand même fonctionner : gardez simplement à l'esprit qu'en voyant le nom, beaucoup ne l'entendront pas mentalement comme une personne de langue maternelle anglaise.
• N'est pas le même que celui d'un autre projet et ne s'approche d'aucune marque déposée. Ce ne sont que des bonnes manières et du bon sens légal. Vous ne voulez pas créer une confusion d'identité. Il est déjà assez difficile de suivre tout ce qui est disponible sur le Net sans des problèmes d'homonymie.

Les sites mentionnés précédemment dans l'introduction vous seront d'une grande aide pour savoir si un projet a déjà adopté le nom auquel vous pensiez. Une recherche gratuite de marques déposées est également faisable sur les sites http://www.nameprotect.org/ et http://www.uspto.gov/.

• Est disponible comme nom de domaine en .com, .net ou .org si possible. Vous devriez en choisir un, vraisemblablement en .org, comme site officiel de présentation du projet : les deux autres devraient renvoyer à ce premier site et ne sont simplement là que pour éviter que l'on créé une confusion d'identité autour du nom du projet. Même si vous avez l'intention de l'héberger sur un autre site (voir la section « Forges »), vous pouvez toujours enregistrer des noms de domaines particuliers pour le projet et les faire renvoyer vers le site d'hébergement. Cela aide beaucoup les utilisateurs d'avoir une adresse simple facilement mémorisable.

Définissez clairement vos objectifs

Une fois le site du projet trouvé, les gens chercheront une description rapide de sa teneur, votre mission, afin de pouvoir décider rapidement (dans les 30 secondes) s'ils souhaitent en savoir plus ou pas. Cette description devrait avoir une place de choix sur la première page, préférablement juste en dessous du nom du projet.

Votre mission doit être concrète, restreinte et surtout concise. En voici un bon exemple tiré du site http://www.openoffice.org/ :

Pour créer, en tant que communauté, la suite bureautique internationale dominante qui fonctionnera sur toutes les plateformes principales et qui donnera accès à toutes les fonctionnalités et à toutes les données au travers d'API basées sur des composants libres et des formats de fichier basés sur XML.

En simplement quelques mots, ils ont traité tous les points importants, principalement en s'appuyant sur les connaissances antérieures du lecteur. En écrivant « en tant que communauté », ils annoncent qu'aucune société ne dominera le développement, « internationale » veut dire que les gens pourront utiliser le logiciel dans de nombreuses langues et dialectes, « toutes les plateformes principales » veut dire qu'il sera utilisable sous Unix, Macintosh et Windows. La suite annonce que l'utilisation d'interfaces ouvertes et de formats de fichiers compréhensibles est une part importante de la mission fixée. Ils ne disent pas de but en blanc qu'ils essaient de proposer une alternative libre à Microsoft Office, cependant la plupart des gens peuvent le lire entre les lignes. Bien que cette mission puisse paraître large au premier abord, elle est assez concise : les mots « suite bureautique » signifient quelque chose de très concret aux familiers de ce genre de logiciels. Encore une fois, la présumée connaissance préalable du lecteur (dans ce cas probablement de MS Office) est utilisée pour que la mission reste concise.

La nature de la mission dépend en partie de son auteur, pas uniquement du logiciel décrit. Par exemple, il est logique pour OpenOffice.org d'utiliser les mots « en tant que communauté » car le projet a été initié et est encore largement financé par Sun Microsystems. En ajoutant ces mots, Sun indique sa compréhension des craintes liées à la tentation qu'aurait la société de dominer le processus de développement. En montrant simplement que l'on a conscience des conséquences possibles d'un problème, un grand pas en avant est fait pour l'éviter complètement. D'un autre côté, les projets dont le soutien financier n'est pas assuré par une unique entreprise n'ont pas besoin de tenir un tel discours, après tout, le développement communautaire est la norme : il devrait donc être normalement inutile de le lister parmi les objectifs.

Indiquez que le projet est libre

Ceux qui sont toujours intéressés, après avoir lu la mission, vont ensuite vouloir plus de détails, peut-être une documentation utilisateur ou développeur, et finiront par télécharger quelque chose. Mais auparavant, ils voudront s'assurer que c'est bien Open Source.

La première page doit annoncer sans ambiguïté que le projet est Open Source. Cela peut paraître évident, mais vous seriez surpris de voir combien de projets oublient de le faire. J'ai vu des sites de logiciels libres où la première page, non seulement ne donnait pas la licence de distribution du logiciel, mais ne déclarait même pas non plus que le logiciel était libre. Parfois l'information cruciale était reléguée à la page Téléchargements ou à la page Développeurs, voire une autre encore, nécessitant plus d'un clic pour s'y rendre. Dans les cas extrêmes, la licence n'était pas du tout mentionnée sur le site, le seul moyen de la découvrir étant de télécharger le logiciel pour trouver cette information.

Ne faites pas cette erreur. Une telle omission peut vous faire perdre de nombreux développeurs et utilisateurs potentiels. Annoncez de manière claire, juste en dessous de la mission, que le projet est un « logiciel libre » ou un « logiciel Open Source » et donnez la licence exacte. Un guide rapide pour choisir la licence est proposé dans la section nommée « Choisir une licence et l'appliquer » plus loin dans ce chapitre, et les problèmes relatifs aux licences sont exposés plus en détails dans le Chapitre 9, Licences, droits d'auteur et brevets.

À ce stade, notre visiteur hypothétique a établi (probablement en une minute ou moins) s'il compte passer, disons, au moins cinq minutes de plus à s'informer sur le projet. La prochaine partie décrit ce qu'il devrait trouver durant ces cinq minutes.

Liste des fonctionnalités et pré-requis

Il devrait y avoir une brève liste des fonctionnalités proposées par le logiciel (si un aspect n'est pas encore finalisé, vous pouvez toujours le lister en ajoutant à côté « prévu » ou « en cours ») et l'environnement informatique requis pour l'utiliser. Pensez la liste fonctionnalités/pré-requis comme ce que vous fourniriez à quelqu'un vous demandant un rapide résumé du logiciel. C'est souvent simplement une extension logique de la mission. Ainsi, cela pourrait être :

Créer un outil d'indexation de textes entiers et un moteur de recherche au moyen d'une API riche, en vue de son utilisation par des programmeurs fournissant des services de recherche concernant de grandes collections de fichiers textes.

La liste des fonctionnalités et des pré-requis devrait donner des détails en clarifiant la portée de la mission.

Fonctionnalités :

• Recherche de texte brut, HTML et XML
• Recherche de mots ou de phrases
• (prévu) Correspondance approximative
• (prévu) Mise à jour incrémentale de l'index
• (prévu) Indexation de sites Web distants

Pré-requis:

• Python 2.2 ou plus récent
• Suffisamment d'espace disque pour contenir l'index (approximativement 2x la taille d'origine des données)

Avec ces informations, les lecteurs peuvent rapidement se rendre compte si le logiciel leur convient, et également, envisager une implication dans le développement.

Avancement du développement

Les gens veulent toujours connaître la situation d'un projet. Pour les nouveaux projets, ils veulent apprécier l'écart existant entre les promesses et la réalité actuelle. Pour les plus avancés, ils cherchent à savoir comment est suivi le projet, le rythme de sortie des nouvelles versions et sa réactivité aux rapports de bogues, etc.

Pour répondre à ces questions vous devriez mettre en place une page d'avancement, listant les buts du projet à court terme et ses besoins (il pourrait, par exemple, être à la recherche de développeurs avec des compétences particulières). La page peut également fournir un historique des sorties passées avec une liste des fonctionnalités. Ainsi, les visiteurs peuvent se faire une idée de la manière dont est définie l'« avancement » du projet et sa vitesse de progression selon cette définition.

N'ayez pas peur de paraître non-préparé et ne cédez pas à la tentation d'exagérer la progression du développement. Chacun sait qu'un logiciel évolue par étapes, il n'y a pas de honte à dire « Ceci est une version alpha du logiciel avec des bogues connus. Il tourne et fonctionne au moins quelques fois, mais utilisez-le à vos propres risques. ». Un tel langage ne fera pas fuir les développeurs nécessaires à cette étape. Quant aux utilisateurs, l'une des pires choses possible est de les attirer avant que le logiciel ne soit prêt. Une image d'instabilité ou de sensibilité aux bogues est très dure à gommer une fois bien ancrée. Le conservatisme est rentable sur le long terme, mieux vaut toujours un logiciel plus stable comparé aux attentes de l'utilisateur que le contraire : les bonnes surprises contribuent à un meilleur bouche à oreille.

Téléchargements

Le logiciel devrait être téléchargeable sous forme de code source aux formats standards. Au commencement d'un projet, les paquets binaires (exécutables) ne sont pas nécessaires, à moins que la complexité de l'assemblage demandé ou des dépendances soit telle que le simple fait de le faire fonctionner représenterait un gros travail pour la plupart des gens (mais si tel est le cas le projet aura bien du mal à attirer les développeurs !).

Les mécanismes de distribution devraient être aussi pratiques, standards et transparents que possible. Si vous essayiez d'éradiquer une maladie, vous ne distribueriez pas un médicament demandant une taille de seringue non standard pour être administré. De même, le logiciel devrait se conformer à des règles standards de construction et d'installation : plus il s'écartera des normes, plus les utilisateurs et développeurs potentiels abandonneront et partiront ailleurs, perplexes.

Cela peut sembler évident, mais de nombreux projets ne prennent pas la peine de standardiser les procédures d'installation avant un stade avancé du développement, se disant qu'ils peuvent le faire à n'importe quel moment. « On s'occupera de tout ça quand le code sera presque fini ». Ce qu'ils ne réalisent pas, c'est qu'en remettant le travail fastidieux de finition à plus tard, ils rendent en fait la finalisation du code plus longue car ils découragent les développeurs qui auraient pu autrement contribuer au code. C'est même plus insidieux que cela, ils ne savent pas qu'ils perdent tous leurs développeurs, ce processus étant l'accumulation de non-évènements : quelqu'un visite un site Web, télécharge le logiciel, essaye de l'assembler, échoue, abandonne et va voir ailleurs. Qui saura un jour que c'est arrivé, hormis l'individu en question ? Personne, travaillant sur le projet, ne réalisera que l'intérêt de quelqu'un et sa bonne volonté ont été silencieusement gâchés.

Le travail barbant à forte rentabilité devrait toujours être réalisé tôt. Faciliter significativement l'accès au projet en créant des paquets standards est un exemple de forte rentabilité.

Quand vous publiez un paquet téléchargeable, il est vital que vous lui attribuiez un numéro de version unique, ainsi les gens peuvent comparer deux versions et savoir laquelle est la plus récente. Une discussion détaillée à propos de la numérotation se trouve dans la section « Numérotation de version » et les détails à propos de la standardisation d'une construction et des procédures d'installation sont traités dans la section appelée « Création de Paquets », toutes les deux dans le Chapitre 7, Paquets, sorties et développement quotidien.

Gestion de versions et accès au système de suivi de bogues

Télécharger les paquets sources est suffisant pour ceux qui veulent juste installer et utiliser un logiciel, mais c'est insatisfaisant pour ceux qui veulent le déboguer ou ajouter de nouvelles fonctionnalités. Des mises à jour chaque nuit peuvent aider, mais elles ne sont pas d'une précision assez fine pour une communauté de développeurs prospère. Les gens ont besoin d'un accès en temps réel aux dernières sources, et pour cela, on peut utiliser un programme de gestion de configuration logicielle. La présence de versions contrôlées du code source, anonymement accessibles, est un signe, à la fois pour les utilisateurs et les développeurs, que le projet fait un effort pour donner aux gens le nécessaire pour participer. Si vous ne pouvez pas proposer de gestion de versions tout de suite, alors affichez clairement votre intention de l'implanter rapidement. L'infrastructure d'une version de contrôle est discutée plus en détails dans la section nommée « Les logiciels de gestion de versions » dans le Chapitre 3, Infrastructure technique.

Il en va de même pour le système de suivi de bogues du projet. L'importance du suivi de bogues ne réside pas uniquement dans son utilité aux développeurs, mais aussi dans la signification qu'il a aux yeux des observateurs du projet. Pour la majorité, une base de données de bogues est l'un des signes les plus forts de la prise au sérieux du projet. Surtout, plus la base de données contient de bogues, meilleure est la santé du projet. Cela peut sembler illogique, mais souvenez-vous que le nombre de bogues enregistrés dépend principalement de trois choses : du nombre total de bogues présents, du nombre de personnes utilisant le logiciel et de la facilité qu'ont ces utilisateurs à rapporter les nouveaux bogues. De ces trois facteurs, les deux derniers sont plus importants que le premier : comment le projet va-t-il gérer l'enregistrement et la gestion des priorités de ces bogues ? Un projet avec une base de données de bogues importante et développée (ce qui signifie que les bogues sont corrigés rapidement, que les bogues dupliqués sont unifiés, etc.) fait alors meilleure impression qu'un projet sans base de données de bogues ou avec une base presque vide.

Bien évidemment, si vous venez de débutez votre projet, votre base de données contiendra très peu de bogues, difficile d'y faire grand chose. Mais, si la page d'avancement met l'accent sur la jeunesse du projet, et, si les gens regardant la base de données de bogues peuvent voir que la majeure partie de l'archivage a été faite récemment, ils pourront en déduire que le projet a un rythme d'archivage sain et ne seront pas indûment alarmés par le nombre relativement faible de bogues enregistrés.

Remarquez que les systèmes de recherche de bogues ne sont souvent pas uniquement utilisés pour rapporter les bogues du logiciel mais aussi pour rapporter les demandes d'améliorations, de modifications de la documentation, des tâches en cours et plus encore. Les détails sur l'utilisation d'un système de suivi de bogues sont donnés dans la section « Suivi de bogues » dans le Chapitre 3, Infrastructure technique, donc je ne m'étendrai pas plus ici. L'aspect important, du point de vue de la présentation, est d'avoir un système de suivi de bogues, et de s'assurer que ce fait est bien visible sur la page d'accueil du projet.

Les voies de communications

Les visiteurs veulent en général savoir comment contacter les êtres humains impliqués dans le projet. Fournissez les adresses des listes de diffusion, des canaux IRC et tout autre forum où chaque personne impliquée dans le logiciel peut être jointe. Indiquez clairement que vous et les autres auteurs du projets sont inscrits sur ces listes de diffusion afin que les gens puissent voir qu'il existe des moyens de donner leur avis aux développeurs. Votre présence sur les listes n'implique pas que vous êtes tenus de répondre à toutes les questions ou d'ajouter toutes les idées données. Sur le long terme, la plupart des utilisateurs ne s'inscriront jamais aux forums de toute façon, mais ils seront rassurés de savoir qu'ils peuvent le faire si besoin est.

Au cours des premières étapes du projet, nul n'est besoin de séparer les forums utilisateurs et développeurs. Il vaut bien mieux réunir toutes les personnes concernées par le logiciel dans une même « salle » pour en discuter. La distinction entre développeurs et utilisateurs est souvent floue pour les premiers arrivants, si tant est qu'elle existe : le nombre de développeurs par rapport à celui des utilisateurs est, en général, beaucoup plus élevé dans les premiers jours du projet que par la suite. Même si vous ne pouvez partir du principe que tout nouvel arrivant est un programmeur voulant bidouiller le logiciel, vous pouvez supposer qu'il est au minimum désireux de suivre les discussions autour du développement et de comprendre l'orientation du projet.

Comme ce chapitre ne traite que du lancement d'un projet, c'est presque suffisant de dire que ces forums de communication doivent exister. Plus tard, dans la section appelée « Gérer la croissance » au Chapitre 6, Communication, nous examinerons où et comment mettre en place de tels forums, dans quel mesure ils peuvent avoir besoin d'une modération ou d'autres formes de surveillance, et comment séparer, le moment venu, les forums utilisateurs des forums développeurs sans creuser de fossé infranchissable.

Les directives développeurs

Si une personne envisage de contribuer au projet, elle cherchera les directives développeurs. Les directives développeurs ne sont pas vraiment techniques mais plutôt sociales : elles expliquent comment les développeurs interagissent entre eux et avec les utilisateurs, et finalement comment les choses se déroulent.

Ce sujet est détaillé dans la section dénommée « Tout mettre par écrit » dans le Chapitre 4, Infrastructure sociale et politique, mais les éléments de base des directives pour les développeurs sont :

• des liens vers les forums pour l'interaction avec d'autres développeurs.
• des instructions pour les rapports de bogues et la soumission de correctifs.
• des indications sur la gestion du développement, le projet est-il une dictature bénévole, une démocratie ou quelque chose d'autre encore ?

Le mot « dictature » n'est pas employé dans un sens péjoratif d'ailleurs. Une tyrannie où un développeur particulier a le droit de veto sur tous les changements n'a rien de choquant. Beaucoup de projets réussis fonctionnent de cette manière. Il est simplement important d'annoncer la couleur. Une tyrannie faisant semblant d'être une démocratie découragera les gens, une tyrannie qui ne se déguise pas fonctionnera très bien tant que le tyran est compétent et a la confiance de tous.

Voir http://svn.collab.net/repos/svn/trunk/www/hacking.html pour un exemple particulièrement complet de directives pour les développeurs, ou http://www.openoffice.org/dev_docs/guidelines.html pour des directives plus larges qui se concentrent plus sur l'administration et l'esprit de participation et moins sur les aspects techniques.

Le problème distinct de la présentation du logiciel aux programmeurs est abordé dans la section nommée « Documentation développeur » plus loin dans ce chapitre.

Documentation

La documentation est essentielle. Il faut quelque chose à lire, même si c'est rudimentaire et incomplet. La documentation fait vraiment partie des « corvées » mentionnées précédemment, et c'est souvent le premier domaine où un nouveau projet Open Source peut s'effondrer. Proposer une mission et une liste de fonctionnalités, choisir une licence, résumer l'avancement du développement sont des tâches relativement simples pouvant être accomplies une bonne fois pour toutes et dont vous n'aurez plus à vous soucier. La documentation, à l'inverse, n'est jamais vraiment terminée, ce qui peut être parfois une bonne raison pour retarder son exécution.

Insidieusement, rédacteur(s) et lecteurs ne partagent pas les mêmes préoccupations. La documentation la plus importante pour les nouveaux utilisateurs concerne les bases : comment rapidement mettre le logiciel en route, une vue d'ensemble de son fonctionnement et peut-être quelques guides pour les tâches courantes. Or, c'est exactement tout ce que les auteurs de la documentation connaissent parfaitement, si parfaitement, qu'il peut être difficile pour eux de voir les choses du point de vue du lecteur, et d'énumérer laborieusement les étapes qui (aux yeux des auteurs) semblent évidentes ou inutiles à mentionner.

Il n'y a pas de solution miracle à ce problème. Il faut prendre le temps de l'écrire, puis de la mettre entre les mains d'un nouvel utilisateur lambda pour en tester la qualité. Utilisez un format facilement éditable comme le HTML, du texte brut, Texinfo ou une variante de XML, quelque chose de pratique en vue de retouches légères et d'améliorations sur une impulsion. Il ne s'agit pas simplement d'ôter un obstacle qui pourrait gêner les auteurs voulant apporter des améliorations, mais aussi de permettre, à ceux qui rejoindront plus tard le projet, de travailler sur la documentation.

On peut s'assurer que la réalisation de la documentation initiale de base sera accomplie, en limitant par avance son étendue. Ainsi, son écriture ne semblera pas être une tâche infinie. Par expérience, la documentation devrait remplir les critères minimaux suivant :

• Indiquer clairement au lecteur le degré d'expertise attendu de sa part.

• Décrire clairement et de manière détaillée comment lancer le logiciel et, quelque part en début de documentation, dire à l'utilisateur comment faire fonctionner une sorte de diagnostic ou une commande simple confirmant que tout a été fait correctement. Les instructions de démarrage sont d'une certaine manière plus importantes que les instructions d'utilisation. Plus une personne fournit d'efforts pour installer et faire ses premiers pas avec le logiciel, plus elle persévèrera à découvrir les fonctionnalités avancées qui ne sont pas aussi bien documentées. Quand les gens abandonnent, ils le font rapidement, aussi, ce sont les premières étapes, comme l'installation par exemple, qui demandent le plus d'assistance.

• Présenter un exemple, ou une méthode, sur la manière de réaliser une tâche basique. Évidemment, de nombreux exemples seraient préférables, mais si vous êtes limité par le temps, sélectionnez une fonction et décrivez la en détail. Dès qu'une personne constate que le logiciel peut servir à quelque chose, elle va commencer à explorer les autres possibilités voire, si vous êtes chanceux, compléter elle-même la documentation. Ce qui nous amène au point suivant....

• Indiquer les endroits où la documentation est incomplète. En montrant au lecteur que vous connaissez ses imperfections, vous vous accordez à son point de vue. Votre empathie le rassure : il n'aura pas à lutter pour convaincre le projet de ce qui est important. Ces indications ne sont pas nécessairement des promesses de remédier à ces insuffisances à une date précise, il est légitime également de les voir comme des appels à l'aide de volontaires.

Le dernier point est réellement de la plus grande importance et s'applique au projet entier, pas uniquement à la documentation. Tenir un compte précis des lacunes connues est la norme dans le monde de l'Open Source. Inutile d'exagérer les défauts du projet, il suffit simplement de les identifier scrupuleusement et impartialement quand le besoin s'en fait sentir (que ce soit dans la documentation, dans la base de données de suivi de bogues ou dans les discussions sur la liste de diffusion). Personne ne verra cela comme du défaitisme de la part du projet, ni comme une promesse de résolution des problèmes à une date précise, à moins que le projet ne s'y engage explicitement. Étant donné que tout utilisateur du logiciel découvrira les lacunes de lui même, il est préférable qu'il y soit préparé psychologiquement, de plus, le projet donnera l'impression d'une parfaite connaissance de son état de fonctionnement.

Disponibilité de la documentation

La documentation devrait être disponible en deux endroits : en ligne, directement depuis le site Web, et dans la distribution téléchargeable du logiciel (voir la section appelée « Création de paquets » dans le Chapitre 7, Paquets, sorties et développement quotidien). Elle doit être en ligne sous une forme navigable car les gens lisent souvent la documentation avant de télécharger le logiciel pour la première fois afin de décider s'ils vont le faire ou pas. Mais elle doit aussi accompagner le téléchargement du logiciel qui devrait fournir (c'est-à-dire rendre l'accès hors ligne possible) tout ce dont on pourrait avoir besoin pour utiliser le paquet.

En ce qui concerne la documentation en ligne, assurez-vous qu'il y a un lien menant vers la documentation complète sur une page au format HTML (ajoutez une note comme « monolithique », « tout en un » ou « page unique » à côté du lien, afin que les gens sachent que ça pourra prendre un certain temps à charger). C'est utile car, souvent, ils veulent chercher un mot en particulier ou une phrase dans la documentation entière. En général, ils savent déjà ce qu'ils cherchent, ils ne se souviennent simplement pas où se trouve l'information. Pour eux, rien n'est plus frustrant que de rencontrer une page HTML pour le sommaire, ensuite une autre pour l'introduction, une autre encore pour les instructions d'installation, etc. Quand les pages sont séparées ainsi, la fonction de recherche de leur navigateur est inutile. Une structure éclatée est utile pour ceux qui savent à quelle partie ils doivent se référer ou ceux qui veulent lire le document du début à la fin par morceaux. Ne pas leur proposer un document complet sur une seule page leur compliquerait la vie plus qu'autre chose.

La documentation développeur

La documentation développeur est rédigée pour aider les programmeurs à comprendre le code, ainsi ils peuvent le réparer et le compléter. Elle ne fait pas double emploi avec les directives pour les développeurs dont nous avons parlé précédemment qui sont plus un outil social que technique. Les directives pour les développeurs indiquent aux programmeurs comment bien collaborer entre eux, la documentation développeur leur indique comment se débrouiller avec le code lui-même. Les deux sont en général réunies en un seul document pour des raisons pratiques (comme dans l'exemple donné plus tôt : http://svn.collab.net/repos/svn/trunk/www/hacking.html), mais ce n'est pas une obligation.

Bien que la documentation utilisateur puisse être très pratique, elle ne doit pas être la raison d'un retard de la distribution. Que les auteurs d'origine soient disponibles (et disposés à le faire) pour répondre aux questions touchant au code, est déjà suffisant pour commencer. En fait, c'est le fait de devoir répondre sans cesse aux mêmes questions qui motive souvent les gens à écrire la documentation. Mais, même avant qu'elle ne soit rédigée, les participants motivés trouveront comment fonctionne le code. En apprenant les bases du code, ils réalisent quelque chose d'utile pour eux, c'est ce qui les pousse à persévérer. Si les gens y croient vraiment, ils prendront le temps de comprendre les choses, s'ils n'ont pas cette foi, ce n'est pas la documentation, aussi complète puisse-t-elle être, qui les attirera ou les fera rester.

Donc, si vous n'avez le temps d'écrire la documentation que pour un seul public, faites-le pour les utilisateurs. Au fond, la documentation utilisateur est également une documentation développeur puisque les programmeurs qui vont travailler sur une partie du logiciel doivent être familiers avec son utilisation. Ensuite, quand vous voyez que les programmeurs posent sans cesse les mêmes questions, prenez le temps d'écrire quelques documents indépendants plus spécialement pour eux.

Certains projets utilisent des wikis comme documentation de départ, voire comme documentation principale. D'après mon expérience, cela ne fonctionne vraiment que si le wiki est souvent édité par une poignée de gens en accord sur la manière d'organiser la documentation et sur le ton qu'elle devrait avoir. Référez-vous à la section « Wikis » dans le Chapitre 3, Infrastructure technique pour en savoir plus.

Exemples de réalisations et captures d'écran

Si le projet comporte une interface graphique, s'il produit des graphiques ou tout autre forme de réalisation visible, affichez-en quelques exemples sur le site du projet. Pour les interfaces, cela signifie des captures d'écran, pour les réalisations ça pourra prendre la forme de captures d'écrans ou simplement de fichiers. Les deux satisfont le besoin d'avoir une gratification immédiate : une simple capture d'écran peut se montrer plus convaincante que des paragraphes de texte descriptif ou des conversations extraites de la liste de diffusion. Une capture d'écran est la preuve irréfutable que le logiciel fonctionne. Il peut être bogué, il peut être compliqué à installer, sa documentation n'est peut-être pas complète, mais cette capture d'écran est quand même la preuve que, si on y met assez de bonne volonté, on peut le faire fonctionner.

Il y a bien d'autres choses que vous pouvez ajouter à votre site Web, si vous en avez le temps ou si, pour une raison ou pour une autre, elles vous apparaissent particulièrement appropriées : une page d'informations, une page pour l'historique du projet, une page pour les liens connexes, une fonction de recherche, un lien pour les dons, etc. Rien de tout ceci n'est absolument nécessaire au moment du lancement, mais gardez-les à l'esprit pour le futur.

Forges

Il y a quelques sites qui proposent un hébergement gratuit ainsi que l'infrastructure pour des projets Open Source : une zone Web, une gestion de versions, un système de suivi de bogues, une zone de téléchargement, des forums de discussions, des sauvegardes régulières, etc. Les détails varient d'un site à l'autre, mais les services de base sont les mêmes partout. En utilisant l'un de ces sites vous obtiendrez beaucoup en échange de rien. Vous tournez par contre le dos à un contrôle précis de ce que vous offrez aux utilisateurs du site. Les services d'hébergement décident des logiciels qui fonctionnent sur le site et peuvent contrôler, ou au moins influencer, l'aspect des pages Web du projet.

Je vous renvoie à la section « Forges » dans le Chapitre 3, Infrastructure technique pour un exposé plus détaillé des avantages et inconvénients des forges ainsi qu'une liste de sites qui offrent ces services.

Choisir une licence et l'appliquer

Cette partie est un guide rapide, non exhaustif, du choix d'une licence. Lisez le Chapitre 9, Licences, droits d'auteur et brevets pour mieux comprendre les détails des implications légales des différentes licences et l'influence qu'aura votre choix sur l'intégration de votre logiciel dans d'autres logiciels libres.

Vous avez le choix entre un grand nombre de licences. Nous n'avons pas besoin de parler de la plupart d'entre elles ici puisqu'elles ont été écrites pour satisfaire des besoin légaux très particuliers pour certaines sociétés ou personnes et qu'elles ne seraient pas appropriées pour votre projet. Nous nous en tiendrons simplement aux licences les plus courantes, dans la plupart des cas votre choix se portera sur l'une d'elles.

Les licences à « tout faire »

Si cela ne vous dérange pas que le code de votre projet puisse être utilisé dans un programme propriétaire vous devriez utiliser une licence du type MIT/X. C'est la plus simple parmi certaines licences minimales qui ne font pas grand chose de plus que revendiquer un droit d'auteur nominal (sans pour autant limiter la copie) et spécifier que le code est livré sans garantie. Référez-vous à la section « Le système de licence MIT/X Window » pour plus de détails.

La licence GPL

Si vous ne souhaitez pas que votre code puisse être utilisé dans des programmes propriétaires utilisez la licence GNU General Public Licence (http://www.gnu.org/licences/gpl.html). La licence GPL est certainement la licence pour logiciel libre la plus largement reconnue dans le monde aujourd'hui, ce qui est déjà un avantage important puisque les utilisateurs et les bénévoles seront familiers avec cette licence et donc n'auront pas à passer du temps en plus pour la lire et la comprendre. Voir la section nommée « La licence GNU General Public License » dans le Chapitre 9, Licences, droits d'auteur et brevets pour de plus amples informations.

Comment appliquer une licence à votre logiciel

Une fois la licence choisie vous devriez la faire apparaître sur la première page du projet. Vous n'avez pas besoin d'ajouter le texte de la licence à cet endroit : précisez simplement le nom de la licence et créez un lien vers le texte complet se trouvant sur une autre page.

Vous annoncez ainsi au public sous quelle licence vous comptez distribuer le projet, mais ce n'est pas légalement suffisant. Pour ceci il faut que le logiciel contienne cette licence. Habituellement, le texte complet de la licence se trouve dans un fichier nommé « COPIE » (ou « LICENCE »), et une petite note en début de chaque fichier source indique la date du copyright, le détenteur des droits et l'emplacement du texte complet de la licence.

Il y a beaucoup de variantes possibles à ce modèle, donc nous verrons juste un exemple ici. La licence GNU GPL recommande d'ajouter une note comme celle ci-dessous au début de chaque fichier source.

Copyright (C) <year>  <name of author>

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 3 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, see <http://www.gnu.org/licenses/>

ou en français :

Copyright (C) <année> <nom de l'auteur>

Ce programme est un logiciel libre : vous pouvez le redistribuez et/ou le
modifier sous les termes de la licence GNU Public Licence telle que publiée
par la Free Software Foundation, soit dans la version 2 de la licence, ou
(selon votre choix) toute version ultérieure. 
Ce programme est distribué avec l'espoir qu'il sera utile, mais SANS AUCUNE
GARANTIE : sans même les garanties implicites de VALEUR MARCHANDE ou
D'APPLICABILITÉ À UN BUT PRÉCIS. Voir la licence GNU General Public License
pour plus des détails.

Vous devriez avoir reçu une copie de la licence GNU General Public Licence
avec ce programme. Si ce n'est pas le cas, voir <http://www.gnu.org/licenses/>

Rien n'indique spécifiquement que la licence livrée avec le programme est dans le fichier « COPIE », mais c'est là qu'elle est en général copiée (Vous pouvez modifier la note ci-dessus pour le préciser directement). Ce modèle fournit également l'adresse postale où demander une copie de la licence. Une autre méthode courante est de fournir un lien vers le site Web où se trouve la licence. Fiez-vous à votre jugement et renvoyez à la page que vous pensez être la plus à même d'être maintenue, ce qui peut simplement être le site de votre projet. En général la note que vous ajoutez dans chaque fichier source n'a pas besoin de ressembler exactement à ceci, tant qu'elle commence en indiquant le détenteur des droits et la date, précise le nom de la licence et dit clairement où la licence peut être trouvée.

Donner le ton

Jusque-là, nous avons vu les tâches à faire une fois pour toutes à la mise en route : choisir une licence, créer le site Web, etc. Mais les aspects les plus importants de la création d'un projet changent sans cesse. Le choix d'une adresse pour la liste de diffusion est simple, vous assurez que les discussions sur cette liste ne dévient pas est complètement différent. Si le projet s'ouvre après des années de développement interne, son processus de développement s'en retrouvera modifié et vous devrez préparer les développeurs déjà présents à ce changement.

Les premiers pas sont les plus durs car les modèles et les attentes pour le futur n'ont pas encore été définis. La stabilité d'un projet n'est pas due à des règles formelles mais à une sagesse collective, difficile à définir, qui se développe avec le temps. On retrouve souvent des règles écrites également, mais elles représentent plutôt une version distillée des accords intangibles et sans cesse changeants qui dirigent vraiment le projet. Les règles écrites sont plus descriptives de la culture du projet que caractérisantes, et encore, seulement approximativement.

Il y a plusieurs raisons à ce mode de fonctionnement. La croissance et un fort taux de renouvellement ne sont pas aussi nuisibles à l'accumulation de normes sociales qu'on pourrait le penser. Tant que les changements ne se produisent pas trop vite, les nouveaux arrivants ont le temps d'apprendre comment les choses fonctionnent, et après avoir appris, ils apporteront leur propre contribution. Voyez comme les chansons enfantines survivent à travers les siècles. Les enfants d'aujourd'hui chantent plus ou moins les mêmes rimes que celles chantées par d'autres enfants, il y a des centaines d'années de cela, alors qu'aucun enfant de l'époque n'est encore vivant. Les jeunes enfants entendent des chansons chantées par leurs aînés, ensuite, plus vieux, ils les chantent à leur tour devant d'autres, plus jeunes qu'eux. Les enfants n'entrent pas consciemment dans ce programme de transmission évidemment, mais la raison qui fait que ces chansons survivent est qu'elles sont malgré tout transmises régulièrement et de manière répétée. L'échelle de temps des logiciels libres ne se mesure peut-être pas en siècles (on ne sait pas pour l'instant), mais les moyens de transmission sont très proches. Le taux de renouvellement est plus rapide cependant, et doit être compensé par un effort de transmission plus actif et volontaire.

Cet effort est aidé par le fait que les gens arrivent en cherchant et en espérant trouver des normes sociales. L'Homme est ainsi fait. Dans un groupe unifié par un but commun les recrues cherchent instinctivement les attitudes qui montreront qu'ils font partie du groupe. Le but est d'établir rapidement des modèles, et de rendre ces comportements « de groupe » utiles au projet, car une fois en place ils se perpétueront principalement d'eux mêmes.

Vous trouverez ci-dessous quelques pistes qui vous guideront dans la bonne marche à suivre. Cette liste n'est pas exhaustive, ce sont simplement des illustrations de l'idée que la création précoce d'une bonne collaboration aide énormément le projet. Physiquement, les développeurs travailleront peut-être seuls, mais vous pouvez faire en sorte qu'ils se sentent plus proches, comme s'ils travaillaient tous dans la même pièce. Si vous réussissez, ils auront plus envie de passer du temps sur le projet. Je choisis ces exemples particuliers car le projet Subversion y fut confronté (http://subversion.tigris.org/). J'y ai participé, j'ai pu observer, depuis le tout début, ces problèmes. Mais ils ne sont pas spécifiques à Subversion, la plupart des projets Open Source les rencontreront et ces exemples doivent être pris comme des opportunités de commencer du bon pied.

Évitez les discussions privées

Même une fois le projet ouvert au public, vous et les autres fondateurs serez tentés de régler les problèmes délicats par des discussions privées au sein d'un cercle fermé. C'est particulièrement vrai dans les premiers jours, quand il y a tant de décisions importantes à prendre et, généralement, peu de volontaires qualifiés pour le faire. Tous les inconvénients des discussions publiques vous apparaîtront de manière palpable : le délai inhérent aux discussions par e-mail, le besoin de laisser suffisamment de temps à un consensus pour se former, le tracas d'avoir affaire aux volontaires naïfs qui pensent saisir les tenants et les aboutissants du problème alors que ce n'est pas le cas (tout projet a cette catégorie de volontaires, ils pourront très bien devenir les membres les plus actifs l'année suivante, tout comme ils peuvent aussi rester naïfs pour toujours), l'ennui d'avoir affaire à la personne qui ne comprend pas pourquoi vous voulez résoudre juste le problème X alors qu'il fait partie de manière évidente d'un plus grand problème Y et ainsi de suite. La tentation sera effectivement grande de prendre les décisions en petit comité et de les présenter comme des faits accomplis, ou au moins comme les recommandations d'une grande partie soudée et influente des votants.

Ne le faites pas.

Aussi encombrantes et lentes qu'elles puissent être, les discussions publiques seront presque toujours préférables sur le long terme. Prendre les décisions importantes en privé reviendrait à pulvériser du repousse bénévoles sur le projet. Aucun volontaire sérieux ne resterait longtemps dans un environnement où toutes les grandes décisions sont prises par un conseil privé. De plus, les discussions publiques ont des effets secondaires positifs qui perdureront bien après l'éphémère question technique débattue :

• La discussion aidera à entraîner et instruire les nouveaux développeurs. Vous ne savez jamais combien de paires d'yeux suivent une conversation, même si la plupart ne participent pas, ils peuvent être nombreux à la suivre en silence, glanant des informations sur le logiciel.

• La discussion vous entraînera dans l'art d'expliquer les problèmes techniques aux gens qui ne sont pas aussi familiers que vous avec le logiciel. C'est une compétence qui demande de la pratique, pratique que vous ne pouvez pas acquérir en parlant avec des gens qui savent déjà ce que vous savez.

• La discussion et ses conclusions seront ensuite accessibles en permanence dans des archives publiques, permettant aux discussions futures d'éviter de tourner en rond. Voir la section « Utilisation efficace des archives » dans le Chapitre 6, Communication.

Finalement, il se peut que quelqu'un dans la liste apporte une vraie contribution à la discussion, en proposant une idée à laquelle vous n'auriez pas pensé. Il est difficile d'en déterminer la probabilité : ça dépend simplement de la complexité du code et du degré de spécialisation requis. Mais s'il m'est accordé de fournir une preuve anecdotique, je me risquerais à dire que c'est plus probable que ce que vous pourriez penser. Dans le projet Subversion, nous (les fondateurs) pensions que nous faisions face à un ensemble de problèmes graves et complexes auxquels nous réfléchissions beaucoup depuis quelques mois. Nous doutions franchement qu'un membre de la nouvelle liste de diffusion puisse apporter une vraie contribution à la discussion. Alors, nous avons employé la manière simple et nous avons commencé à débattre d'idées techniques par e-mails privés, jusqu'à ce que quelqu'un qui observait le projet [10] ait eu vent de ce qui se passait et ait demandé à ce que la discussion soit partagée dans la liste publique. Nous l'avons fait, un peu mécontents, et nous avons été surpris par le nombre de commentaires inspirés et de suggestions qui en ont rapidement résulté. Dans beaucoup de cas, les gens proposaient des idées qui ne nous étaient encore jamais venues à l'esprit. En fin de compte, il y avait des gens très malins sur cette liste, ils attendaient simplement qu'on leur tende la main. J'avoue que les discussions qui ont suivi ont pris plus de temps qu'elles ne l'auraient fait si nous avions gardé cette conversation privée, mais elles étaient tellement plus productives que ça n'était pas du temps perdu, loin s'en faut.

Sans tomber dans les généralisations faciles comme « le groupe est toujours plus fort que l'individu » (nous avons tous connus suffisamment de groupes pour savoir que ce n'est pas forcément vrai), il faut reconnaître que dans certains domaines le groupe excelle. Une inspection à grande échelle par nos confrères en fait partie, générer un grand nombre d'idées rapidement également. La qualité des idées dépend de la qualité de la réflexion menée bien sûr, mais vous ne pourrez jamais jauger le niveau de vos collaborateurs si vous ne leur soumettez pas un problème difficile.

Évidemment, certaines discussions doivent être privées, nous en verrons des exemples tout au long du livre. Mais le principe directeur devrait toujours être : s'il n'y a pas de raison qu'elle soit privée alors elle devrait être publique.

Rendre cela possible demandera des efforts. Il ne suffit pas simplement de s'assurer que tous vos billets passent par la liste publique. Vous devez aussi faire en sorte que les discussions d'autres personnes qui n'ont pas de raison d'être privées figurent également sur la liste publique. Si quelqu'un tente de commencer une conversation privée, sans raison de confidentialité particulière, il vous incombe alors de rendre public l'embryon de discussion au plus tôt. Ne faites pas de commentaires sur le sujet d'origine avant d'avoir réussi à le diriger vers un endroit public ou de vous être assuré que la confidentialité était requise. Si vous insistez, les gens comprendront rapidement et commenceront à utiliser les forums publics naturellement.

Tuez la vulgarité dans l'œuf

Dès le début de votre projet, vous devriez maintenir une politique de tolérance zéro contre les comportements grossiers et insultants au sein des forums. La tolérance zéro n'implique pas l'emploi des grands moyens. Vous n'êtes pas censé bannir des personnes des listes de diffusion parce qu'elles s'en sont prises à un autre membre, ni leur retirer leur accès de commit pour des commentaires désobligeants (en théorie vous serez peut-être amené à vous y résoudre, mais seulement après avoir épuisé toutes les autres solutions, ce qui par nature n'est pas le cas au début du projet). Montrer une tolérance nulle signifie simplement ne jamais fermer les yeux sur un mauvais comportement. Par exemple, quand quelqu'un publie un commentaire technique mêlé à une attaque ad hominem contre un autre développeur travaillant sur le projet, vous devez en premier lieu répondre à l'attaque ad hominem comme à un problème différent et, seulement ensuite, revenir au contenu technique du message.

Il est malheureusement très facile, et bien trop courant, que des discussions constructives sombrent en batailles rangées. Les gens peuvent dire par e-mail des choses qu'ils n'oseraient jamais se dire en face. Le sujet de discussion amplifie ce fait : concernant les problèmes techniques, les gens pensent souvent qu'une seule bonne solution répond à la plupart des questions et qu'un avis divergent ne peut être expliqué que par l'ignorance ou la stupidité. Il n'y a qu'un pas entre dire que la proposition d'une personne est stupide et dire que la personne elle même est stupide. En fait la frontière entre débat technique et attaque personnelle est souvent difficile à discerner. C'est l'une des raisons pour lesquelles les mesures drastiques ou les punitions ne sont pas une bonne idée. Quand vous pensez être témoin de ceci, faites plutôt une réponse incitant les gens à conserver un ton amical dans les discussions, sans accuser personne d'avoir été délibérément fauteur de troubles. Ces réponses très « policier sympa » ont une malheureuse tendance à ressembler à un cours sur les bonnes manières donné par un maître de maternelle :

En premier, occupons nous, si vous le voulez bien, des commentaires potentiellement ad hominem ; par exemple, dire que le modèle de J pour la couche de sécurité est « naïf et ignorant des principes de base de la sécurité informatique » n'est en aucun cas une manière d'en débattre, que cela soit vrai ou pas. J a fait sa proposition en toute bonne foi. Si elle présente des inconvénients, indiquez les et on les corrigera ou on décidera de pencher pour une autre solution. Je suis sûr que ce n'était pas l'intention de M d'insulter personnellement J, mais les mots étaient mal choisis et on essaie de garder les discussions constructives ici.

En ce qui concerne la proposition. Je pense que M a raison lorsqu'il dit que...

Bien que ce genre de réponses semblent artificiellement formelles, elles ont un effet visible. Si vous montrez du doigt les mauvais comportements sans cesse, sans demander d'excuses ou de reconnaissance de faute à la personne offensante, vous laissez les gens se calmer doucement et montrer un meilleur visage la prochaine fois en se comportant de manière plus courtoise et ils le feront. Un des secrets pour que cette technique soit payante est de ne jamais laisser le hors sujet devenir la discussion principale. Ça doit rester une parenthèse, comme une courte préface au corps de votre réponse. Indiquez en passant que les choses ne se déroulent pas ainsi par ici, mais ensuite, passez au vrai sujet afin de recentrer le débat et de donner aux autres matière à répondre. Si quelqu'un pense ne pas avoir mérité votre reproche et conteste, refusez simplement d'être attiré dans une dispute à ce propos. Vous pouvez ne pas répondre (si vous estimez qu'il se défoule simplement et que ça n'appelle pas de réponse) ou dire que vous êtes désolé si vous avez réagi excessivement et qu'il est difficile de détecter les nuances par e-mail, ensuite revenez en au sujet principal. N'insistez surtout jamais pour qu'une personne qui s'est mal conduite reconnaisse ses torts, que ce soit publiquement ou en privé. S'ils décident de leur propre chef de faire un message d'excuse, c'est très bien, mais leur demander de le faire apportera uniquement de la rancœur.

Il importe surtout que les gens voient l'usage des bonnes manières comme un comportement du « groupe ». C'est important pour le projet puisque les développeurs peuvent être découragés (même au sein d'un projet qu'ils aiment et veulent soutenir) par des guerres d'insultes. Ça pourrait même arriver sans que vous ne vous en rendiez compte, quelqu'un pourrait jeter un œil aux discussions, voir qu'il faut la peau dure pour participer à ce projet et décide finalement de ne pas s'impliquer. Maintenir les forums accueillants est une stratégie de survie à long terme, et c'est plus simple à réaliser quand le projet est encore petit. Une fois que ça sera entré dans les mœurs, vous ne serez plus le seul à insister sur la politesse, tout le monde le fera.

Effectuez une inspection visible du code

L'un des meilleurs moyens de motiver une communauté de développement productive est d'amener les gens à regarder le code des autres. Une certaine infrastructure technique est requise pour le faire efficacement, en particulier les e-mails de commit doivent être activés, voir la section « E-mails de commit » pour plus de détails. Chaque fois que quelqu'un modifie le code source, l'effet de l'e-mail de commit est qu'un e-mail est envoyé montrant le journal et les diffs concernant les changements (voir diff dans la section nommée « Vocabulaire de la gestion de versions »). L'inspection du code consiste à étudier les e-mails de commit à mesure qu'ils arrivent, à chercher des bogues et les améliorations possibles. [11]

L'inspection du code a plusieurs utilités. C'est l'exemple le plus probant de critique par les pairs dans le monde de l'Open Source, il aide directement à maintenir la qualité du logiciel. Tout bogue qui se retrouve dans une partie du logiciel a été créé mais pas détecté, donc plus il y a d'yeux qui surveillent les commits, moins il y a de bogues passant au travers des mailles du filet. Mais l'inspection du code est utile indirectement également : ça confirme aux gens que ce qu'ils font compte, en effet personne ne prendrait le temps d'inspecter un commit à moins qu'il n'accorde de l'importance à ces effets. Les gens donnent le meilleur d'eux-même quand ils savent que d'autres personnes prendront le temps d'évaluer leur travail.

Les inspections devraient être publiques. Même lorsque j'étais dans la même salle que les développeurs et que l'un de nous avait apporté une contribution, nous n'en avons pas fait la critique verbalement dans la salle mais l'avons envoyée à la place à la liste de diffusion des développeurs. C'est dans l'intérêt de chacun de voir que la critique a été faite. Les gens s'intéressent aux commentaires, parfois ils y trouvent des défauts, mais, même s'ils n'y participent pas, cela leur rappelle que la critique régulière est attendue : cela doit devenir une activité constante comme faire la vaisselle ou tondre le gazon.

Dans le projet Subversion, nous n'avons pas fait au départ l'exercice d'inspection régulière du code. Nous n'avions aucune garantie que tous les commits seraient revus, même si quelqu'un pouvait de temps en temps examiner un changement car particulièrement intéressé par cette partie du code. Des bogues nous ont échappés qui auraient vraiment pu et auraient dû être vus. Un développeur, du nom de Greg Stein, qui connaissait l'importance de l'inspection du code par ses expériences passées, a décidé de montrer l'exemple en inspectant chaque ligne de chaque commit destiné au dépôt. Tout commit effectué était rapidement suivi d'un e-mail envoyé à la liste des développeurs par Greg, disséquant le commit, analysant les problèmes possibles et parfois faisant l'éloge d'un morceau de code bien écrit. Il détectait tout de suite les bogues et les habitudes non optimales d'écriture de code qui nous auraient autrement échappés. Évidemment, il ne s'est jamais plaint d'être le seul à inspecter absolument tous les commits, même si ça lui prenait une grande partie de son temps, mais il faisait l'éloge de l'inspection de code à chaque fois qu'il en avait l'occasion.

Rapidement, d'autres personnes, y compris moi-même, ont aussi commencé à inspecter les commits de façon régulière. Quelle était notre motivation ? Ce n'est pas Greg qui nous donna mauvaise conscience. Non, il nous a prouvé que passer du temps à inspecter le code est payant, et que quelqu'un peut apporter autant au projet en examinant les modifications des autres, qu'en écrivant de nouvelles lignes de code. Une fois démontré, ce fait devint la norme, à tel point que lorsqu'un commit ne recevait pas de commentaires, son auteur s'en inquiétait, et demandait même sur la liste si quelqu'un avait eu l'occasion de le contrôler. Plus tard, Greg trouva un emploi ne lui laissant plus autant de temps pour Subversion et dut arrêter ses inspections régulières. Mais à ce moment là, l'habitude était tellement ancrée parmi nous, qu'elle semblait présente depuis des temps immémoriaux.

Commencez les examens dès le tout premier commit. Les problèmes les plus simples à détecter en fouillant les diffs sont les vulnérabilités de sécurité, les fuites de mémoire, les commentaires ou la documentation API insuffisants, les erreurs de logique, les incohérences de discipline appelant/appelé et d'autres problèmes qui nécessitent peu de contexte pour être détectés. Néanmoins, même des problèmes à plus grande échelle, comme l'incapacité à réduire des schémas répétés à une seule position deviennent détectables une fois que la personne fait des inspections régulièrement, parce que se souvenir des diffs antérieurs aide à l'inspection des diffs plus récents.

Ne vous inquiétez pas si vous ne trouvez rien à commenter ou si vous n'êtes pas assez renseigné sur toutes les parties du code. Il y aura presque toujours quelque chose à dire à propos de chaque commit, même si vous ne trouvez rien à redire, vous aurez peut-être un commentaire élogieux à faire. Le plus important est de montrer à ceux qui envoient les commits que ce qu'ils font est vus et compris. Évidemment, l'inspection du code ne dispense pas les programmeurs de la responsabilité de contrôler et tester leurs changements avant de les exposer : on ne devrait pas se reposer sur l'inspection du code pour trouver les erreurs qu'on aurait dû voir soi-même.

Soyez attentifs à l'amplitude des changements lorsque vous libérez un projet fermé

Si vous libérez un projet déjà existant, sur lequel les développeurs sont habitués à travailler dans un environnement fermé, assurez vous que tout le monde comprenne qu'un grand changement se profile, essayez de vous mettre à leur place pour comprendre leurs sentiments.

Essayez d'imaginer la situation de leur point de vue : avant, toutes les décisions concernant le code et l'architecture étaient prises au sein d'un groupe où tous les programmeurs connaissaient à peu près aussi bien le logiciel, programmeurs qui étaient sous la même pression du même encadrement et qui connaissaient les forces et les faiblesses de chacun. Maintenant vous leur demandez d'exposer le code au regard d'étrangers qui se feront un jugement uniquement d'après ce qu'ils voient, sans connaître les pressions commerciales derrière telle ou telle décision. Ces étrangers poseront beaucoup de questions, des questions qui seront comme un choc pour les développeurs déjà présents qui réaliseront que la documentation sur laquelle ils se sont échinés est encore inadaptée (c'est inévitable). Pire encore, les nouveaux venus sont des inconnus, des entités sans visage. Si l'un de vos développeurs a déjà des doutes quant à ses compétences, imaginez comment ce sentiment sera exacerbé quand des nouveaux venus montreront du doigt des défauts du code qu'il a écrit, et pire encore, devant tous ses collègues. À moins que votre équipe soit composée de codeurs parfaits c'est inévitable, en fait, ça leur arrivera à tous au début. Ce n'est pas parce qu'ils sont de mauvais programmeurs, c'est juste que n'importe quel programme ayant atteint une certaine taille contient des bogues et la critique par des pairs mettra en avant certains de ces bogues (voir la section appelée « Effectuez une inspection visible du code », précédemment dans ce chapitre). À ce moment, les nouveaux venus ne seront pas exposés à la critique des pairs eux, comme ils ne peuvent pas participer à la programmation tant qu'ils ne sont pas familiers avec le projet. Vos développeurs auront l'impression que la critique ne va que dans un sens. Il y a donc un risque qu'une mentalité d'assiégé se développe au sein des « anciens ».

Le meilleur moyen d'éviter ceci, est de tous les prévenir de ce qui les attend, expliquez, dites leur que l'inconfort du début est parfaitement normal et assurez les que les choses iront en s'améliorant. Certains de ces avertissements devraient être faits en privé, avant que le projet ne soit ouvert. Mais vous pourrez aussi trouver utile de rappeler aux gens sur les listes publiques que c'est une nouvelle phase du développement du projet et qu'il y aura un certain temps d'adaptation. La meilleure chose que vous puissiez faire est de donner l'exemple. Demandez aux développeurs de répondre plus aux questions de débutants, si vous vous rendez compte qu'ils ne le font pas suffisamment, n'améliorera pas les choses. Ils n'ont pas forcément déjà une idée claire des questions qui requièrent une réponse ou pas, ou il se peut qu'ils ne sachent pas comment répartir leur temps entre le travail de programmation et leur nouvelle charge de communication externe. Afin de les faire participer, il faut que vous participiez vous même. Soyez présent sur les listes de diffusion publiques et répondez à quelques questions posées par ce biais. Si vous n'avez pas la connaissance requise pour répondre à une question, alors transmettez là à un développeur qui saura y répondre, et ce de manière visible à tous. Assurez vous qu'il fournisse une solution, ou qu'au moins il réponde. Il sera tentant pour les développeurs qui ont participé de longue date de retomber dans des discussions privées, c'est naturel puisqu'ils y sont habitués. Assurez vous de faire partie de la liste de diffusion interne sur laquelle cela peut se passer, ainsi vous pouvez demander à ce que ce genre de discussion soit déplacée sur les listes publiques immédiatement.

Il y a d'autre préoccupations sur le long terme lorsque vous rendez public un projet précédemment fermé. Le Chapitre 5, L'argent explore des techniques pour faire cohabiter avec succès des développeurs salariés et bénévoles et le Chapitre 9, Licences, droits d'auteur et brevets traite de l'attention légale que vous devez porter lorsque vous rendez libre un code propriétaire pouvant contenir des logiciels écrits ou « détenus » par d'autres parties.

Annoncer

Une fois que le projet est présentable, pas parfait, juste présentable, vous êtes prêt à l'annoncer au monde entier. C'est en fait un processus très simple : allez sur http://freshmeat.net/, cliquez sur « Submit » (Soumettre) en haut de la barre de navigation et remplissez un formulaire pour annoncer l'existence de votre nouveau projet. C'est sur Freshmeat que tout le monde se rend pour surveiller les annonces concernant les nouveaux projets. Vous devrez attirer l'attention de quelques paires d'yeux ici pour que le bouche à oreille à propos de votre projet commence.

Si vous connaissez des listes de discussion ou des newsgroups où l'annonce de votre projet cadrerait avec le sujet et apporterait quelque chose alors écrivez-y. Mais prenez garde de faire exactement un sujet par forum et de rediriger les gens vers le forum de votre projet pour poursuivre la discussion (en modifiant « Répondre à » dans l'en-tête). Le message se doit d'être court et d'aller directement au but :

À : discuss@lists.example.org

Sujet : [ANN] Projet Scanley d'indexation de textes complets

Répondre à : dev@scanley.org

Ceci est un message ponctuel pour annoncer la création du projet Scanley, un outil d'indexation de texte complet, Open Source, ainsi qu'un moteur de recherche avec une API riche, à l'usage des programmeurs afin de permettre un service de recherche pour de grandes quantités de documents écrits. Scanley est fonctionnel, en cours de développement intense et recherche des développeurs et des testeurs.

Site internet : http://www.scanley.org

Fonctionnalités :

* Recherche de texte brut, HTML et XML

* Recherche de mot ou de phrase

* (prévu) Correspondance approximative

* (prévu) Mise à jour incrémentale des indexes

* (prévu) Indexation de sites Web distants

Pré-requis:

* Python 2.2 ou supérieur

* Suffisamment d'espace disque pour contenir les indexes (approximativement 2x la taille d'origine des données)

Pour de plus amples informations, visitez scanley.org.

Merci,

-A.Nonyme

(Voir la section appelée « Publicité » dans le Chapitre 6, Communication, vous y trouverez des conseils concernant l'annonce des futures versions et autres évènements liés au projet.)

Il y a un débat actuellement dans le monde du logiciel libre, doit-on commencer avec un code fonctionnel ou est-il plus profitable pour le projet d'être rendu public même pendant la période de conception/discussion ? Avant je pensais que commencer un projet avec un code qui marche était le facteur le plus important, que c'était ce qui séparait les projets réussis des gadgets et que les développeurs sérieux ne seraient attirés que par des logiciels qui réalisent déjà quelque chose de concret.

Finalement ce n'est pas toujours le cas. Pour le projet Subversion nous avons commencé avec un modèle, un cœur de développeurs intéressés et proches, beaucoup de paillettes et absolument pas de code. À ma grande surprise, le projet a rassemblé des participants actifs dès le début, et au moment où nous avions quelque chose de fonctionnel, il y avait déjà quelques volontaires très impliqués dans le projet. Subversion n'est pas le seul exemple, le projet Mozilla a également commencé sans code fonctionnel, et maintenant c'est un navigateur Internet populaire qui rencontre beaucoup de succès.

Face à de telles preuves, j'ai dû revoir ma position sur le fait qu'un code fonctionnel est absolument nécessaire pour lancer un projet. Un code fonctionnel reste la meilleure base du succès, et l'expérience voudrait qu'on attende de l'avoir avant d'annoncer la création du projet. Quoiqu'il en soit, certaines circonstances font qu'une annonce anticipée a du sens. Je pense en effet qu'un modèle bien fait, ou une sorte de trame pour le code est nécessaire, évidemment il peut être retouché selon les critiques publiques, mais il faut proposer quelque chose de concret auquel les gens pourront se raccrocher, quelque chose de plus tangible que de bonnes intentions.

Chaque fois que vous annoncez, ne vous attendez pas à voir débarquer ensuite une horde de volontaires désirant joindre le projet. En général, le résultat de votre annonce sera la réception de quelques questions désinvoltes, quelques personnes supplémentaires joindront les listes de diffusion, et, à part cela, les choses continueront comme avant. Mais avec le temps, vous remarquerez une augmentation progressive de la participation à la fois des développeurs et des utilisateurs. Annoncer, c'est comme planter une graine. La nouvelle peut mettre du temps à se répandre. Si le projet récompense systématiquement ceux qui s'investissent, la nouvelle se répandra malgré tout, parce que les gens parlent quand ils ont bien aimé quelque chose. Si tout se passe bien, les lois exponentielles des réseaux de communications transformeront doucement votre projet en une communauté complexe, où vous ne connaîtrez pas forcément chacun par son nom, et où vous ne pourrez plus suivre toutes les discussions. Les prochains chapitres traiteront du travail dans cet environnement.

[10] Nous n'en sommes pas encore aux remerciements, mais je vais déjà mettre en pratique ce que je prêcherai plus tard : l'observateur était Brian Behlendorf et c'est lui qui a signalé l'importance de maintenir toutes les discussions publiques à moins que vous n'ayez un besoin particulier de confidentialité.

[11] C'est en général comme ça que se passe l'inspection du code dans les projets Open Source dans tous les cas. Dans des projets plus centralisés, « inspection du projet » peut aussi désigner une assemblée de gens s'asseyant autour d'une table pour relire des copies du code source, à la recherche de problèmes et de formules particulières.

---

Chapitre 1 : Introduction

Page d'accueil du projet

Chapitre 3 : Infrastructure technique