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.