Guide pratique de la conduite de projet logiciel libre
Version française du Free Software Project
Management HOWTOBenjamin"Mako"Hillmako CHEZ debian POINT orgSylvainLévesqueTraduction de la version françaiseslevesque CHEZ gezere POINT comTillyBayard-RichardTraduction et Relecture de la version françaisetilly POINT bayardrichard CHEZ free POINT frMichelBelleauRelecture de la version françaisemichel POINT belleau CHEZ malaiwah POINT comMichaelGagnonRelecture de la version françaisemgagnon CHEZ gezere POINT comRaphaelRousseauRelecture de la version françaiseraphael POINT rousseau CHEZ r4f POINT frVersion : 0.3.2.fr.0.0.0[UN JOUR EN 200666666]0.3.2.fr.0.0.0[2004-0?-??]SLVersion initiale françaisev0.3.22002-04-15BCHv0.3.12001-06-18BCHv0.32001-05-05BCHv0.2.12001-04-10BCHv0.22001-04-08BCHv0.012001-03-27BCH
Version initiale
(Initial Release)
fswd
Ce guide pratique est rédigé à l'attention de
développeurs expérimentés qui possèdent
des compétences dans la conduite de projet logiciel, mais
qui ne connaissent pas encore le monde du logiciel libre.
Ce guide pratique a pour objectif de faire découvir les aspects non
techniques du développement de projet logiciel libre. Il a
été conçu pour servir de manuel de formation
rapide à des méthodes qui ne sont pas
enseignées au personnel des entreprises d'ingénierie
informatique traditionnelles, mais qui feront qu'un projet
logiciel libre pourra être un succès si elles sont
suivies, ou un échec dans le cas contraire.
Introductionfswd!introduction
En parcourant freashmeat.net, on découvrira un tas de
justifications à l'existence du pré guide
pratique. L'Internet est pollué d'innombrables programmes
utiles écrits avec talent mais qui sont tombés dans
l'insondable décharge de l'univers des oubliés du
logiciel libre. Cette image de désolation m'a fait me demander
à moi-même, mais pourquoi tant
d'injustice ?
Ce guide essaie de dire beaucoup de choses (sans doute trop), mais
il ne répond pas à cette question, et ne tente
même pas de le faire. Par contre, il va essayer de vous
donner une chance supplémentaire de réussir votre
projet logiciel libre.
Si vous écrivez mal un bout de code dont personne n'a
besoin, vous pourrez bien relire ce guide jusqu'à pouvoir le
réciter par coeur dans vos rêves, votre projet sera
vraissemblablement un échec. A contrario, écrivez une
petite merveille de composant logiciel qui suive à la lettre
chacune des instructions du présent guide, et votre oeuvre
pourrait tout aussi bien finir au pilon. C'est la dure loi de
l'existence. Je serai sans doute le seul de mon avis en disant
cela, mais produisez du code utile et d'excellente qualité
en faisant fi des conseils de ce guide, et alors vous aurez
probablement bien plus de chances
d'échouer.
Une grande part des informations dans ce guide relève du
simple bon sens. Bien sûr, comme le prouvent toutes les
discussions à propos d'interfaces, ce qui est du bon sens
pour les uns, apparaîtra comme totalement artificiel et
compliqué aux autres. Après avoir testé
à plusieurs occasions, le contenu de ce guide auprès
de spécialistes du logiciel libre, j'ai compris que ce guide
pourrait servir utilement comme base de discussion et
d'échange entre développeurs pour partager leur
expérience de ce qui marche ou ne marche pas pour eux.
Comme quiconque qui s'est déjà trouvé
embarqué dans une de ces interminables successions
d'histoires ridicules de propriété intellectuelle,
l'atestera, une petite dose de juridique s'avère d'importance
capitale.
Droits d'utilisation et Licence
Le texte ci-dessous est la version française de ce
document. Seule la version originale de cette licence,
présentée à la section suivante, fait foi.
Copyright (c) 2000, 2003 Benjamin "Mako" Hill
Vous êtes autorisé à copier, distribuer ou
modifier la version originale de ce document selon les termes de la
licence de documentation libre GNU (GFDL), version 1.1 ou
ultérieure, telle que publiée par la Free Software
Foundation ; sans section invariante, sans texte de
première de couverture ni texte de quatrième de
couverture.
Une copie en anglais de cette licence est incluse à la fin
de ce document (cf. ). Une traduction
française officieuse de cette licence est disponible sur
http://cesarx.free.fr/gfdlf.html.
La version française de ce document a été
réalisée par Tilly Bayard-Richard [, ET AL.]. Elle est
publiée en accord avec les termes de la licence de
documentation libre GNU (GFDL) version 1.1 ou ultérieure,
telle que publiée par la Free Software Foundation ;
sans section invariante, sans texte de première de
couverture, ni texte de quatrième de couverture.
Une copie en anglais de cette licence est incluse à la fin
de ce document (cf. ). Une traduction
française officieuse de cette licence est disponible sur
http://cesarx.free.fr/gfdlf.html.
Copyright and License
Le texte ci-dessous est la licence de ce document. Ce texte fait
foi. Il est composé de la licence (en anglais) du document
original, suivi de la licence (en français) de sa traduction.
This document is copyrighted (c) 2000 Benjamin "Mako" Hill
and is distributed under the terms of the GNU Free
Documentation License.
Permission is granted to copy, distribute and/or modify this
document under the terms of the
GNU
Free Documentation License
, Version 1.1 or any
later version published by the Free Software Foundation with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license can be found in .
Copyright (c) 2004 Tilly Bayard-Richard [, ET AL.] pour la version
française.
La version française de ce document a été
réalisée par Sylvain Lévesque [, ET AL.]. Elle est
publiée en accord avec les termes de la licence de
documentation libre GNU (GFDL) version 1.1 ou ultérieure,
telle que publiée par la Free Software
Foundation ; sans section invariante, sans texte de
première de couverture, ni texte de quatrième de
couverture.
Une copie en anglais de cette licence est incluse à la fin
de ce document (cf. ). Une traduction
française officieuse de cette licence est disponible sur
http://cesarx.free.fr/gfdlf.html.
Mise en garde
Le texte ci-dessous est la version française de la mise en
garde de ce document. Seule la version originale de cette mise en
garde, présentée dans la section suivante, fait foi.
Aucune responsabilité ne pourra être retenue,
basée sur le contenu de ce document.
L'utilisation des concepts, des exemples, et de toute autre
information est sous l'entière responsabilité du
lecteur et à ses propres risques. S'agissant d'une
édition intermédiaire du document, il peut contenir
des erreurs et des inexactitudes qui pourraient être
préjudiciables au projet du lecteur (et par conséquent
pour son système). Soyez prudents, car bien que le risque
soit faible, l'auteur ne prend aucune part de
responsabilité en cas de problème de cet ordre.
Les copyrights sont détenus par leurs propriétaires
respectifs, sauf mention contraire. L'utilisation d'un terme du
langage courant ne doit pas être considérée
comme pouvant être opposé à une marque
commerciale de produit ou de service.
La citation de produits commerciaux ou marques
particulières ne doit pas être
considérée comme une appropriation.
Disclaimer
Le texte ci-dessous est la mise en garde de ce document. Ce texte
fait foi.
No liability for the contents of this documents can be accepted.
Use the concepts, examples and other content at your own risk. As
this is a new edition of this document, there may be errors and
inaccuracies, that may of course be damaging to your project (and
potentially your system). Proceed with caution, and although this
is highly unlikely, the author(s) does not take any responsibility
for that.
All copyrights are held by their by their respective owners, unless
specifically noted otherwise. Use of a term in this document
should not be regarded as affecting the validity of any trademark
or service mark.
Naming of particular products or brands should not be seen
as endorsements.
Nouvelles versions
La présente version fait partie de la troisième
étape de publication expérimentale de ce guide
pratique. Elle est publiée pour revue critique par des
développeurs. Merci de ne pas oublier que la
présente version de ce guide pratique en est encore
à ses premiers balbutiements, et sera encore
considérablement révisée dans le futur.
La référence de la dernière version sera
toujours signalée sur la page de projets
hébérgée par yukidoke.org..
La version la plus à jour de ce guide pratique sera toujours accessible sur ce même site internet, dans différents formats :
HTML.
HTML (en une seule page).
Texte simple.
Postscript compressé.
Code natif SGML compressé.
Remerciements
Dans cette version, j'ai le plaisir d'exprimer ma reconnaissance
à :
Mes compagnons de développement Debian, Martin Michlmayr et
Vivek Venugopalan qui m'ont fourni des informations et des liens
vers des articles trè intéressants. Je les ai
signalés dans la bibliographie et j'ai inclu des
informations qu'ils contiennent dans ce guide pratique.
Merci à Andrew Shugg qui m'a signalé plusieurs
erreurs dans le document. également, merci beaucoup à
Sung Wook Her (alias RedBaron) qui effectue la première
traduction en coréen. Je suis content de voir que des
personnes ont déjà apprécié et
tiré bénéfice de mon guide pratique.
D'autres remerciements plus anciens mais que je veux continuer
à inclure ici vont à : Josh Crawford, Andy King,
et Jaime Davila qui ont tous lu intégralement ce travail, et
m'ont fait des commentaires qui m'ont aidés à
améliorer la qualité de ce document. Messieurs, je ne
pourrais jamais vous remercier assez pour votre aide. Un
merci tout particulier pour Andy King qui l'a lu et
relu plusieurs fois, et m'a facilité la vie en me
fournissant des kits de modification
(patches).
Karl Fogel, l'auteur avec Moshe Bar de Open Source
Development with CVS publié par
Paraglyph. La seconde édition (mai 2003)
est disponible dans son intégralité en PDF sur Internet, sous licence
GPL. Les chapitres consacrés à CVS en font le
meilleur manuel sur ce système que j'ai jamais vu. Le reste
de l'ouvrage traite des défis et des positions
philosophiques propres au fonctionnement d'un projet Open Source
avec CVS. Cet ouvrage couvre parfaitement quelques un des sujets
mis en lumière dans le présent guide pratique, et
d'autres encore qui ne sont pas abordés ici. Le site du livre donne aussi
accès à plusieurs traductions des chapitres sur CVS
de la première édition publiée en 1999 par
Coriolis Open Press. Si vous êtes véritablement
motivé pour démarrer un projet logiciel libre, il
faut vous procurer ce livre. Je me suis efforcé de citer
Fogel dans les sections du présent guide pratique, là
où je savais que je m'inspirais directement de ses
idées. Si j'ai oublié de le faire à certains
endroits, je m'en excuse. Je ferai de mon mieux pour réparer
ces ommissions dans les versions futures.
Pour envoyer un message à Karl Fogel :
kfogel CHEZ red-bean POINT com
M'ont également fourni des arguments précieux et
l'inspiration pour écrire ce guide pratique : Eric
S. Raymond, grâce à sa dialectique savante et
parfaitement maîtrisée, et Lawrence Lessig qui m'a
fait prendre conscience de l'importance du logiciel libre. Je veux
aussi remercier les utilisateurs et les développeurs qui
travaillent au projet
Debian. Ce projet m'a offert un espace où j'ai pu
m'exercer à défendre la cause du logiciel libre, pour
exprimer sa différence, un terrain où profiter de
l'expérience de ceux qui ont participé au mouvement
depuis bien plus longtemps que moi, et donner la preuve qu'un
projet logiciel peut absolument fonctionner, vraiment.
Et surtout, je veux remercier Richard
Stallman pour son oeuvre à la Free Software
Foundation, et pour ne jamais avoir renoncé. C'est Stallman
qui a établit les fondements philosophiques qui m'ont
conduit à écrire ce document pour assurer encore
mieux la réussite des projets logiciels libres.
Pour envoyer un email à Richard Stallman :
rms CHEZ gnu POINT org.
Commentaires
Les commentaires concernant ce document sont toujours les
bienvenus. Sans vos soumissions, ce document n'existerait pas. Vous
pensez que quelquechose manque ? écrivez-moi pour me
demander de rédiger un nouveau chapitre ou une section, ou
mieux, rédigez les vous-même. Je souhaite que ce
document soit le résultat d'un développement de
documentation selon le modèle du logiciel libre, et qu'il en
soit un emblème. Je suis convaincu que l'étendue de
son audience dépend de notre capacité à y
parvenir. SVP, envoyez vos ajouts, commentaires et critiques, en
anglais, à l'adresse suivante : mako CHEZ debian
POINT org.
N'hésitez pas à faire parvenir tout commentaire
relatif à la version française de ce document
à commentaires CHEZ traduc POINT org.
Traductions
Je sais bien que tout le monde ne parle pas l'anglais. Les
traductions dans une langue étrangère sont
formidables et j'aimerais que ce guide pratique gagne l'audience
internationale que seules des versions traduites peuvent l'aider
à obtenir.
J'ai été contacté par un lecteur qui promet
une traduction en coréen. Toutefois ce guide pratique est
encore un peu jeune, et à part le coréen promis,
seuls l'anglais et le français sont disponibles pour le
moment. Si vous voulez nous aider en faisant une traduction dans
une autre langue, vous aurez droit à mon profond respect et
à mon admiration, et vous deviendrez un acteur à part
entière d'une histoire passionnante. Si cela vous
intéresse, n'hésitez pas à
m'écrire : mako CHEZ debian POINT org.
Lancer un projetfswd!starting
Sans aucune discussion possible, le lancement est la phase de la vie
d'un projet qui est la plus difficile à réussir en
termes de conduite et gestion de projet logiciel libre. Construire
sur des bases solides est déterminant pour que votre projet
s'épanouisse au lieu de décliner et mourir. C'est
aussi ce qui est d'intérêt le plus immédiat pour
qui veut se servir du présent document comme d'un guide de
mise en pratique.
Lancer un projet vous place au coeur d'un dilemne, qu'il vous
faudra résoudre en tant que développeur : aucun
utilisateur potentiel de votre programme n'est
intéressé par du code qui ne fonctionne pas encore,
alors que le processus de développement que vous voulez
mettre en oevre implique impérativement la
participation d'utilisateurs.
C'est à l'occasion de cette initialisation difficile et
risquée qu'une personne ayant décidé de lancer
un projet logiciel libre devra essayer de touver un
équilibre entre différentes voies.L'un des moyens les
plus sûrs pour quelqu'un qui lance un projet de trouver cet
équilibre, c'est de fixer un cadre solide pour le processus
de développement du projet, à choisir parmi les
différentes pistes que je propose dans de cette section.
Choisir un projet
Si vous êtes en train de lire ce document, c'est presque
certainement parce que vous avez en tête une idée de
projet. Il y a aussi de fortes chances pour que cela soit pour
combler ce que vous pensez être un manque et faire quelque
chose qu'aucun autre projet logiciel libre ne fait
déjà, ou faire quelque chose d'une façon
suffisamment originale pour rendre nécessaire le codage d'un
composant logiciel innovant.
Identifier et structurer votre idée de projet
Eric S. Raymond décrit comment les projets logiciels libres
démarrent, dans son essai
NdT : version originale en anglais : The Cathedral and the Bazaar, Eric S. Raymond.
, traduit en français par Sébastien Blondel :
La
cathédrale et le bazar. La
lecture de ce texte est absolument indispensable pour tout
développeur de projet logiciel libre. Il est disponible
en-ligne.
Dans La cathédrale et le
bazar, Eric Raymond nous dit :
Tout bon logiciel commence par gratter un développeur
là où ça le
démange. L'hypothèse que fait Eric Raymond et
qui est maintenant largement acceptée, c'est que les nouveaux
logiciels libres sont écrits, d'abord et avant toute chose,
pour résoudre un problème particulier qu'un
développeur a rencontré.
Si vous avez en tête l'idée d'un logiciel, il y a de
fortes chaces que cela vise à traiter un problème
précis, une démangeaison que vous
souhaitez calmer. Le projet, c'est cette
idée. Structurer-la
clairement. Rédigez-la. Décrivez en détail le
problème que vous aller attaquer. La réussite de
votre projet à venir à bout d'un problème
donné dépend de votre capacité à
identifier clairement et très tôt ce
problème. Définissez exactement ce que vous voulez
que votre projet fasse.
Comme nous le verrons à la section suivante, il y a beaucoup
de choses à faire avant même de commencer à
écrire la première ligne de code. Montey Manley dit
dans un essai que Démarrer un projet Open Source
implique qu'avant toute chose, le développeur se garde
bien de coder trop tôt !.
Valider votre idée
Pour valider votre idée, il faut d'abord vous poser quelques
questions à vous-même. Vous devrez le faire avant
d'aller plus loin dans la lecture de ce guide
pratique. Demandez-vous : Est-ce que le modèle de
développement du logiciel libre est vraiment celui qui
convient pour mon projet ?
Apparemment, puisque vous l'envie de ce programme vous
démange, vous êtes vraiment motivé pour en
faire du code exécutable. Mais parce qu'un
développeur codant tout seul dans son coin, ce n'est pas ce
qui fait un développement logiciel libre, il faut vous poser
cette deuxième question : Qui d'autre cela
intéresse-t-il ?
Parfois, la réponse est tout simplement
personne. Si vous avez l'intention d'écrire
une série de scripts pour organiser votre
collection MP3 sur votre machine, alors, le modèle
de développement du logiciel libre n'est pas le bon
choix. Cependant, si vous voulez écrire une série de
scripts pour organiser une collection MP3 pour tout un
chacun, alors, un logiciel libre pourrait bien convenir
pour répondre au besoin.
Heureusement, l'Internet est si vaste et si divers qu'il existe
toujours une chance pour que quelqu'un, quelque part, partage votre
intérêt et ressente le même
besoin. C'est justement parce qu'il y a tant de personnes
qui partagent les mêmes besoins et attentes qu'il faut vous
poser la troisième question importante : Est-ce
que quelqu'un d'autre a déjà eu la même
idée avant moi, ou une autre qui lui ressemble ?.
A la recherche des projets similaires
Il faut aller sur des sites internet pour chercher et trouver des
réponses à la question précédente. Si
vous fréquentez déjà la communauté du
logiciel libre, vous connaissez bien la plupart de ces
adresses. Tous les sites cités ci-dessous, disposent d'un
moteur de recherche :
freshmeat.netfreshmeat.net
se décrit comme étant l'index le plus
complet des logiciels Linux et Open Source, sur
Internet ; sa réputation en la
matière est parfaitement irréfutable et
inégalable. Si vous ne trouvez pas sur freashmeat, il
est fort peu probable que vous ou qui que ce soit d'autre,
trouviez ailleurs.
SlashdotSlashdot
dont la devise en anglais est News for
Nerds. Stuff that matters , ce
qui peut se traduire par L'info pour les fondus. Les
trucs vraiment importants, comporte
généralement des discussions sur le logiciel
libre, l'open source, les technologies, et des infos sur les
événements culturels associés. Il est
d'usage que les projets de développement innovants y
soient annoncés, c'est pourquoi il est vraiment
important de le consulter.
SourceForgeSourceForge
héberge et soutient un nombre de plus en plus
important de projets logiciels libres et open source. Ce site
devient rapidement le point de passage obligé pour
tout développeur de logiciel libre. Il faut absolument
passer par les pages qui présentent
la cartographie des logiciels et
les distributions récentes
avant de lancer un nouveau projet logiciel libre. SourceForge
fournit aussi une
librairie de snippets
qui contient des morceaux de code réutilisables, avec un choix
possible de langages de programmation, qui
peuvent s'avérer très utiles pour tout projet.
Google et le moteur de recherche Linux sur GoogleGoogle et
le moteur de recherche Linux
,
offrent de puissantes fonctions de recherche sur Internet qui
peuvent montrer que plusieurs personnes travaillent en
parallèle sur des projets similaires. Il ne s'agit pas
de catalogues de logiciels ou de recueils d'information comme
freashmeat et Slashdot, mais cela vaut la peine de
vérifier que vous ne gaspiller pas vos efforts sur un
projet en double.
Prendre la décision
Une fois que vous avez bien exploré le terrain, et que
vous avez une idée des projets logiciels libres
similaires qui existent, vous aurez besoin de prendre la
décision de mener votre propre projet, ou non. Il est
rare de poursuivre un objectif qui ne soit pas plus ou moins
ressemblant ou en relation avec un autre. Toute personne
démarrant un nouveau projet doit se demander :
Est-ce que mon nouveau projet duplique ce qui est fait
dans un autre projet ? Est-ce que mon nouveau projet entre
en compétiton avec un projet existant ? Est-ce que
les objectifs de mon nouveau projet pourraient être atteints
en complétant les fonctionalités d'un projet
existant ?.
Si la réponse à l'une de ces questions est
oui, prenez contact avec le développeur du
projet existant concerné pour voir si il est d'accord
pour travailler avec vous.
Pour beaucoup, se sera sans doute la principale
difficulté dans la conduite d'un projet de logiciel
libre, mais c'est primordial. Il est très facile de
s'emballer pour une idée et de se laisser embarquer par
l'excitation et l'enthousiasme dans un nouveau projet. Ce sera
souvent extrêmement douloureux, mais il est important que
tout développeur de logiciel libre soit bien conscient
que l'intérêt de la communauté du logiciel
libre, et la meilleure façon d'atteindre les objectifs de
son projet, et de ceux qui lui ressemblent, c'est souvent de
prendre la décision de ne pas
démarrer un nouveau projet de développement.
Donner un nom à votre projet
Tout en reconnaissant qu'il y a un tas de projets qui
échouent alors qu'ils portent des noms bien choisis, et
plein d'autres qui réussissent alors qu'ils sont mal
nommés, je pense que cela vaut la peine de se donner un peu
de mal pour baptiser son projet. Leslie Orchard traite cette
question dans un article
Advogato.
Son article est court et vaut vraiment la peine d'être parcouru.
En résumé Orchard vous recommande de choisir un nom
tel que, après l'avoir entendu, de nombreux utilisateurs ou
développeurs pourront instantanément :
savoir ce que le projet couvre,s'en souvenir le lendemain.
Plaisamment, le project de Orchard, Iajitsu,
n'obéit à aucun de ces critères. C'est
probablement sans rapport, si le développement du projet
s'est arrêté depuis la publication de l'article !
N'empêche qu'il touche juste sur un point. Il existe des
entreprises dont le seul service est de fabriquer des noms pour des
logiciels. Elles gagnent des sommes faramineuses dont elles ne
semblent pas avoir à rougir. Alors que vous ne pourrez
jamais vous offrir les prestations d'une entreprise de ce type,
vous pouvez bien vous inspirer de ce qu'elles font et
réfléchir un peu au nom que vous allez donner
à votre projet, parce que cela est
vraiment important.
Si vous avez un nom auquel vous tenez, mais qu'il ne satisfasse pas
les critères de Orchard, ne vous arrêtez pas pour
autant. J'ai toujours pensé que gnubile
était le meilleur nom que j'ai jamais entendu pour un projet
logiciel libre, et j'en parle encore, même très
longtemps aprè avoir utilisé le logiciel pour la
dernière fois. Toutefois, si vous avez un certain
degré de liberté, suivez les conseils d'Orchard. Cela
pourrait vous aider.
Distribuer votre logiciel sous licence
Vue de très loin, la différence entre un logiciel
libre et un logiciel propriétaire, c'est la licence. C'est
la licence qui va aider le développeur que vous êtes
en protégeant les droits que vous détenez de
distribuer votre code selon vos propres termes, et qui va vous
permettre de faire savoir à tous ceux qui peuvent vous
aider, vous ou votre projet, que vous les encouragez à le
faire.
Choisir un type de licence
N'importe quelle discussion à propos de licence va à
coup sûr produire un débat plus ou moins
animé, car des opinions fortes prévalent pour le
choix de telle ou telle autre licence logicielle. Et avec la
question de l'Open Source viendront aussi les
arguties autour des termes logiciel open source et
logiciel libre. Quoi qu'il en soit, et parce que
j'écris le guide pratique de conduite de projet logiciel
libre, et non le guide pratique de conduite de projet open source,
mon opinion sur la question est de notoriété
publique.
Dans ma tentative diplomatique pour trouver un terrain d'entente
sans renier ma propre conviction, je vous recommande de choisir
une licence basée sur
Les
principes du logiciel libre selon Debian
(DFSG, pour Debian Free
Software Guidelines). Initialement
rassemblés par Bruce Perens pour le projet Debian, les
DFSG ont été adoptés
comme base pour la première version de la
Définition de l'Open Source
(OSD pour Open Source
Definition).
Les exemples de licences libres que l'on trouve dans les
DFSG sont la licence GPL
(pour General Public License), la
licence BSD (pour Berkley System
Distribution), et la licence artistique. Ainsi que
le recommande Eric Raymond dans son guide , ne rédigez pas vous-même votre
propre licence dans la mesure du possible. Les trois licences que
j'ai citées bénéficient d'importants et longs
historiques en matière d'interprétation. Ce sont
clairement des licences pour du logiciel libre (et elle peuvent de
cette façon être distribuées au sein du projet
Debian, ou dans d'autres endroits qui autorisent la diffusion de
logiciel libre).
Conformément à la définition du logiciel libre donnée par Richard Stallman dans
Qu'est-ce
qu'un Logiciel Libre?
n'importe laquelle de ces licences fonde la liberté
pour les utilisateurs d'exécuter, de copier, de distribuer,
d'étudier, de modifier et d'améliorer le
logiciel. Il existe beaucoup d'autres licences qui sont
également conformes aux DFSG, mais
s'appuyer sur une licence réputée vous offrira
l'avantage d'être immédiatement reconnu et
compris. Beaucoup de personnes rédigent trois ou quatre
phrases dans un fichier LICENCE et sont
persuadées d'avoir écrit une licence pour du logiciel
libre. Croyez-en ma longue habitude des échanges de type
juridique pour Debian, ceci est le plus souvent totalement faux.
Pour aller un peu plus loin, je suis d'accord avec la
classification des licences en deux groupes, que propose Karl
Fogel : celles qui sont du type GPL, et
celles qui ne sont pas du type GPL.
Personnellement, tous mes logiciels sont sous licence
GPL. Créée et
protégée par la Free Software Foundation et le projet
GNU, la licence GPL est celle du noyau Linux, de
GNOME, Emacs, et de la très large majorité des
logiciels GNU/Linux. C'est un choix d'évidence, mais je
pense aussi que c'est un bon choix. Tout fan de BSD vous avertira
du caractère viral de la licence GPL qui
empêche de pouvoir combiner du code sous
GPL avec du code qui n'est pas sous
GPL. Pour de nombreuses personnes (dont
moi-même), ceci est un avantage, mais pour d'autres, c'est un
inconvénient majeur.
Comme je l'ai déjà signalé, beaucoup de
personnes rédigent trois ou quatre phrases dans un fichier
LICENCE et sont persuadées d'avoir
écrit une licence pour du logiciel libre. Croyez-en ma
longue habitude des échanges de type juridique pour Debian,
ceci est le plus souvent totalement faux. Cela peut ne pas vous
protéger du tout, ne pas protéger votre logiciel, et
rendre les choses extrêmement difficiles pour les gens qui
veulent utiliser votre code et qui font très attention aux
mentions légales subtiles que l'on trouve dans les
licences. Si la fabrication artisanale de licences est votre
passion, faites-la valider par quelqu'un de
OSI (Open Source Initiative)
ou par la liste de diffusion
debian-legal
list.
Il faut en tout premier lieu vous protéger des effets
secondaires non anticipés de votre licence.
Les trois principales licences sont disponibles aux adresses suivantes :
la licence GNU
GPL (General Public License)
Seul le texte original en anglais de la licence GPL fait foi. Une
traduction non-officielle en français de la licence GPL est
disponible pour
information seulement.
la licence
BSDla licence artistique
Dans tous les cas, prenez soin de lire attentivement une
licence avant de distribuer votre logiciel suivant ses termes. En
tant que principal développeur, vous ne pouvez pas vous
permettre de tomber dans un quelconque piège juridique par
ignorance.Le mécanisme de la licence
Le texte de la GPL offre une bonne
description sur la façon appropriée d'appliquer une licence
à un bout de code. Voici les points à vérifier lors de
l'application d'une licence.
Faites-vous vous-mêmes ou le FSF le propriétaire des
droits de licence. à la place, dans de très rares cas, vous pourriez vouloir
donner les droits de licence à une organisation (Si c'est assez gros
et puissant). Faire cela est aussi simple que de mettre le nom dans
l'espace blanc dans l'avis des droits de licence çi-bas. Contrairement
à la pensée populaire, vous n'êtes pas tenu d'inscrire un nom d'organisation.
L'avis seule est suffisante à protéger votre travail.
Autant que possible, attachez et distribuez une copie complète
de la licence avec votre code source et vos fichiers exécutables
en l'incluant dans un fichier séparé.
Au début de chaque fichier de code source de votre programme,
inscrivez un avis de droits réservés et notez l'endroit où l'on
peut trouver la licence complète. La GPL recommande
que chaque fichier commence par:
Une ligne pour donner le nom du programme et une idée de ce qu'il accomplit.
Tous droits réservés (C) AAAA 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.
La GPL recommande d'inclure les coordonnées
de l'auteur via courriel ou adresse postal.
La GPL suggère aussi, pour les programmes
s'exécutant en mode intéractif, d'afficher un avis de droit
de licence lors de chaque exécution de celui-çi. Cet avis, tel
celui çi-bas, doit indiquer où l'on peut trouver la licence complète:
Gnomovision version 69, Tous droits réservés (C) AAAA nom de l'auteur
Gnomovision vient avec AUCUNES GARANTIES; Pour plus de détails
tapez `show w'. Ceci est un logiciel libre et vous êtes libre de le
redistribuer sous certaines conditions; tapez `show c' pour plus de détails.
Finalement, il peut être utile d'inclure une section limitations
de responsabilité d'un employeur ou d'une école si vous
travaillez comme développeur ou s'il semble que votre employeur ou votre
école pourrait vouloir argumenter sur qui détient le titre propriété
intellectuelle de votre code source. La plupart du temps ce n'est pas nécessaire mais il y a
plein de développeur de logiciels libres qui se sont mis dans le pétrin et aurait
souhaiter en avoir une.
Ultime avertissement concernant la licence
Je vous en prie, je vous en supplie, mettez votre code sous une
licence quelqu'elle soit. Cela peut
paraître sans gravité à certains dont vous
êtes, mais croyez-moi, la licence, c'est
important. Pour qu'un morceau de code soit pris dans
une distribution Debian de GNU/Linux, il faut absolument que ce
code ajouté soit sous une licence conforme aux principes
du logiciel libre selon Debian. Si votre code
n'est pas sous licence, il ne pourra pas être
distribué dans un paquetage Debian tant que vous ne le
ditribuerez à nouveau avec une licence libre. Je vous en
prie, épargnez des soucis à vous-même et aux
autres en distribuant votre code sous une licence explicite,
dè la première version.
Choisir un système de numérotation de version
Ce qui est important à propos de la numérotation des
versions, c'est que cela existe. Cela peut
paraître lourd d'insister sur ce point, mais vous seriez
surpris de voir la quantité de scripts, et de petits
programmes qui apparaissent et ne portent absolument aucun
numéro de version.
Aprè cela, la chose la plus importante dans un
systè de numérotation de version, c'est que les
numéros soient attribué dans l'ordre
croissant. Les systèmes de recherche de version
automatiques, et bon sens universel seraient totalement
désorganisés si les nuérotation de version
n'allaient pas en augmentant. Cela n'a aucune
importance que 2.1 représente un degré majeur, et
2.0.0005 un degré très minime, mais ce qui est
important c'est que 2.1 soit une version plus récente que
2.0.005.
Respectez ces deux règles simples, et vous ne risquez pas
de (trop) vous trompez. Au delà, les notions les plus
courantes du système de numérotation de version sont
les degrés majeur, mineur, et
patch. Que cela vous soit familier ou non, c'est ce
que vous expérimentez quotidiennement. Le premier nombre
est le majeur, il signale une version principale, des
modifications ou des réécritures majeures. Le second
est le mineur, il indique que des fonctionalités ont
été ajoutées ou aménagées pour
compléter une base déjà cohérente. Le
troisième est le patch, pour distinguer des versions qui
corrigent des bogues.
C'est parce que ce système est très largement
répandu, que je peux reconnaître la nature et le type
des différences entre les versions 2.4.12 du noyau Linux et
2.4.11, ou 2.2.12, et 1.2.12, sans rien connaître d'aucune de
ces distributions.
Il est possible de tordre ou de briser ces règles, et
certains le font. Mais attention, si vous le faites, quelqu'un va
en être perturbé, fera l'hypothèse que vous
vous trompez, essaiera de vous corriger, et sans doute sans
ménagements. Je respecte scrupuleusement ces règles,
et je vous exhorte à faire de même.
Plusieurs implémentations de systèmes de
numérotation de versions sont bien connues, utiles, et
valent la peine d'être observées, avant que vous ne
sortiez la première version de votre logiciel.
numérotation des versions du noyau Linux :
Le noyau Linux utilise un système tel que toute version
mineure impaire indique une distribution non qualifiée
(version de développement, ou de test), alors que toute
version mineure paire indique une version stable
(qualifiée). Arrêtons nous un instant. D'après
ce système, les noyaux 2.1 et 2.3 étaient et seront
toujours des noyaux pour développement ou test, alors que
les noyaux 2.0, 2.2 et 2.4 sont des versions plus stables et plus
validées.
Que vous prévoyez un modè de développement
hiérarchisé (décrit ), ou la distribution d'une seule version
à la fois, mon expépérience de plusieurs
projets logiciels libres, et du projet Debian, m'ont appris qu'il
est sage de mettre en place le système de
numérotation de versions de Linux.
Pour Debian, toutes les versions mineures sont
stables (2.0, 2.1, etc.). Cependant, beaucoup de personnes pensent
que la version 2.1 n'est pas stable ou est une version de
développement, et continuent à utiliser la version
précédente jusqu'à ce qu'ils soient tellement
frustrés du retard de développement qu'ils finissent
par se plaindre et rejeter le produit. Même si vous ne
distribuez que les versions mineures paires, et jamais impaires,
vous ne gênez personne, et mieux, cela causera beacoup moins
de confusion. C'est une idée à retenir.
numérotation des versions de Win :
En raison de la nature peu commune du développement
de Wine où le non-émulateur est en constante
amélioration mais ne vise pas l'atteinte immédiate
d'objectif réalisable, Wine est distribué toutes les trois
semaines. L'identification des versions de Wine suit le format
année mois jour ce qui fait que chaque
livraison porte un identificateur du type
wine-XXXXXXXX et par exemple, la
livraison du 4 janvier 2000 serait la
wine-20000104 , Pour certains projets, la
numérotation de versions, le format année mois
jour peut être parfaitement bien adapté.
numérotation des versions de Mozilla :
Si l'on observe Netscape 6 et ses versions commerciales, on verra
que le modèle de développement du projet Mozilla est
parmi les modèles de logiciel libre les plus complexes
existants. La numérotation de version du projet correspond
à l'originalité de son mode de développement.
Historiquement, le principe de la numérotation de version de
Mozilla repose sur les étapes principales de son
développement. Depuis l'origine du projet, les objectifs ont
étés classés par ordre de priorité et
organisés en feuilles de route
successives.
Les étapes principales et les objectifs tout au long de cette feuille
de route sont incrit comme des jalons. Donc, bien que Mozilla fut
compilé et distribué chaque nuit comme une version
journalière, une fois un jalon atteint, cette version
particulière est marqué comme une version majeure.
Bien que je ne connaisse pas à ce jour d'autre projet qui
utilise cette méthode, je trouve que le principe est bon et
peut être valablement utilisé pour la validation ou
pour le développement par branche d'applications complexes.
Documentation
Un nombre important d'applications logicielles libres par ailleurs
remarquables, ont périclité et disparu parce que leur
concepteur était l'unique personne qui savait comment les
utiliser de A à Z. Même si votre programme s'adresse
essentiellement à des utilisateurs très pointus
technologiquement parlant, la documentation est utile, voire
indispensable pour la pérennité de votre projet. Vous
verrez un peu plus loin à qu'il faudra
toujours que ce que vous distribuez soit utilisable. Du
code sans documentation, ce n'est pas utilisable.
Les destinataires de la documentation peuvent être
très différents les uns des autres, et il y aura
beaucoup de façons de documenter votre projet.
La documentation de votre code source pour aider au développement
par une communauté plus large est vitale mais cela est
hors du cadre de ce guide patique. Ceci étant dit, cette section vous
donneras des trucs pratiques en rapport avec la documentation destinée
aux utilisateurs.
Un mélange de traditions et de besoins ont forgé un
cadre quasi standard pour la documentation technique de la
majorité des projets logiciels libres. Il sera donc bon de
s'en inspirer. Les utilisateurs d'un côté et les
développeurs de l'autre s'attendent à trouver la
documentation par différents moyens, et il est essentiel de
fournir l'information qu'ils vont rechercher dans un format
facilement lisible, si vous espérez seulement que votre
projet décolle. Voici ce à quoi ils
s'attendent :
Pages man (alias pages de manuel de
référence)
Vos utilisateurs voudront pouvoir taper :
man le_nom_de_votre_projet
et voir s'afficher une jolie page de manuel de
référence qui mette en lumière l'utilisation
principale de votre application. Vérifiez bien que vous avez
prévu de faire cela avant de livrer votre programme.
Les pages man ne sont pas difficiles à rédiger. Il
existe une trè bonne documention
NdT : version originale en anglais : Linux
Man page HOWTO, Jens Schweikhardt.
qui explique comment faire : Man page
HOWTO. Il est disponible sur le site de traduction
en français des documents LDP
(Linux Documentation Project).
On peut également rédiger des pages de manuel avec
DocBook. à la fois parce que les pages de manuel sont vraiment
très simples et que le codage DocBook est assez nouveau, je
n'ai pas exploré cette méthode plus avant, mais
j'apprécirais beaucoup l'aide que l'on pourra m'apporter en
fournissant plus d'information sur cette façon de faire.
Documentation affichée depuis la ligne de commande
La plupart des utilisateurs s'attendent à pouvoir obtenir
une documentation de base très facilement, depuis la ligne
de commande. Dans un petit nombre de cas seulement, cette
information occupera plus d'une fenêtre (24 ou 25 lignes)
pour l'apperçu de l'utilisation de base et un descriptif
court en une ou deux phrases du programme, une liste explicative
des commandes, les principales options également
expliquées, et un pointeur vers l'endroit où trouver
une documentation plus complète si besoin. La documentation
obtenue depuis la ligne de commande pour apt-get
de Debian est un excellent exemple et un bon modèle :
apt 0.3.19 for i386 compiled on May 12 2000 21:17:27
Usage: apt-get [options] command
apt-get [options] install pkg1 [pkg2 ...]
apt-get is a simple command line interface for downloading and
installing packages. The most frequently used commands are update
and install.
Commands:
update - Retrieve new lists of packages
upgrade - Perform an upgrade
install - Install new packages (pkg is libc6 not libc6.deb)
remove - Remove packages
source - Download source archives
dist-upgrade - Distribution upgrade, see apt-get(8)
dselect-upgrade - Follow dselect selections
clean - Erase downloaded archive files
autoclean - Erase old downloaded archive files
check - Verify that there are no broken dependencies
Options:
-h This help text.
-q Loggable output - no progress indicator
-qq No output except for errors
-d Download only - do NOT install or unpack archives
-s No-act. Perform ordering simulation
-y Assume Yes to all queries and do not prompt
-f Attempt to continue if the integrity check fails
-m Attempt to continue if archives are unlocatable
-u Show a list of upgraded packages as well
-b Build the source package after fetching it
-c=? Read this configuration file
-o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
See the apt-get(8), sources.list(5) and apt.conf(5) manual
pages for more information and options.
Rendre ce type d'information disponible à l'aide des options
et est devenu une
convention GNU. La plupart des utilisateurs de GNU/Linux
s'attendent à obtenir une information de base de cette
façon, alors si vous décidez de faire
autrement, tenez-vous prêts à encourir les
foudres et les dommages qui pourraient en découler.
Fichiers
En plus des pages man et de l'aide en ligne, il y a des fichiers
particuliers où l'on recherche de l'information, surtout
dans les paquetages de code source. Dans une distribution de
sources, ces fichiers se trouvent généralement dans
le répertoire racine, ou bien dans un sous-répertoire
nommé doc ou
Documentation. Les fichiers que l'on trouve le plus
souvent à ces endroits sont :
LISEZ-MOI ou Lisez-moi ou README ou Readme
C;est un document qui contitent toutes les instructions de base
pour l'installation, la compilation et l'utilisation qui
constituent le minimum d'information nécessaire pour
lancer le programme. Un LISEZ-MOI n'est pas fait pour
s'épancher, car il doit être concis et
efficace. Un LISEZ-MOI idéal contiendra 30 lignes au
minimum et 250 au plus.
INSTALL ou Install
Le fichier INSTALL devra être beaucoup plus court que le
fichier LISEZ-MOI et devra décrire brièvement
comment construire et installer le programme. Habituellement,
le fichier INSTALL indique simplement à l'utilisateur
qu'il doit lancer :
./configure; make; make install
et signale éventuellement les options ou traitements peu
habituels qui seraient nécessaires. Dans les cas les
plus standards d'installation, et pour la plupart des
programmes, le fichier INSTALL est le plus court possible et
dépasse rarement 100 lignes.
CHANGELOG, Changelog, ChangeLog, ou changelog
Un ficher CHANGELOG devrait exister pour tout projet logiciel
libre bien géré. C'est tout simplement un fichier
qui comme son nom l'indique en anglais liste ou décrit
les changements que vous apportez à votre programme. La
manière la plus simple de tenir à jour un fichier
CHANGELOG, c'est tout simplement d'avoir un fichier avec les
sources du programme et d'ajouter en-tête du CHANGELOG
une nouvelle section à chaque nouvelle livraison pour
décrire ce qui a changé, a été
corrigé ou ajouté au programme dans cette
nouvelle version. C'est une bonne idée que de
présenter également ce CHANGELOG sur le site
internet du projet, parce que cela permet aux gens de
décider si ils doivent immédiatement changer de
version, ou bien si ils peuvent se contenter d'attendre une
prochaine modification plus importante.
NEWS
Un fichier NEWS et CHANGELOG sont similaire. Contrairement
à un fichier CHANGELOG, un fichier NEWS n'est pas nécessairement
mis à jour avec les nouvelles versions. à toutes les fois que de
nouvelles fonctionnalités sont ajoutées, le développeur, qui
en est responsable, va ajouter une note dans le fichier NEWS.
Le fichier de NEWS ne doit pas être modifié avant la nouvelle
version (il doit être mis à jour tout le long) mais c'est une
bonne idée tout de même de le regarder parce que les développeurs
oublient souvent de le garder à jour.
FAQ
Pour ceux qui le savent déjà, FAQ veut dire Foire
Aux Questions et une FAQ est justement une collection de questions. Les
FAQs ne sont pas difficile à faire. Vous avez juste à respecter la règle
suivante; si on vous pose une question ou que vous voyez une question
sur une liste de diffusion deux fois ou plus, ajouter la question (et
sa réponse) sur votre FAQ. Une FAQ est moins primordiale que les deux
fichiers que nous avons parlés précédemment mais elle peut vous sauver
du temps, être plus pratique et réduire les maux de tête qui provenant
de toute part.
Site internet
Ce n'est pas de la documentation à priori mais un bon site web
deviendra sans doute une part essentielle de votre projet de
logiciel libre. Votre site web doit permettre l'accès à votre
documentation (en HTML si possible). Il doit
aussi inclure un section pour les actualités et les événements
reliés à votre application et une section qui détaille la procédure
permettant aux gens de s'impliquer dans le développement ou le testage
de votre application et faire une invitation à tous. Il doit aussi
fournir des liens vers les listes de diffusions, des sites similaires
et fournir tous les liens directs pour télécharger votre application.
Autres conseils de documentation
Toute votre documentation doit être en format texte, ou, si votre
documentation est sur votre site web, en HTML. Tout le monde peux
visualiser un fichier texte, tout le monde à un éditeur de texte,
(presque) tout le monde peux lire du HTML. Vous êtes le
bienvenue de distribué votre documentation dans plusieurs formats
plus ou moins standards tel: PDF, PostScript, RTF. Par contre, n'oubliez
surtout pas les format texte et HTML car les gens ne seront
très fâché. Selon mon avis, les fichiers man tombent
sous cette catégorie. Il y a plein de bonne documentation GNU que les
gens ne lisent tout simplement pas parce qu'il n'est seulement
dans le format man. Et ceci fâche les gens.
Ce n'est pas une question de meilleur formats; c'est une question
d'accessibilité et le statut quo joue un rôle important dans cette
détermination.
ça ne fait pas mal de distribuer la documentation de votre
programme qui se retrouve sur votre site web (FAQ, etc...)
avec votre programme. N'hésitez pas à l'envoyer dans votre
l'archive de votre application. Si des gens n'en veulent pas,
ils vont l'effacer. Je peux le répéter encore et encore:
Trop de documentation n'est pas péché.
à moins que votre application ne s'applique qu'à une langue autre
que l'Anglais (Le Japonnais par exemple), S.V.P distribuez la
documentation Anglaise avec votre application. Si vous ne parlez
pas l'Anglais ou que vous ne vous sentez pas assez à l'aise de le
faire, demandez de l'aide à un ami. Que vous aimiez ou pas,
juste ou non, l'Anglais est la langue des logiciels
libres. De toute façons, cela ne veut pas dire que
vous devez baser votre documentation seulement sur l'Anglais.
Si vous parlez une aute langue, distribué la version traduite
de votre documentation; si vous en avez le temps et l'énergie.
C'est sûr qu'elle sera utile à quelqu'un.
Finalement, faites-donc la correction de votre documentation.
Les fautes d'orthographes dans la documentation sont des
failles. Je suis coupable de ce crime et malheureusement c'est très
facile de tomber dans le panneau. Si l'anglais n'est pas votre langue
première, essayez de demander à un anglophone de vérifie votre documentation
ou votre site web. Les fautes d'orthographes ou de grammaires ne font que
détruire le professionnalisme de votre code. Les commentaires dans le code
lui-même sont moins important mais dans le man ou sur le site web ces écarts
ne sont pas acceptable.
Présentation diverses
Ce qui nous reste à voir entourant la création de logiciels libres
relève du gros bon sens. On dit souvent que l'ingéniérie logiciel
est est composée de 90 pourcent de gros bon sens mélangé avec 10
pourcent de savoir technologique. il y a rien de pire pour l'espoir d'un
dévelopeur que de se rappeler d'une erreur éventuelle qu'il avait oubliée
Nom des paquetages
Je suis d'accord avec ESR quand il dit: C'est utile à tout
le monde si vos archives ont des nom comme ceux de GNU -- le préfix
tout en alphanumérique et en minuscule, suivi d'un tiret, suivi du numéro
de la version, de l'extention et des autres suffixes. Il y a
beaucoup d'information (incluant beaucoup d'examples de quoi ne
pas faire) dans son guide pratique
Software Realease Practices HOWTO lequel est inclus
dans la bibliographie et peux être trouvé sur le site traduc.org
et en français.
Formats des paquetages
Les formats de paquetages peuvent différés selon le système pour
lequel vous développez. Pour les logiciels sous windows, Les
archives ZIP (.zip) est le format usuel de paquetage. Si vous
développez pour GNU/Linux, *BSD, ou n'importe quel UN*X, faites
sûr que votre code source est toujours disponible en tarball (.tar.gz).
La compression UNIX (.Z) est maintenant révolue et puisque les ordinateurs
sont plus puissants ils utilisent maintenant les bzip2 (.bz2), plus efficace.
Je fais maintenant toutes mes versions avec les deux tarballs, gzip
(.tar.gz) et bzip2 (.tar.bz2).
Les paquetages binaires doivents toujours être à part. Si vous
pouvez construire les paquetages binaires pour les distributions
majeures, vous ne ferez que des heureux. Essayez de tisser
des liens avec des utilisateurs ou développeurs des distributions
majeurs afin d'automatiser le processus de créationn des paquetages
binaires. C'est souvent une bonne idée de fournir en format RPM
pour RedHat, en .deb pour Debian et en Source RPM SRPM
si possible. Souvenez vous que: Les formats binaires c'est super mais
avoir les sources c'est la seule priorité. Vos utilisateurs ou compagnons
feront bine pour vous les paquetages binaires.Système de contrôle des versions
Un système de contôle de versions peut corrigé beaucoup de problèmes de
paquetage (Et beaucoup d'autres problèmes mentionnés dans ce Guide
Pratique). Si vous utilisé *NIX, CVS est votre meilleur atout. Je recommande
fortement le livre de Karl Fogel sur le sujet (et le site
en publie une version HTML).
Que vous utilisiez CVS ou pas, vous devriez peut-être investir un
peu de temps à apprendre un système de contrôle de version car il
automatise la résolution de problèmes discutés dans ce Guide Pratique.
Je ne suis pas au courant des version libre de système de contrôle
de version pour Windows ou Mac OS mais je sais qu'il y a des clients
CVS qui existent pour les deux plateformes. Le site web
SourceForge fait un
excellent travail avec un bel et simple interface web pour CVS.
j'aurai aimé dévoué plus de place dans ce Guide Pratique à CVS parce
que je l'aime bien (j'utilise d'ailleur CVS pour gérer les versions de
ce Guide Pratique!) mais je pense que ça sort du cadre de ce document et
il à déjà son propre Guide Pratique. Plus spécifiquement c'est
CVS Best Practices HOWTO
lequel j'ai inclus dans la bibliographie.
Astuces utiles et trucs de présentation
Autre trucs utiles inclus:
Assurez-vous que votre application peut être trouvé à un
même endroit. Souvent, ça veut dire que vous avez un
seul répertoire accessible par FTP ou par le
web, où les nouvelles versions peuvent être repéré facilement. Une
bonne technique consiste à créer un lien symbolique appellé
nomduprojet.latest qui pointe toujours sur la version la
plus récente de votre application Open Source. Garder à l'esprit
que cet endroit va être énormément sollicité donc assurez vous que
le serveur que vous avez choisi bénéficie de suffisament de bande
passante.
Assurez-vous qu'il y ait toujours une adresse de courriel
valiedepour leretour d'erreurs. Habituellement, c'est
une bonne idée de ne PAS prendre votre adresse principale pour le
retour d'erreurs comme nomduprojet@domain ou nomduprojet-bugs@domain.
De cette façon, si vous décidez de déléguer la maintenance ou si
vous changez d'adresse de courriel, vous n'avez qu'à changer la
redirection de ce courriel. Cela va aussi permettre à plus d'une
personne de pourvoir gérer l'affluence de courriel si jamais votre
projet devient aussi populaire que vous le souhaitez.
Maintenir un projet: Intérragir avec les développeursfswd!developers
Une fois que vous avez démarré votre projet, vous avez dépassé
l'étape la plus difficile dans le processus de développement
de votre application. Avoir un base solide est essentiel, mais
le processus de développement lui-même est tout aussi important
et fourni plusieurs éccueils. Dans le deux prochaines sections,
je décrirai la façon de mener un projet en parlant de comment
maintenir l'effort de développement à travers l'intérraction avec
les développeurs et les utilisateurs.
En distribuant votre application, elle Open Source. Cette transition
et plus qu'un simple élargissement d'utilisateur. En distribuant
votre application librement, votre logiciel
devient un logiciel de la communauté Open Source.
L'orientation du développement de votre application sera revue,
réorienté et completement déterminé par vos
utilisateurs, et à plus grande échelle, par d'autres
développeurs de la communauté.
La différence principale entre le développement de logiciels libres et
le développement de logiciels propriétaires, c'est les développeurs.
En tant que responsable d'un logiciel libre, vous devez attirer et garder les
développeurs au sein du projet ce qui n'est pas le lot des responsables de
développement de logiciels propriétaires. En tant que responsable
du développement d'un logiciel libre, vous devez guider le travail
de vos contributeurs en prenant des décisions ou en choisissant de manière
éclairé de ne pas prendre de décisions. Vous devez guider les
développeurs sans nécessairement les diriger. Vous devez essayer de
garder le respect d'autrui tout en donnant le même respect.
Délégation de tâches
Jusqu'à maintenant, vous m'avez hypothétiquement suivi à partir de la
programmation d'un bout de code de l'application, créé un site
web et un système de documentation, et nous avons dépassé et
(comme il va en être question dans ) nous
prévoyons rendre l'application disponible au reste du monde.
Le temps passe, et si les chose tournent bien, les gens commence
à s'intéresser au projet et veulent contribuer. Les rustines commencent
à entrer.
Comme les parents de n'importe quel enfant qui grandit, c'est
le temps de tréssaillir, de sourire et de faire la chose la plus difficile
dans le vie de parents: c'est le temps de les laissé partir.
La délégation est la façon politique de décrire le processus de
laisser aller. C'est le processus de garder certaines
responsabilités et de donner le pouvoir sur votre projet à d'autres
responsables et développeurs impliqués. C'est difficile pour quiconque
a investi beaucoup de temps et d'énergie dans un projet mais c'est
essentiel pour la croissance de n'importe quel projet de logiciel libre.
Une seule personne ne peut en faire autant. Un logiciel libre n'est rien
sans l'implication d'un groupe de développeurs. Un
groupe de développeurs ne peut être maintenu que dans le respect et la
conduite responsable et la délégation.
à mesure que votre projet progresse, vous remarquerez des gens
qui metteront du temps et des efforts significatifs dans votre
projet. Ceux là seront les gens qui envoyeront des rustines, qui
laisseront des messages dans les listes de diffusion, et qui
s'engageront dans de longue discution par courriel. C'est de votre
responsabilité de contacter ces gens et d'essayer de leur déléguer
une partie du pouvoir et des responsabilités de votre position de
mainteneur de projet (s'ils le veulent). Il y a quelques bonnes façons
de faire cela:
Avec un peu de retenu, délégation ne veut pas dire gérer par un
comité. Dans plusieurs cas, ça l'est et ça a été démontré que ça
marche. Dans d'autres cas, ce ne fut que problèmes. Gérer
des projets de façon libre débat que les projets libres marchent mieux
quand une seule personne prend les grandes décisions (Changement de l'interface,
les dates de sorties, etc...) Je pense que c'est souvent le cas mais
je m'empresse de dire aux développeurs de considérer l'idée qu'un mainteneur de
project n'est pas nécessairement le fondateur et que tout ce pouvoir ne doit
pas rester dans les mains d'une seule personne. Ces situations relèvent de la
politique donc soyez sûr que c'est nécessaire avant de prendre du monde sous
l'aile du projet.
Comment déléguer
Peut-être; que vous trouvez que les autres programmeurs sont plus
expérimenté et connaissant que vous. Votre travail de mainteneur
ne signifie pas que vous devez être le meilleur ou le plus brillant. ça
veut dire que vous êtes responsable de porter un bon jugement et de
reconnaître quelle solution est maintenable et laquelle ne l'est pas.
Comme n'importe quoi, c'est plus facile de regarder les autres déléguer
que de le faire sois-même. En une phrase: Surveillez toujours pour
d'autres développeurs d'expériences qui démontrent de l'intérêt et une
implication soutenue envers le projet et déléguez leur des responsabilités.
Les idées qui suivent peuvent être un bon départ ou une bonne source d'inspiration.
Permettez à un large groupe de personne d'avoir les droits en écriture
à votre dépôt CVS et faites un effort de gérer le tout avec un comité.
Apache est un example
de projet qui est gérer par un petit groupe de développeurs qui votent
pour les améliorations techniques majeures et pour l'admission de
nouveaux membres et qui ont tous accès en .criture au dépôt CVS principal.
Leur processus est détaillé
en ligne.
Le projet Debian est un
example extrême de gestion par comité. Présentement, il y a plus de
700 développeurs qui ont la pleine responsabilité de différents
aspects du projet. Tous ces développeurs peuvent télécharger sur le
serveur FTP primaire, et voter pour les décisions majeures. La direction
du projet est déterminé par le contrat social du projet et une
constitution. Pour faciliter le système, il y a des équipes spéciales
(example l'équipe d'installation, l'équipe de la langue japonaise) aussi bien qu'un
comité technique et un chef de projet. La responsabilité principale du cher de projet
est de, nommer les délégués ou de déléguer les décisions au comité technique.
Bien que ces deux projets fonctionnent à plus grande échelle
que votre projet (au moins au début), leur example est pratique.
L'idée de Debian d'avoir un chef de projet qui ne peut rien faire
sauf déléguer sert de caricature pour démontrer comment un projet peut impliquer
et employer un grand nombre de développeurs et devenir très grand.
Nommez publiquement une personne en tant que gestionnaire de version
pour une version en particuler
Un gestionnaire de version est habituellement responsable de la
coordination des tests, de faire un gel du code, d'être reponsable
de la stabilité et du contrôle de la qualité, de préparer les archives
de logiciels, et de le mettre à l'endroit approprié pour le téléchargement.
Cette utilisation d'une gestionnaire de version est une bonne
façon de vous donner un repos et de passer la responsabilité
d'accepter ou de refuser les rustines à quelqu'un d'autre. C'est
une bonne façon de définir clairement qu'un partie du travail
appartient à une certaine personne et c'est une belle façon de
vous donner un moment pour respirer.
Déléguer le contrôle d'une branche entière
Si votre projet requiert d'avoir plusieurs branches (comme décrit dans
), cela pourrait être une bonne idée de nommer
une personne à la tête de cette branche. Si vous aimez concentrer vos
énergies sur le développement et l'implantation de nouvelles foncitonnalités,
donner le contrôle total de la version stable à un développeur adapté.
L'auteur de Linux, Linux Torvalds, a sorti et couronné Alan Cox
comme l'homme des noyaux stables. Toute les rustines
pour le noyau stable vont à Alan et, si Linus devait arrêter son travail
pour Linux pour une quelconque raison, Alan Cox serait plus que l'homme
de la situation reconnu par ses pairs pour le remplacer.
Accepter et refuser des rustines
Ce Guide Pratique a déja parlé du fait qu'en tant que mainteneur d'un
projet libre, un de vos responsabilité principale sera d'accepter et de
rejeter les rustines que les autres développeurs vous auront envoyé.
Encourager les bonnes pratiques
En tant que chef ou mainteneur de projet, vous n'êtes pas la personne
qui allez faire le plus de rustines. Néanmoins, c'est pas mauvais de
prendre connaissance de la section Règles d'usage pour la
mise au point de la distribution dans le Guide
Pratique sur la publication de logiciels de ESR.
.
Je ne suis pas d'accord avec ESR quand il dit que les rustines les plus
mal docummenté sont succeptible d'être rejeté à première vue -- Ceci n'a
jamais été mon cas, spécifiquement quand on travaile à la résolution de
problèmes qui ne nous arrivent pas souvent sous forme de rustines.
Bien sûr, cela ne veut pas dire que j'aime recevoir
des rustines mal faites. Si vous recevez des mauvaise rustines, si vous
recevez des rustine totalement non documenté, et surtout si vous recevez
autres choses que des corrections insignifiantes, ça peut être bon de juger
rustines selon les critères du Guide Pratique de ESR et d'envoyer aux gens
des liens vers les documents d'informations sur la bonne façon de faire.
Jugement technique
Dans développement Open Source avec CVS, Karl Fogel
tiens un discours convaiquant sur le fait que les plus importantes choses
à garder à l'esprit lorsqu'on refuse ou qu'on accepte des rustines sont:
Un connaissance ferme de la portée de votre application (C'est le sujet
que je traite dans );
L'abileté à reconnaître, faciliter, et diriger
l'évolution de votre application tel que
l'application puisse grandir, changer et incorporer des fonctionnalités
non prévue au départ;
La nécessité d'éviter les disgréssions qui peuvent trop expandre la portée
de l'application
The necessity to avoid digressions that might expand the
scope of the program too much and result and push the project
toward an early death under its own weight and
unwieldiness.
Ce sont les critères que vous en tant que mainteneur de projet devez
prendre en compte à chaque fois que vous recevez une rustine.
Fogel énonce sur le sujet et élabore que les questions à se poser quand
vous considérez de mettre en oeuvre (ou approuver) un changement sont:
Cela répondra t-il à un pourcentage significatif de la communauté d'utilisateurs ?
Est-ce que cela convient au domaine du logiciel ou est-ce une extention intuitive
et naturelle du domaine ?
Les réponses à ces questions ne sont jamais franches et c'est
parfaitement possible (et souhaitable) que la personne qui a soumi
une rustine envisage de façon différente de vous les réponses à ces questions.
Toutefois, si vous sentez que la réponse à l'une de ces question est non,
c'est de votre responsabilité de refuser le changement. Si vous ne faites pas ceci,
le projet deviendra difficile à manier et sera ingérable et échouera au final.
Refuser la rustine
Refuser des rustines est probablement la plus difficile et sensible des
tâches que le mainteneur de n'importe lequel des logiciels libres doit faire face.
Mais parfois ça doit être fait. J'ai mentionné précédemment (dans
et dans ) que vous deviez balancer vos responsabilités et votre
pouvoir de faire les chose
Rejecting patches is probably the most difficult and sensitive
job that the maintainer of any free software project has to
face. But sometimes it has to be done. I mentioned earlier (in
and in )
that you need to try and balance your responsibility and power to
make what you think are the best technical decisions with the
fact that you will lose support from other developers if you seem
like you are on a power trip or being overly bossy or possessive
of the community's project. I recommend that you keep these three
major concepts in mind when rejecting patches (or other changes):
Bring it to the community
One of the best ways of justifying a decision to reject a patch
and working to not seem like you keep an iron grip on your
project is by not making the decision alone at all. It might
make sense to turn over larger proposed changes or more
difficult decisions to a development mailing list where they can
be discussed and debated. There will be some patches (bug fixes,
etc.) which will definitely be accepted and some that you feel
are so off base that they do not even merit further
discussion. It is those that fall into the gray area between
these two groups that might merit a quick forward to a mailing
list.
I recommend this process wholeheartedly. As the project
maintainer you are worried about making the best decision for
the project, for the project's users and developers, and for
yourself as a responsible project leader. Turning things over to
an email list will demonstrate your own responsibility and
responsive leadership as it tests and serves the interests of
your software's community.
Technical issues are not always good justification
Especially toward the beginning of your project's life, you
will find that many changes are difficult to implement,
introduce new bugs, or have other technical problems. Try to see
past these. Especially with added functionality, good ideas do
not always come from good programmers. Technical merit is a
valid reason to postpone an application of a patch but it is not
always a good reason to reject a change outright. Even small
changes are worth the effort of working with the developer
submitting the patch to iron out bugs and incorporate the change
if you think it seems like a good addition to your project. The
effort on your part will work to make your project a community
project and it will pull a new or less experienced developer
into your project and even teach them something that might help
them in making their next patch.
Common courtesy
It should go without saying but, above all and in all
cases, just be nice. If someone has an idea and cares
about it enough to write some code and submit a patch, they
care, they are motivated, and they are already involved. Your
goal as the maintainer is make sure they submit again. They may
have thrown you a dud this time but next time may be the idea or
feature that revolutionizes your project.
It is your responsibility to first justify your choice to not
incorporate their change clearly and concisely. Then thank
them. Let them know that you a appreciate their help and feel
horrible that you can't incorporate their change. Let them know
that you look forward to their staying involved and you hope
that the next patch or idea meshes better with your project
because you appreciate their work and want to see it in your
application. If you have ever had a patch rejected after putting
a large deal of time, thought, and energy into it, you remember
how it feels and it feels bad. Keep this in mind when you have
to let someone down. It's never easy but you need to do
everything you can to make it as not-unpleasant as possible.
Stable and Development Branches
The idea of stable and development branches has already been
described briefly in and in
. These allusions attest to some of
the ways that multiple branches can affect your software. Branches
can let you avoid (to some extent) some of the problems around
rejecting patches (as described in ) by
allowing you to temporarily compromise the stability of your
project without affecting those users who need that stability.
The most common way of branching your project is to have one
branch that is stable and one that is for development. This is the
model followed by the Linux kernel that is described in . In this model, there is
always one branch that is stable and always
one that is in development. Before any new release, the
development branch goes into a feature freeze as
described in where major changes and
added features are rejected or put on hold under the development
kernel is released as the new stable branch and major development
resumes on the development branch. Bug fixes and small changes
that are unlikely to have any large negative repercussions are
incorporated into the stable branch as well as the development
branch.
Linux's model provides an extreme example. On many projects, there is no
need to have two versions constantly available. It may make sense to
have two versions only near a release. The Debian project has
historically made both a stable and an unstable distribution
available but has expanded to this to include: stable, unstable,
testing, experimental, and (around release time) a frozen
distribution that only incorporates bug fixes during the
transition from unstable to stable. There are few projects whose
size would necessitate a system like Debian's but this use of
branches helps demonstrate how they can be used to balance
consistent and effective development with the need to make regular
and usable releases.
In trying to set up a development tree for yourself, there are
several things that might be useful to keep in mind:
Minimize the number of branchesDebian may be able to make good use of four or five
branches but it contains gigabytes of software in over 5000
packages compiled for 5-6 different architectures. For you,
two is probably a good ceiling. Too many branches will confuse
your users (I can't count how many times I had to describe
Debian's system when it only had 2 and sometimes 3 branches!),
potential developers and even yourself. Branches can help but
they come at a cost so use them very sparingly.Make sure that all your different branches are explainedAs I mentioned in the preceding paragraph, different
branches will confuse your users. Do
everything you can to avoid this by clearly explaining the
different branches in a prominent page on your website and in a
README file in the FTP or
web directory.
I might also recommend against a mistake that I think Debian
has made. The terms unstable,testing, and experimental are
vague and difficult to rank in order of stability (or
instability as the case may be). Try explaining to someone
that stable actually means ultra
stable and that unstable doesn't
actually include any unstable software but is really stable
software that is untested as a distribution.
If you are going to use branches, especially early on, keep in
mind that people are conditioned to understand the terms
stable and development and you
probably can't go wrong with this simple and common division of
branches.
Make sure all your branches are always availableLike a lot of this document, this should probably should
go without saying but experience has taught me that it's not
always obvious to people. It's a good idea to physically split
up different branches into different directories or directory
trees on your FTP or web site. Linux
accomplishes this by having kernels in a v2.2 and a v2.3
subdirectory where it is immediately obvious (after you know
their version numbering scheme) which directory is for the most
recent stable and the current development releases. Debian
accomplishes this by naming all their distribution with names
(i.e. woody, potato, etc.) and then changing symlinks named
stable,unstable and
frozen to point to which ever distribution (by
name) is in whatever stage. Both methods work and there are
others. In any case, it is important that different branches
are always available, are accessible from consistent locations,
and that different branches are clearly distinguished from each
other so your users know exactly what they want and where to
get it.Other Project Management issues
There are more issues surrounding interaction with developers in a
free software project that I can not touch on in great detail in a
HOWTO of this size and scope. Please don't hesitate to contact me if you see
any major omissions.
Other smaller issues that are worth mentioning are:
Freezing
For those projects that choose to adopt a split development model
(), freezing is a concept that is worth
becoming familiar with.
Freezes come in two major forms. A feature freeze
is a period when no significant functionality is added to a
program. It is a period where established functionality (even
skeletons of barely working functionality) can be improved and
perfected. It is a period where bugs are fixed. This type of
freeze is usually applied some period (a month or two) before a
release. It is easy to push a release back as you wait for
one more feature and a freeze helps to avoid this
situation by drawing the much needed line in the sand. It gives
developers room they need to get a program ready for release.
The second type of freeze is a code freeze which
is much more like a released piece of software. Once a piece of
software has entered a code freeze, all changes to
the code are discouraged and only changes that fix known bugs
are permitted. This type of freeze usually follows a
feature freeze and directly precedes a
release. Most released software is in what could be interpreted
as a sort of high level code freeze.
Even if you never choose to appoint a release manager (), you will have an easier time
justifying the rejection or postponement of patches () before a release with a publicly stated
freeze in effect.
Forks
I wasn't sure about how I would deal with forking in this
document (or if I would deal with forking at all). A fork is when
a group of developers takes code from a free software project and
actually starts a brand new free software project with it. The
most famous example of a fork was between Emacs and XEmacs. Both
emacsen are based on an identical code-base but for technical,
political, and philosophical reasons, development was split into
two projects which now compete with each other.
The short version of the fork section is, don't do
them. Forks force developers to choose one project to
work with, cause nasty political divisions, and redundancy of
work. Luckily, usually the threat of the fork is enough to scare
the maintainer or maintainers of a project into changing the way
they run their project.
In his chapter on The Open Source Process, Karl
Fogel describes how to do a fork if you absolutely must. If you
have determined that is absolutely necessary and that the
differences between you and the people threatening to fork are
absolutely unresolvable, I recommend Fogel's book as a good place
to start.
Maintaining a Project: Interacting with Usersfswd!users
If you've worked your way up to here, congratulations, you are
nearing the end of this document. This final section describes some
of the situations in which you, in your capacity as project
maintainer, will be interacting with users. It gives some
suggestions on how these situations might be handled effectively.
Interacting with users is difficult. In our discussion of
interaction with developers, the underlying assumption is that in a
free software project, a project maintainer must constantly strive to
attract and keep developers who can easily leave at any time.
Users in the free software community are different than developers
and are also different than users in the world of proprietary
software and they should be treated differently than either
group. Some ways in which the groups differ significantly follow:
The lines between users and developers are blurred in ways
that is totally foreign to any proprietary development
model. Your users are often your developers and vice
versa.In the free software world, you are often your users' only
choice. Because there is such an emphasis on not replicating the
work of others in the free software community and because the
element of competition present in the propriety software model is
absent (or at least in an extremely different form) in the free
software development model, you will probably be the only project
that does what you do (or at least the only one that does what
you do in the way that you do it). This means your responsiveness
to your users is even more important than in the proprietary
software world.In an almost paradoxical situation, free software projects
have less immediate or dire consequences for ignoring their users
altogether. It is also often easier to do. Because you don't
usually need to compete with another product, chances are good
that you will not be scrambling to gain the features of your
competitor's newest program. This means that your development
process will have to be directed either internally, by a
commitment to your users, or through both.
Trying to tackle this unique situation can only be done
indirectly. Developers and maintainers need to listen to users and
to try and be as responsive as possible. A solid knowledge of the
situation recounted above is any free software developer's best tool
for shifting his development or leadership style to fit the unique
process of free software project management. This chapters will try and
introduce some of the more difficult or important points in any
projects interactions with users and give some hints on how to
tackle these.
Testing and Testers
In addition to your users being your developers, they are also
(and perhaps more commonly) your testers. Before I get flamed, I
should rephrase my sentence: some of your
users (those who explicitly volunteer) are your
testers.
It is important that this distinction be made early on because not
all of your users want to be testers. Many users want to use
stable software and don't care if they don't have the newest,
greatest software with the latest, greatest features. These users
except a stable, tested piece of software without major or obvious
bugs and will be angry if they find themselves testing. This is
yet another way in which a split development model (as mentioned
in ) might come in handy.
Managing
Projects the Open Source Way describes what a
good test should look for:
Boundary conditionsMaximum buffer lengths, data conversions, upper/lower
boundary limits, and so on.Inappropriate behaviorIts a good idea to find out what a program will do if a
user hands it a value it isn't expecting, hits the wrong button,
etc. Ask yourself a bunch of what if questions
and think of anything that might fail or
might go wrong and find out what your
program would do in those cases.Graceful failureThe answer to a number of the what if
questions above is probably failure which is
often the only answer. Now make sure that it happens
nicely. Make sure that when it crashes, there is some indication
of why it crashed or failed so that the user or developer
understands whats going on.Standards conformanceIf possible, make sure your programs conforms to
standards. If it's interactive, don't be too creative with
interfaces. If it is non-interactive, make sure it communicates
over appropriate and established channels with other programs
and with the rest of the system.Automated testing
For many programs, many common mistakes can be caught by
automated means. Automated tests tend to be pretty good at
catching errors that you've run into several times before or
the things you just forget. They are not very good at finding
errors, even major ones, that are totally unforeseen.
CVS comes with a Bourne shell script called sanity.sh that is
worth looking at. Debian uses a program called lintian that
checks Debian packages for all of the most common errors. While
use of these scripts may not be helpful, there is a host of other
sanity checking software on the net that may be applicable (feel
free to email me any recommendations). None of these will create
a bug-free release but they will avoid at least some major
oversights. Finally, if your programs become a long term
endeavor, you will find that there are certain errors that you
tend to make over and over. Start a collection of scripts that
check for these errors to help keep them out of future releases.
Testing by testers
For any program that depends on user interactivity, many bugs
will only be uncovered through testing by users actually clicking
the keys and pressing the mouse buttons. For this you need
testers and as many as possible.
The most difficult part of testing is finding testers. It's
usually a good tactic to post a message to a relevant mailing
list or news group announcing a specific proposed release date
and outlining the functionality of your program. If you put some
time into the announcement, you are sure to get a few responses.
The second most difficult part of testing is
keeping your testers and keeping them
actively involved in the testing process. Fortunately, there are
some tried and true tactics that can applied toward this end:
Make things simple for your testersYour testers are doing you a favor so make it as easy as
possible for them. This means that you should be careful to
package your software in a way that is easy to find, unpack,
install, and uninstall. This also means you should explain
what you are looking for to each tester and make the means for
reporting bugs simple and well established. The key is to
provide as much structure as possible to make your testers'
jobs easy and to maintain as much flexibility as possible for
those that want to do things a little differently.Be responsive to your testersWhen your testers submit bugs, respond to them and
respond quickly. Even if you are only responding to tell them
that the bug has already been fixed, quick and consistent
responses make them feel like their work is heard, important,
and appreciated.Thank your testersThank them personally each time they send you
patch. Thank them publicly in the documentation and the about
section of your program. You appreciate your testers and your
program would not be possible without their help. Make sure
they know it. Publicly, pat them on the back to make sure the rest of
the world knows it too. It will be appreciated more than you
expected.Setting up Support Infrastructure
While testing is important, the large part of your interactions
and responsibility to your users falls under the category of
support. The best way to make sure your users are adequately
supported in using your program is to set up a good infrastructure
for this purpose so that your developers and users help each other
and less of the burden falls on you. This way, people will also
get quicker and better responses to their questions. This
infrastructure comes in several major forms:
Documentation
It should not come as any surprise that the key element to any
support infrastructure is good documentation. This topic was
largely covered in and will not be
repeated here.
Mailing lists
Aside from documentation, effective mailing lists will be your
greatest tool in providing user support. Running a mailing list
well is more complicated than installing mailing list software
onto a machine.
Separate lists
A good idea is too separate your user and development mailing
lists (perhaps into project-user@host and project-devel@host)
and enforce the division. If people post a development question
onto -user, politely ask them to repost it onto -devel and vise
versa. Subscribe yourself to both groups and encourage all
primarily developers to do the same.
This system provides so that no one person is stuck doing all of
the support work and works so that users learn more about the
program, they can help newer users with their questions.
Choose mailing list software well
Please don't make the selection of mailing list software
impulsively. Please consider easy accessibility by users without
a lot of technical experience so you want to be as easy as
possible. Web accessibility to an archive of the list is also
important.
The two biggest free software mailing list programs are majordomo
and GNU Mailman. A
long time advocate of majordomo, I would now recommend any
project choose GNU Mailman. It fulfills the criteria listed
above and makes it easier. It provides a good mailing
list program for a free software project maintainer as opposed
to a good mailing list application for a mailing list
administrator.
There are other things you want to take into consideration in
setting up your list. If it is possible to gate your mailing
lists to Usenet and provide it in digest form as well as
making them accessible on the web, you will please some users
and work to make the support infrastructure slightly more
accessible.
Other support ideas
A mailing list and accessible documentation are far from all you
can do to set up good user support infrastructure. Be
creative. If you stumble across something that works well, email me
and I'll include it here.
Make your self accessible
You can not list too few methods to reach you. If you hang out
in an IRC channel, don't hesitate to list it
in your projects documentation. List email and snailmail
addresses, and ways to reach you via ICQ,
AIM, or Jabber if they apply.
Bug management software
For many large software projects, use of bug management software
is essential to keep track of which bugs have been fixed, which
bugs have not been fixed, and which bugs are being fixed by
which people. Debian uses the Debian Bug Tracking System
(BTS) although it may not be best choice for
every project (it seems to currently be buckling under its own
weight) As well as a damn good web browser, the Mozilla project
has spawned a sub-project resulting in a bug tracking system
called bugzilla
which has become extremely possible and which I like a lot.
These systems (and others like them) can be unwieldy so
developers should be careful to not spend more time on the bug
tracking system than on the bugs or the projects themselves. If
a project continues to grow, use of a bug tracking system can
provide an easy standard avenue for users and testers to report
bugs and for developers and maintainers to fix them and track
them in an orderly fashion.
Releasing Your Program
As mentioned earlier in the HOWTO, the first rule of releasing is,
release something useful. Non-working or
not-useful software will not attract anyone to your
project. People will be turned off of your project and will be likely
to simply gloss over it next time they see a new version
announced. Half-working software, if useful, will intrigue people,
whet their appetites for versions to come, and encourage them to
join the development process.
When to release
Making the decision to release your software for the first time
is an incredibly important and incredibly stressful decision. But
it needs to done. My advice is to try and make something that
is complete enough to be usable and incomplete enough to allow
for flexibility and room for imagination by your future
developers. It's not an easy decision. Ask for help on a local
Linux User Group mailing list or from a group of developer
friends.
One tactic is to first do an alpha or
beta release as described below in . However, most of the guidelines described
above still apply.
When you feel in your gut that it is time and you feel
you've weighed the situation well several times, cross your
fingers and take the plunge.
After you've released for the first time, knowing when to release
becomes less stressful, but just as difficult to gauge. I like
the criteria offered by Robert Krawitz in his article, Free
Software Project Management for maintaining a
good release cycle. He recommends that you ask yourself,
does this release...Contain sufficient new functionality or bug fixes to be
worth the effort.Be spaced sufficiently far apart to allow the user time
to work with the latest release.Be sufficiently functional so that the user can get work
done (quality).
If the answer is yes to all of these questions, its probably time
for a release. If in doubt, remember that asking for advice can't
hurt.
How to release
If you've followed the guidelines described in this HOWTO up
until this point, the mechanics of doing a release are going to
be the easy part of releasing. If you have set up consistent
distribution locations and the other infrastructure described in
the preceding sections, releasing should be as simple as building
the package, checking it once over, and uploading it into the
appropriate place and then making your website reflect the
change.
Alpha, beta, and development releases
When contemplating releases, it worth considering the fact that
not every release needs to be a full numbered release. Software
users are accustomed to pre-releases but you must be careful to
label these releases accurately or they will cause more problems then
they are worth.
The observation is often made that many free software developers
seem to be confused about the release cycle. Managing
Projects the Open Source Way suggests that you memorize
the phrase, Alpha is not Beta. Beta is not Release
and I'd agree that tis is a probably a good idea.
alpha releasesAlpha software is feature-complete but sometimes only
partially functional.Alpha releases are expected to be unstable, perhaps a
little unsafe, but definitely usable. They
can have known bugs and kinks that have
yet to be worked out. Before releasing an alpha, be sure to
keep in mind that alpha releases are still
releases and people are not going to be expecting a
nightly build from the CVS source. An alpha should work and
have minimal testing and bug fixing already finished.beta releasesBeta software is feature-complete and functional, but is
in the testing cycle and still has a few bugs left to be
ironed out.Beta releases are general expected to be usable and
slightly unstable, although definitely not
unsafe. Beta releases usually preclude a full
release by under a month. They can contain small known bugs
but no major ones. All major functionality should be fully
implemented although the exact mechanics can still be worked
out. Beta releases are great tool to whet the appetites of
potential users by giving them a very realistic view of where
your project is going to be in the very near future and can
help keep interest by giving people
something.development releasesDevelopment release is much a more vague
term than alpha or beta. I
usually choose to reserve the term for discussion of a
development branch although there are other ways to use the
term. So many in fact, that I feel the term has been
cheapened. The popular window manager Enlightenment has
released nothing but development
releases. Most often, the term is used to describe releases
that are not even alpha or beta and if I were to release a
pre-alpha version of a piece of software in order to keep
interest in my project alive, this is probably how I would
have to label it.Announcing Your Project
Well, you've done it. You've (at least for the purposes of this
HOWTO) designed, built, and released your free software
project. All that is left is for you to tell the world so they
know to come and try it out and hopefully jump on board with
development. If everything is in order as described above, this
will be a quick and painless process. A quick announcement is all
that it takes to put yourself on the free software community's
radar screen.
Mailing lists and UsenetAnnounce your software on Usenet's comp.os.linux.announce. If
you only announce your software in two places, have it be c.o.l.a
and freshmeat.
However, email is still the way that most people on the Internet
get their information. Its a good idea to send a message
announcing your program to any relevant mailing list you know of
and any other relevant Usenet discussion groups.Karl Fogel recommends that use you simple subject
describing the fact that the message is an announcement, the name
of the program, the version, and a half-line long description of
its functionality. This way, any interested user or developer
will be immediately attracted to your announcement. Fogel's
example looks like:
Subject: ANN: aub 1.0, a program to assemble Usenet binaries
The rest of the email should describe the programs functionality
quickly and concisely in no more than two paragraphs and should
provide links to the projects webpage and direct links to
downloads for those that want to try it right away. This form
will work for both Usenet and mailing list posts.
You should repeat this announcement process consistently in the
same locations for each subsequent release.
freshmeat.net
Mentioned earlier in , in today's free
software community, announcements of your project on freshmeat
are almost more important than announcements on mailing lists.
Visit the freshmeat.net
website or their submit project
page to post your project onto their site and into their
database. In addition to a large website, freshmeat provides a
daily newsletter that highlights all the days releases and
reaches a huge audience (I personally skim it every night for any
interesting new releases).
Project Mailing ListIf you've gone ahead and created mailing lists for your
project, you should always announce new versions on these
lists. I've found that for many projects, users request a very
low-volume announce only mailing list to be notified when new
versions are released. freshmeat.net now allows users to subscribe
to a particular project so they receive emails every time a new
version is announced through their system. It's free and it can
stand in for an announce-only mailing list. In my opinion, it
can't hurt.Printed BooksFogelKarlOpen Source Development with CVSCoriolois Open Press19991-57610-490-7
Fogel's guide to using CVS in the free software
world is much more than its subtitle. In the publisher's
own words: Open Source Development with
CVS is one of the first books available that teaches
you development and implementation of Open Source
software. It also includes the best reference and
tutorial to CVS I have ever seen. It is the book that was
so good that it prompted me to write this
HOWTO because I thought the role it tried to serve was so
important and useful. Please check it or buy it if you can and
are seriously interested in running a free software project.
LessigLawrenceCode and Other Laws of CyberspaceBasic Books20000-465-03913-8
While it only briefly talks about free software (and does it by
tiptoeing around the free software/open source issue with the
spineless use of the term open code that only a
lawyer could coin), Lessig's book is brilliant. Written by a
lawyer, it talks about how regulation on the Internet is not
done with law, but with the code itself and how the nature of
the code will determine the nature of future freedoms. In
addition to being a quick and enjoyable read, it gives some
cool history and describes how we need
free software in a way more powerfully than anything I've read
outside of RMS's
Right to Read.RaymondEricThe Cathedral and the BazaarMusings on Linux and Open Source by an Accidental RevolutionaryO'Reilly19991-56592-724-9
Although I have to honestly say that I am not the ESR fan that
I used to be, this book proved invaluable in getting me where I
am today. The essay that gives the book its title does a good
job of sketching the free software process and does an an
amazing job of making an argument for free software/open source
development as a road to better software. The rest of the book
has other of ESR's articles, which for the most part are posted
on his website. Still, it's nice thing to own in hard copy and
something that every free software/open source hacker should
read.
Web-Accessible Resources
This is a list of the web resources pertaining to this HOWTO that
I've found most helpful in compiling this information. If you know
of others that would help, please don't hesitate to email me at
mako@debian.org and we can look into getting it
added to the list and represented in the HOWTO.
I'd recommend that any free software developer (or potential one)
skim through these sites because they have each have a lot to say.
DafermosGeorgeN
<ulink url="http://firstmonday.org/issues/issue6_11/dafermos/" >Management and Virtual Decentralized Networks: The Linux Project</ulink>
Since the paper includes its own abstract, I thought I
would include it here verbatim:
This paper examines the latest of
paradigms - the Virtual Network(ed) Organisation - and whether
geographically dispersed knowledge workers can virtually
collaborate for a project under no central
planning. Co-ordination, management and the role of knowledge
arise as the central areas of focus. The Linux Project and its
development model are selected as a case of analysis and the
critical success factors of this organisational design are
identified. The study proceeds to the formulation of a
framework that can be applied to all kinds of virtual
decentralised work and concludes that value creation is
maximized when there is intense interaction and uninhibited
sharing of information between the organisation and the
surrounding community. Therefore, the potential success or
failure of this organisational paradigm depends on the degree
of dedication and involvement by the surrounding
community.
This paper was referred to me in my capacity as author of
this HOWTO and I was very impressed. It's written by a graduate
student in management and I think it succeeds at evaluating the
Linux project as an example of a new paradigm in management--one
that you will be be placing yourself at the
center of in your capacity as maintainer of a free software
project.As a developer trying to control an application and guide
it to success in the free software world, I'm not sure how
useful Dafermos's argument is. It does however, provide a
theoretical justification for my HOWTO--free software project
management is a different creature than
proprietary software project management. If you are interested
in the conceptual and theoretical ways that free software
project management differs from other types of management, this
is a great paper to read. If this paper answers questions of
how?, Dafermos answers the (more difficult to
defend) questions of why? and does a very good
job.GabrielRichard
<ulink url="http://www.jwz.org/doc/worse-is-better.html" >The Rise of
<quote>Worse is Better</quote>
</ulink>
A well written article although I think the title may have
confused as many people as the rest of the essay helped. It
offers a good description of how to design programs that will
succeed and stay maintainable as they grow.
ManleyMontey
<ulink url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD" >Managing
Projects the Open Source Way</ulink>
Linux
ProgrammingOct 31, 2000
In one of the better articles on the subject that I've read,
Monty sums up some of the major points I touch on including:
starting a project, testing, documentation, organizing a team and
leadership, and several other topics. While more opinionated that
I try to be, I think its an important article that I found very
helpful in writing this HOWTO. I've tried to cite him in
the places where I borrowed from him most.
I have problems much of this piece and I recommend you read
at the same time you read Monty's
article for a good critique.
RaymondEricSteven
<ulink url="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html" >Software Release Practice HOWTO</ulink>
At first glance, ESR's release practice HOWTO seems to
share a lot of terrain with this document. Upon closer
examination, the differences become apparent but they are
closely related. His document, read in conjunction with mine,
will give a reader a good picture of how to go about managing a
project. ESR's HOWTO goes into a bit more detail on how to write
and what languages to write in. He tends to give more specific
instructions and checklists (name this file this, not
this) while this HOWTO speaks more conceptually. There
are several sections that are extremely similar. It's also
much shorter.My favorite quote from his HOWTO is: "Managing a
project well when all the participants are volunteers presents
some unique challenges. This is too large a topic to cover in a
HOWTO. Oh really? Perhaps I just do a poor job.VenugopalanVivek
<ulink url="http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html" >CVS Best Practices</ulink>
Venugopalan provides one of the best essays on
effective use of CVS that I've come across. It is written for
people who already have a good knowledge of CVS. In the chapter
on branching, he describes when and how to branch but gives no
information on what CVS commands you should use to do this. This
is fine (technical CVS HOWTO have been written) but CVS newbies
will want to spend some time with Fogel's reference before they
will find this one very useful.Venugopalan creates checklists of things to do before,
after, and around releases. It's definitely worth a read through
as most of his ideas will save tons of developer head aches over
any longer period of time.Advogato Articles
I've found that one of the best resources that any free software
developer has at his or her disposal is Advogato.org. If you haven't
yet had a chance to visit the
website, do.
I have spent a huge amount of time on Advogato and I've gone
through and provided links to the articles that I think might be
of particular interest to anyone reading this HOWTO. I think that
skimming through these links can be helpful and I promise that if
you do, you'll learn a lot. You will learn that my idea of how a
free software project should be run is not the
only idea. I think that's important.
If nothing else, there is way more
information on that website than I could ever fit into, or
reference from this HOWTO. I have listed what I think are the most
relevant articles here with short descriptions that I've written.
HindleStephen
<ulink url="http://www.advogato.org/article/262.html" >'Best Practices' for Open Source?</ulink>
AdvogatoMarch 21, 2001
Touching mostly on programming practice (as most articles on
the subject usually do), the article talks a little about
project management (Use it!) and a bit about
communication within a free software project.
CohenBram
<ulink url="http://www.advogato.org/article/258.html" />How to
Write Maintainable CodeAdvogatoMarch 15, 2001
This article touches upon the "writing maintainable code"
discussion that I try hard to avoid in my HOWTO. It's one of
the better (and most diplomatic) articles on the subject that
I've found.
KrawitzRobert
<ulink url="http://www.advogato.org/article/196.html" >Free
Source Project Management</ulink>
AdvogatoNovember 4, 2000
This article made me happy because it challenged many of the
problems that I had with Monty's article on LinuxProgramming. The
author argues that Monty calls simply for the application of
old (proprietary software) project management techniques in
free software projects instead of working to come up with
something new. I found his article to be extremely well thought
out and I think it's an essential read for any free software
project manager.
MartinsLalo
<ulink url="http://www.advogato.org/article/128.html" >Ask
the Advogatos: why do Free Software projects
fail?</ulink>
AdvogatoJuly 20, 2000
While the article is little more than a question, reading the
answers to this question offered by Advogato's readers can
help. In a lot of ways, this HOWTO acts as my answer to the
questions posed in this article but there are others, many of
which might take issue with whats is in this HOWTO. It's worth
checking out.
BurleyDavid
<ulink url="http://www.advogato.org/article/107.html" >In-Roads to Free
Software Development</ulink>
AdvogatoJune 14, 2000
This document was written as a response to another Advogato
article. Although not about running a project, this
describes some of the ways that you can get started with free
software development without starting a project. I think this
is an important article. If you are interested in becoming
involved with free software, this article showcases some of the
ways that you can do this without actually starting a project
(something that I hope this HOWTO has demonstrated is not to be
taken lightly).
MoormanJacob
<ulink url="http://www.advogato.org/article/72.html" >Importance of
Non-Developer Supporters in Free Software</ulink>
AdvogatoApril 16, 2000
Moorman's is a short article but it brings up some good
points. The comment reminding developers to thank their testers
and end-users is invaluable and oft-forgotten.
OrchardLeslie
<ulink url="http://www.advogato.org/article/67.html" >On
Naming an Open Source Project</ulink>
AdvogatoApril 12, 2000
I didn't even have a section on project naming in this HOWTO
(See ) until Leslie Orchard's article
reminded me of it. Thanks to Leslie for writing this article!
AllenDavid
<ulink url="http://www.advogato.org/article/40.html" >Version Numbering Madness</ulink>
AdvogatoFebruary 28, 2000
In this article, David Allen challenges the whole
Major.Minor.Patch version numbering scheme. Its
good to read this as you read . I liked the article and it
describes some of the projects that I bring up in my discussion
of version numbering.
GNU Free Documentation License0. PREAMBLE
The purpose of this License is to make a manual, textbook, or
other written document free in the sense of
freedom: to assure everyone the effective freedom to copy and
redistribute it, with or without modifying it, either
commercially or non-commercially. Secondarily, this License
preserves for the author and publisher a way to get credit for
their work, while not being considered responsible for
modifications made by others.
This License is a kind of copyleft, which means
that derivative works of the document must themselves be free in
the same sense. It complements the GNU General Public License,
which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for
free software, because free software needs free documentation: a
free program should come with manuals providing the same
freedoms that the software does. But this License is not limited
to software manuals; it can be used for any textual work,
regardless of subject matter or whether it is published as a
printed book. We recommend this License principally for works
whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be
distributed under the terms of this License. The
Document, below, refers to any such manual or
work. Any member of the public is a licensee, and is addressed
as you.
A Modified Version of the Document means any work
containing the Document or a portion of it, either copied
verbatim, or with modifications and/or translated into another
language.
A Secondary Section is a named appendix or a
front-matter section of the Document that deals exclusively
with the relationship of the publishers or authors of the
Document to the Document's overall subject (or to related
matters) and contains nothing that could fall directly within
that overall subject. (For example, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.) The relationship could be a matter of historical
connection with the subject or with related matters, or of
legal, commercial, philosophical, ethical or political position
regarding them.
The Invariant Sections are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the
notice that says that the Document is released under this
License.
The Cover Texts are certain short passages of
text that are listed, as Front-Cover Texts or Back-Cover Texts,
in the notice that says that the Document is released under this
License.
A Transparent copy of the Document means a machine-readable
copy, represented in a format whose specification is available
to the general public, whose contents can be viewed and edited
directly and straightforwardly with generic text editors or (for
images composed of pixels) generic paint programs or (for
drawings) some widely available drawing editor, and that is
suitable for input to text formatters or for automatic
translation to a variety of formats suitable for input to text
formatters. A copy made in an otherwise Transparent file format
whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent. A copy
that is not Transparent is called
Opaque.
Examples of suitable formats for Transparent copies include
plain ASCII without markup, Texinfo input format, LaTeX input
format, SGML or XML using a publicly available DTD, and
standard-conforming simple HTML designed for human
modification. Opaque formats include PostScript, PDF,
proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD
and/or processing tools are not generally available, and the
machine-generated HTML produced by some word processors for
output purposes only.
The Title Page means, for a printed book, the
title page itself, plus such following pages as are needed to
hold, legibly, the material this License requires to appear in
the title page. For works in formats which do not have any title
page as such, Title Page means the text near the
most prominent appearance of the work's title, preceding the
beginning of the body of the text.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either
commercially or non-commercially, provided that this License, the
copyright notices, and the license notice saying this License
applies to the Document are reproduced in all copies, and that
you add no other conditions whatsoever to those of this
License. You may not use technical measures to obstruct or
control the reading or further copying of the copies you make or
distribute. However, you may accept compensation in exchange for
copies. If you distribute a large enough number of copies you
must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated
above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies of the Document numbering more than 100,
and the Document's license notice requires Cover Texts, you must enclose
the copies in covers that carry, clearly and legibly, all these
Cover Texts: Front-Cover Texts on the front cover, and
Back-Cover Texts on the back cover. Both covers must also
clearly and legibly identify you as the publisher of these
copies. The front cover must present the full title with all
words of the title equally prominent and visible. You may add
other material on the covers in addition. Copying with changes
limited to the covers, as long as they preserve the title of the
Document and satisfy these
conditions, can be treated as verbatim copying in other
respects.
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto
adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100,
you must either include a machine-readable Transparent copy along with
each Opaque copy, or state in or with each Opaque copy a
publicly-accessible computer-network location containing a
complete Transparent copy of the Document, free of added
material, which the general network-using public has access to
download anonymously at no charge using public-standard network
protocols. If you use the latter option, you must take
reasonably prudent steps, when you begin distribution of Opaque
copies in quantity, to ensure that this Transparent copy will
remain thus accessible at the stated location until at least one
year after the last time you distribute an Opaque copy (directly
or through your agents or retailers) of that edition to the
public.
It is requested, but not required, that you contact the authors
of the Document well before
redistributing any large number of copies, to give them a chance
to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of
sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the
Modified Version filling the role of the Document, thus
licensing distribution and modification of the Modified Version
to whoever possesses a copy of it. In addition, you must do
these things in the Modified Version:
A
Use in the Title
Page (and on the covers, if any) a title distinct
from that of the Document, and from those of
previous versions (which should, if there were any, be
listed in the History section of the Document). You may
use the same title as a previous version if the original
publisher of that version gives permission.
B
List on the Title
Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the
Modified Version,
together with at least five of the principal authors of
the Document (all of
its principal authors, if it has less than five).
C
State on the Title
Page the name of the publisher of the Modified Version, as the
publisher.
D
Preserve all the copyright notices of the Document.
E
Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
F
Include, immediately after the copyright notices, a
license notice giving the public permission to use the
Modified Version under
the terms of this License, in the form shown in the
Addendum below.
G
Preserve in that license notice the full lists of Invariant Sections and
required Cover
Texts given in the Document's license notice.
H
Include an unaltered copy of this License.
I
Preserve the section entitled History, and
its title, and add to it an item stating at least the
title, year, new authors, and publisher of the Modified Version as given on
the Title Page. If
there is no section entitled History in the
Document, create one
stating the title, year, authors, and publisher of the
Document as given on its Title Page, then add an item
describing the Modified Version as stated in the previous
sentence.
J
Preserve the network location, if any, given in the Document for public access
to a Transparent
copy of the Document, and likewise the network locations
given in the Document for previous versions it was based
on. These may be placed in the History
section. You may omit a network location for a work that
was published at least four years before the Document
itself, or if the original publisher of the version it
refers to gives permission.
K
In any section entitled Acknowledgements or
Dedications, preserve the section's title,
and preserve in the section all the substance and tone of
each of the contributor acknowledgements and/or
dedications given therein.
L
Preserve all the Invariant
Sections of the Document, unaltered in their
text and in their titles. Section numbers or the
equivalent are not considered part of the section titles.
M
Delete any section entitled
Endorsements. Such a section may not be
included in the Modified
Version.
N
Do not retitle any existing section as
Endorsements or to conflict in title with
any Invariant
Section.
If the Modified Version
includes new front-matter sections or appendices that qualify as
Secondary Sections and
contain no material copied from the Document, you may at your
option designate some or all of these sections as invariant. To
do this, add their titles to the list of Invariant Sections in the
Modified Version's license notice. These titles must be
distinct from any other section titles.
You may add a section entitled Endorsements,
provided it contains nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text
has been approved by an organization as the authoritative
definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage
of up to 25 words as a Back-Cover Text, to the end of
the list of Cover Texts
in the Modified Version.
Only one passage of Front-Cover Text and one of Back-Cover Text
may be added by (or through arrangements made by) any one
entity. If the Document
already includes a cover text for the same cover, previously
added by you or by arrangement made by the same entity you are
acting on behalf of, you may not add another; but you may
replace the old one, on explicit permission from the previous
publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to
assert or imply endorsement of any Modified Version .
5. COMBINING DOCUMENTS
You may combine the Document
with other documents released under this License, under the
terms defined in section 4
above for modified versions, provided that you include in the
combination all of the Invariant
Sections of all of the original documents, unmodified,
and list them all as Invariant Sections of your combined work in
its license notice.
The combined work need only contain one copy of this License,
and multiple identical Invariant
Sections may be replaced with a single copy. If there are
multiple Invariant Sections with the same name but different
contents, make the title of each such section unique by adding
at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique
number. Make the same adjustment to the section titles in the
list of Invariant Sections in the license notice of the combined
work.
In the combination, you must combine any sections entitled
History in the various original documents,
forming one section entitled History; likewise
combine any sections entitled Acknowledgements,
and any sections entitled Dedications. You must
delete all sections entitled Endorsements.6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies
of this License in the various documents with a single copy that
is included in the collection, provided that you follow the
rules of this License for verbatim copying of each of the
documents in all other respects.
You may extract a single document from such a collection, and
dispbibute it individually under this License, provided you
insert a copy of this License into the extracted document, and
follow this License in all other respects regarding verbatim
copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with
other separate and independent documents or works, in or on a
volume of a storage or distribution medium, does not as a whole
count as a Modified Version
of the Document, provided no compilation copyright is claimed
for the compilation. Such a compilation is called an
aggregate, and this License does not apply to the
other self-contained works thus compiled with the Document , on
account of their being thus compiled, if they are not themselves
derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one
quarter of the entire aggregate, the Document's Cover Texts may
be placed on covers that surround only the Document within the
aggregate. Otherwise they must appear on covers around the whole
aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with
translations requires special permission from their copyright
holders, but you may include translations of some or all
Invariant Sections in addition to the original versions of these
Invariant Sections. You may include a translation of this
License provided that you also include the original English
version of this License. In case of a disagreement between the
translation and the original English version of this License,
the original English version will prevail.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly
provided for under this License. Any other attempt to copy,
modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software
Foundation may publish new, revised versions of the GNU
Free Documentation License from time to time. Such new versions
will be similar in spirit to the present version, but may differ
in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version
number. If the Document
specifies that a particular numbered version of this License
or any later version applies to it, you have the
option of following the terms and conditions either of that
specified version or of any later version that has been
published (not as a draft) by the Free Software Foundation. If
the Document does not specify a version number of this License,
you may choose any version ever published (not as a draft) by
the Free Software Foundation.