
Free Software Project Management HOWTO

Benjamin "Mako" Hill

         <mako@debian.org>

   Diario delle Revisioni
   Revisione v0.3.2 15 aprile 2002 Revisionato da: bch
   Revisione v0.3.1 18 giugno 2001 Revisionato da: bch
   Revisione v0.3   5 maggio 2001  Revisionato da: bch
   Revisione v0.2.1 10 aprile 2001 Revisionato da: bch
   Revisione v0.2   8 aprile 2001  Revisionato da: bch
   Revisione v0.01  27 marzo 2001  Revisionato da: bch
   Prima versione

   Questo HOWTO  diretto a persone che hanno esperienza di
   programmazione, e qualche capacit nella gestione di un
   progetto software, ma che sono nuove all'esperienza del
   software libero. Questo documento vuole fungere da guida agli
   aspetti non-tecnici della gestione dei progetti di software
   libero, ed  stato scritto come corso accelerato per quelle
   capacit relazionali che non vengono insegnate ai
   programmatori commerciali, ma possono determinare il successo
   o il fallimento di un progetto di software libero. Traduzione
   a cura di Andrea Giancola. Revisione di Giulio Daprel ed
   Elisabetta Galli.
     _________________________________________________________

   Sommario
   1. Introduzione

        1.1. Copyright Information
        1.2. Disclaimer
        1.3. Nuove versioni
        1.4. Riconoscimenti
        1.5. Il feedback
        1.6. Traduzioni

   2. Iniziare un progetto

        2.1. Scegliere un progetto

              2.1.1. Identificare ed articolare l'idea
              2.1.2. Valutare l'idea

        2.2. Dare un nome al progetto
        2.3. Adottare una licenza per il programma

              2.3.1. Scegliere la licenza
              2.3.2. Il meccanismo delle licenze
              2.3.3. Avvertimento finale sulle licenze

        2.4. Scegliere un metodo di numerazione delle versioni
        2.5. Documentazione

              2.5.1. Pagine di manuale
              2.5.2. Documentazione accessibile a linea di
                      comando

              2.5.3. File che gli utenti si aspettano di trovare
              2.5.4. Sito web
              2.5.5. Altri suggerimenti sulla documentazione

        2.6. Altri problemi di presentazione

              2.6.1. Nomi dei file di pacchetto
              2.6.2. Formati dei pacchetti
              2.6.3. Sistemi di controllo di versione
              2.6.4. Suggerimenti e dritte utili per la
                      presentazione

   3. Mantenere un progetto: interagire con gli sviluppatori

        3.1. Delegare il lavoro

              3.1.1. Come delegare

        3.2. Accettare e rifiutare patch

              3.2.1. Incoraggiare un buon patching
              3.2.2. Giudizio tecnico
              3.2.3. Rifiutare delle patch

        3.3. Rami stabili e rami di sviluppo
        3.4. Altri problemi nella gestione dei progetti

              3.4.1. Congelamento

        3.5. Forks

   4. Mantenere un progetto: interagire con gli utenti

        4.1. Collaudo e collaudatori

              4.1.1. Collaudo automatizzato
              4.1.2. Collaudo eseguito da collaudatori

        4.2. Impostare un'infrastruttura di supporto

              4.2.1. Documentazione
              4.2.2. Mailing list
              4.2.3. Altre idee di supporto

        4.3. Rilasciare il programma

              4.3.1. Quando rilasciare
              4.3.2. Come rilasciare
              4.3.3. Rilasci alpha, beta, e di sviluppo

        4.4. Annunciare il progetto

              4.4.1. Mailing list e Usenet
              4.4.2. freshmeat.net
              4.4.3. Mailing List di progetto

   Bibliografia
   A. GNU Free Documentation License

        A.1. 0. PREAMBLE
        A.2. 1. APPLICABILITY AND DEFINITIONS
        A.3. 2. VERBATIM COPYING
        A.4. 3. COPYING IN QUANTITY
        A.5. 4. MODIFICATIONS
        A.6. 5. COMBINING DOCUMENTS
        A.7. 6. COLLECTIONS OF DOCUMENTS
        A.8. 7. AGGREGATION WITH INDEPENDENT WORKS
        A.9. 8. TRANSLATION
        A.10. 9. TERMINATION
        A.11. 10. FUTURE REVISIONS OF THIS LICENSE

1. Introduzione

   Basta scorrere freshmeat.net per ricavare una montagna di
   ragioni per l'esistenza di questo HOWTO: Internet 
   disseminata di programmi utili e scritti in modo eccellente,
   che per si sono dissolti nell'universo dell'oblio del
   software libero. Questo triste scenario mi ha portato a
   chiedermi: "Perch?"

   Il presente HOWTO cerca di fare molte cose (probabilmente
   troppe), ma non pu rispondere a questa domanda, e non ci
   prover. Ci che l' HOWTO cercher di fare  fornire al
   proprio progetto di software libero una chance da giocarsi, un
   vantaggio. Se si scrive una porcheria che non interessa a
   nessuno, si pu leggere questo HOWTO fino a recitarlo a
   memoria nel sonno, e nonostante questo il progetto
   probabilmente fallir. Non solo, si pu scrivere un software
   bello, utile, e seguire tutte le istruzioni di questo HOWTO e
   il proprio software ancora potrebbe non farcela. Certe volte
   la vita  cos. Comunque, mi sbilancer sino a dire che se si
   scrive un bellissimo ed utile software ed si ignorano i
   consigli di questo HOWTO, probabilmente si fallir pi spesso.

   Molte delle informazioni di questo HOWTO sono questioni di
   buon senso; naturalmente, come ogni dibattito sulle interfacce
   pu provare, ci che  buon senso per alcuni programmatori si
   dimostra completamente controintuitivo per altri. Dopo aver
   spiegato frammenti di questo HOWTO a sviluppatori di software
   libero in diverse occasioni, ho compreso che scrivere questo
   HOWTO potrebbe fornire una risorsa utile ed un punto
   d'incontro affinch i programmatori si scambino idee su ci
   che ha o non ha funzionato per loro.

    necessaria una breve introduzione alla questione licenze: ne
    cosciente chi si  trovato coinvolto in quella che sembra
   un'infinita lotta al diritto di propriet intellettuale.
     _________________________________________________________

1.1. Copyright Information

   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 nelAppendice A.
     _________________________________________________________

1.2. Disclaimer

   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.
     _________________________________________________________

1.3. Nuove versioni

   Questa versione  parte del terzo ciclo di pre-rilascio di
   questo HOWTO.  stato scritto per essere rilasciato agli
   sviluppatori per ricevere critiche e nuove idee. Si ricordi
   per favore che questa versione dell'HOWTO  ancora in uno
   stadio infantile e continuer ad essere ampiamente
   revisionata.

   L'ultimo numero di versione di questo documento dovrebbe
   sempre essere riportato sulla homepage del progetto residente
   su yukidoke.org.

   La versione pi recente di questo HOWTO sar sempre resa
   disponibile sullo stesso sito web, in una variet di formati:

     * HTML.
     * HTML (pagina singola).
     * testo semplice.
     * postscript compresso.
     * sorgente SGML compresso.
     _________________________________________________________

1.4. Riconoscimenti

   In questa versione ho il piacere di ringraziare:

   I colleghi sviluppatori Debian Martin Michlmayr e Vivek
   Venugopalan, che hanno inviato informazioni e collegamenti ad
   articoli estremamente interessanti. Entrambi sono stati
   aggiunti alla bibliografia, e sono state aggiunte all'HOWTO
   informazioni ricevute da ognuno. Grazie ad Andrew Shugg che ha
   segnalato diversi errori nel documento. Un grande grazie anche
   a Sung Wook Her (alias RedBaron) che sta facendo la prima
   traduzione dell'HOWTO in coreano. Sono stato felice di notare
   che la gente fino ad ora ha tratto giovamento e beneficio da
   questo HOWTO.

   Ringraziamenti meno recenti, ma che non voglio eliminare,
   includono: Josh Crawford, Andy King e Jaime Davila, che hanno
   letto questo documento per intero e hanno dato dei feedback
   molto utili per correggerlo e migliorarlo. Non posso
   ringraziarvi abbastanza per il vostro aiuto. Un "grazie" extra
   va ad Andy King, che ha riletto il documento diverse volte, ed
   ha inviato delle correzioni che mi hanno reso la vita pi
   facile.

   Karl Fogel, l'autore di Open Source Development with CVS,
   pubblicato dalla Coriolis Open Press. Lunghi estratti del suo
   libro sono disponibili sul web. 225 pagine del libro sono
   disponibili sotto licenza GPL, e costituiscono il miglior
   manuale introduttivo per CVS che abbia mai visto. Il resto del
   libro copre "le sfide e gli innati problemi di principio
   connessi alla conduzione di un progetto Open Source usando
   CVS." Il libro fa un buon lavoro nel coprire alcuni degli
   argomenti trattati in questo HOWTO, e molti altri. Il sito web
   del libro offre informazioni su come ordinare il libro, e
   fornisce diverse traduzioni dei capitoli su CVS. Se si 
   seriamente interessati alla conduzione di un progetto di
   software libero bisogna avere questo libro. Ho cercato di
   citare Fogel nelle sezioni di questo HOWTO in cui ero
   consapevole di stare attingendo direttamente dalle sue idee;
   se ne ho dimenticata qualcuna, chiedo venia, cercher di
   correggerle nei rilasci futuri.

   Karl Fogel pu essere contattato presso <kfogel (at) red-bean
   (dot) com>

   Anche Eric S. Raymond ha fornito materiale di supporto e
   ispirazione per questo HOWTO, con le sue discussioni
   prolifiche, coerenti e meticolose, e Lawrence Lessig mi ha
   ricordato l'importanza del software libero. Inoltre, voglio
   ringraziare tutti gli utenti e sviluppatori coinvolti nel
   progetto Debian. Debian mi ha fornito una casa, un posto dove
   praticare il patrocinio del software libero, un posto dove
   ottenere dei risultati, un posto dove imparare da quelli che
   sono parte del movimento da molto pi tempo di me. Debian mi
   ha anche fornito la testimonianza di un progetto di software
   libero che funziona davvero bene.

   Soprattutto, voglio ringraziare Richard Stallman, per il suo
   lavoro alla Free Software Foundation, e per non essersi mai
   arreso. Stallman ha stabilito e articolato le basi filosofiche
   che mi spingono verso il software libero, e che mi portano a
   scrivere un documento per far s che esso abbia successo. RMS
   pu essere sempre raggiunto via email a <rms (at) gnu (dot)
   org>.
     _________________________________________________________

1.5. Il feedback

   Ogni feedback su questo documento  sempre, senza fallo, il
   benvenuto. Senza le segnalazioni ed aggiunte dei lettori,
   questo documento non esisterebbe. Pensate che manchi qualcosa?
   Non esitate a contattarmi per farmi scrivere un capitolo,
   sezione o sottosezione, o per scriverne una voi stessi. Voglio
   che questo documento sia un prodotto di quel processo di
   sviluppo del software libero che mira a promuovere, e penso
   che il suo successo finale si fondi sulla sua capacit di
   esserlo davvero. Per favore inviate le vostre aggiunte,
   commenti e critiche al seguente indirizzo email:
   <mako@debian.org>.
     _________________________________________________________

1.6. Traduzioni

   Non tutti parlano inglese. Le traduzioni sono una buona cosa,
   e sarebbe molto bello che questo HOWTO raggiungesse quella
   portata internazionale che la traduzione di un documento
   comporta.

   Sono stato contattato da un lettore che promette una
   traduzione in coreano. Tuttavia, questo HOWTO  ancora
   giovane, ed oltre alla promessa del coreano, solamente
   l'inglese  disponibile; se voleste contribuire a, o eseguire
   per intero, una traduzione, otterreste il mio completo
   rispetto e ammirazione, e diventereste parte di un processo
   molto interessante. Se siete interessati, per favore non
   esitate a contattarmi a: <mako@debian.org>.
     _________________________________________________________

2. Iniziare un progetto

   Senza dubbio l'inizio  il periodo pi difficile per gestire
   con successo un progetto di software libero: la posa di
   fondamenta solide determiner se il progetto prosperer o
   avvizzir fino a morire.  anche l'argomento di pi immediato
   interesse per chiunque legga questo documento come una guida.

   Iniziare un progetto implica un dilemma che come programmatori
   bisogna affrontare: nessun potenziale utente del programma 
   interessato ad un programma che non funziona, ma d'altra parte
   il processo di sviluppo che si vuole impiegare ha come
   imperativo il coinvolgimento degli utenti.

    in questi pericolosi momenti iniziali che chi si sta dando
   da fare per iniziare un progetto di software libero deve
   cercare un equilibrio tra queste esigenze. Uno dei modi pi
   importanti per farlo  stabilire una struttura solida per il
   processo di sviluppo attraverso alcuni dei suggerimenti
   delineati in questa sezione.
     _________________________________________________________

2.1. Scegliere un progetto

   Se si sta leggendo questo documento, ci sono buone probabilit
   che si abbia gi in mente un'idea per un progetto. Ci sono
   anche discrete probabilit che questa idea possa soddisfare
   una lacuna percepita anche da altri, facendo qualcosa che
   nessun altro progetto di software libero fa, o facendolo in un
   modo sufficientemente peculiare da necessitare di un nuovo
   software.
     _________________________________________________________

2.1.1. Identificare ed articolare l'idea

   Eric S. Raymond scrive di come nascono i progetti software nel
   suo nuovo saggio, " The Cathedral and the Bazaar", che  quasi
   una lettura obbligatoria per ogni sviluppatore di software
   libero.  disponibile online.

   In "The Cathedral and the Bazaar" Raymond dice che: "ogni buon
   lavoro software comincia grattando il prurito di uno
   sviluppatore." L'ipotesi di Raymond, ora largamente accettata,
    che i nuovi programmi di software libero siano scritti prima
   di tutto per risolvere un problema specifico presentatosi allo
   sviluppatore.

   Se si ha in mente un'idea per un programma, ci sono buone
   probabilit che affronti un problema, o "prurito", che ci si
   vuole grattare: questa idea  il progetto. Esprimerla con
   chiarezza, scriverla, descrivere in dettaglio il problema che
   si vuole affrontare: il successo del progetto nel trattare un
   particolare problema sar legato all'abilit nell'identificare
   quel problema con chiarezza fin dall'inizio. Si scopra cosa si
   vuole che il proprio progetto faccia esattamente.

   Monty Manley esprime l'importanza di questo passo iniziale in
   un saggio, "Managing Projects the Open Source Way." Come
   mostrer la prossima sezione, c' molto lavoro da fare prima
   ancora che il software sia pronto per essere programmato.
   Manley dice: "Iniziare come si deve un progetto Open Source
   significa che uno sviluppatore deve prima di tutto evitare di
   scrivere codice troppo presto!"
     _________________________________________________________

2.1.2. Valutare l'idea

   Nel valutare l'idea, bisogna per prima cosa porsi alcune
   domande. Questo dovrebbe avvenire prima di avanzare
   ulteriormente nella lettura del presente HOWTO. Ci si chieda:
   il modello di sviluppo del software libero  davvero quello
   giusto per il proprio progetto?

   Ovviamente, dal momento che il programma gratta un proprio
   prurito, si  certamente interessati a vederlo implementato in
   codice. Ma, poich un singolo hacker che programma in
   solitudine non si pu qualificare come uno sforzo di sviluppo
   di software open source, ci si deve porre una seconda domanda:
   qualcun altro potrebbe essere interessato?

   Certe volte la risposta  un semplice "no". Se si vuole
   scrivere un insieme di script per ordinare la propria raccolta
   di MP3 sulla propria macchina, forse il modello di sviluppo
   del software libero non  quello giusto. D'altro canto, se si
   vuole scrivere un insieme di script per ordinare gli MP3 di
   chiunque, un progetto di software libero potrebbe utilmente
   riempire un vuoto.

   Fortunatamente Internet  un luogo cos grande e variegato che
    possibile che qualcuno, da qualche parte, condivida i propri
   interessi e provi lo stesso "prurito". E il fatto che ci siano
   cos tante persone con bisogni e desideri cos simili tra loro
   introduce la terza domanda principale: qualcuno ha gi avuto
   la propria idea, o un'idea abbastanza simile? 
     _________________________________________________________

2.1.2.1. Trovare progetti simili

   Ci sono posti dove si pu andare, sul web, per cercare di
   rispondere alla domanda di cui sopra. Se si ha esperienza con
   la comunit del software libero probabilmente si ha gi
   familiarit con molti di questi siti. Tutte le risorse
   elencate sotto consentono di effettuare ricerche nei propri
   database:

   freshmeat.net
          freshmeat.net si autodefinisce come "il pi grande
          indice sul Web per software Linux e Open Source" e la
          sua reputazione al riguardo  ineguagliabile e
          indiscussa. Se non si riesce a trovare qualcosa su
          freshmeat,  difficile che lo si possa trovare altrove.

   Slashdot
          Slashdot fornisce "Notizie per nerd. Roba che conta",
          il che di solito comprende discussioni sul software
          libero, l'open source, la tecnologia, e notizie ed
          eventi sulla cultura geek. Non  insolito che un
          progetto di sviluppo particolarmente allettante venga
          annunciato qui, perci vale indubbiamente la pena di
          controllare.

   SourceForge
          SourceForge ospita e promuove un numero crescente di
          progetti open source e di software libero. Sta anche
          rapidamente diventando un punto di incontro ed una
          sosta obbligata per gli sviluppatori di software
          libero. La sua mappa dei software e le pagine dei nuovi
          rilasci dovrebbero essere soste obbligate prima di
          imbarcarsi in un nuovo progetto software. SourceForge
          fornisce anche una biblioteca di frammenti di codice
          che contiene utili pezzetti di codice riusabili, in
          tutta una gamma di linguaggi, che possono tornare utili
          in qualsiasi progetto.

   Google e la Linux Search di Google
          Google e la Linux Search di Google offrono potenti
          strumenti di ricerca del web che possono far scoprire
          persone che lavorano su progetti simili. Non  un
          catalogo di software o informazioni come freshmeat o
          Slashdot, ma vale la pena di controllare, per
          assicurarsi di non dirigere i propri sforzi verso un
          progetto ridondante.
     _________________________________________________________

2.1.2.2. Decidere di procedere

   Una volta che si  mappata con successo la zona delle
   operazioni, e si ha un'idea di quali progetti di software
   libero somiglianti esistono, ogni sviluppatore deve decidere
   se andare avanti con il proprio progetto.  raro che un nuovo
   progetto cerchi di raggiungere un obiettivo che non  affatto
   simile o collegato all'obiettivo di un altro progetto.
   Chiunque cominci un nuovo progetto deve chiedersi: "il nuovo
   progetto duplicher il lavoro fatto da un altro progetto? il
   nuovo progetto si procaccer sviluppatori ai danni di un
   progetto esistente? gli obiettivi del nuovo progetto possono
   essere raggiunti aggiungendo funzionalit ad un progetto
   esistente?"

   Se la risposta ad almeno una di queste domande  "s", si
   provi a contattare lo sviluppatore del progetto (o dei
   progetti) esistente in questione per capire se lui o lei
   sarebbe disposto a collaborare.

   Per molti sviluppatori questo  l'aspetto pi ostico della
   gestione dei progetti di software libero, ma  un aspetto
   essenziale:  facile appassionarsi ad un'idea e lasciarsi
   prendere dall'impeto e dall'eccitazione di un nuovo progetto.
   Spesso  estremamente difficile da fare, ma  importante che
   ogni sviluppatore di software libero ricordi che l'interesse
   della comunit del software libero, e il modo pi veloce per
   raggiungere gli obiettivi del proprio progetto e di progetti
   simili, spesso pu consistere nel non dare il via ad un nuovo
   processo di sviluppo.
     _________________________________________________________

2.2. Dare un nome al progetto

   Anche se ci sono un sacco di progetti che falliscono pur
   avendo nomi descrittivi, e un sacco che hanno successo pur
   senza averli, quando si d un nome al progetto vale la pena di
   pensarci un po' sopra. Leslie Orchard affronta questo problema
   in un articolo pubblicato su Advogato. L'articolo  breve e
   sicuramente merita almeno un'occhiata.

   Il riassunto  che Orchard raccomanda di scegliere un nome
   tale che, dopo averlo udito, molti utenti o sviluppatori:

     * sapranno cosa fa il progetto
     * se ne ricorderanno un domani

   Curiosamente il progetto di Orchard, "Iajitsu," non fa nessuna
   delle due cose. Probabilmente non c' alcuna correlazione col
   fatto che lo sviluppo di quel progetto si  arrestato da
   quando l'articolo  stato scritto.

   Comunque l'argomento  convincente. Ci sono aziende il cui
   solo lavoro consiste nell'inventare nomi per dei software.
   Tirano su una quantit di denaro incredibile facendolo, ed 
   opinione comune che valgano tutto questo denaro. Anche se
   probabilmente non ci si pu permettere un'azienda come questa,
   ci si pu permettere di trarre un insegnamento dalla loro
   esistenza, e riflettere un momento sul nome che si sta dando
   al proprio progetto, perch conta.

   Se c' un nome che sta a cuore, ma che non rispetta i criteri
   di Orchard, si pu continuare comunque. Penso che "gnubile"
   fosse uno dei migliori nomi che abbia mai sentito per un
   progetto di software libero, e ancora ne parlo, nonostante sia
   trascorso molto tempo da quando ho smesso di usare il
   programma. Comunque, se si  flessibili su questo argomento,
   si ascolti il consiglio di Orchard. Potrebbe aiutare.
     _________________________________________________________

2.3. Adottare una licenza per il programma

   Ad un certo livello (piuttosto semplicistico), la differenza
   tra un software libero ed un software proprietario  la
   licenza. Una licenza aiuta come sviluppatori proteggendo i
   propri diritti legali ad ottenere la distribuzione del proprio
   software alle proprie condizioni, ed incoraggia coloro che
   vorrebbero aiutare il proprio progetto a partecipare.
     _________________________________________________________

2.3.1. Scegliere la licenza

   Qualsiasi discussione sulle diverse licenze genera sicuramente
   almeno una piccola flame war, poich ci sono forti convinzioni
   che alcune licenze di software libero siano migliori di altre.
   Questa discussione porta anche alla ribalta la questione del
   "software open source" e il dibattito sui termini "software
   open source" e "software libero". Ad ogni buon conto, poich
   ho scritto un HOWTO sulla gestione dei progetti di software
   libero, e non un HOWTO sulla gestione dei progetti software
   open source, la mia scelta di campo  chiara.

   Nel tentativo di raggiungere un diplomatico compromesso, senza
   sacrificare la mia personale filosofia, consiglio di scegliere
   una qualsiasi licenza che si conformi alle Debian Free
   Software Guidelines. Scritte originariamente dal progetto
   Debian sotto la guida di Bruce Perens, le DFSG costituiscono
   la prima versione della definizione di Open Source. Esempi di
   licenze libere forniti dalle DFSG sono la GPL, la BSD, e la
   Licenza Artistica. Come accennato nell'HOWTO[ESRHOWTO] di ESR,
   se possibile evitare di scrivere una propria licenza. Le tre
   licenze citate hanno tutte lunghe tradizioni interpretative.
   Sono anche senza dubbio software libero (e possono quindi
   essere distribuite come parte di Debian, e in altri posti che
   consentono lo scambio di software libero).

   Conformemente alla definizione di software libero fornita da
   Richard Stallman in "The Free Software Definition", ognuna di
   queste licenze garantisce "la libert per gli utenti di
   eseguire, copiare, distribuire, esaminare, modificare e
   migliorare il software". Ci sono un sacco di altre licenze che
   si conformano alle DFSG, ma rifarsi ad una licenza pi diffusa
   offrir il vantaggio di un immediato riconoscimento e
   comprensione. Molte persone scrivono tre o quattro frasi in un
   file COPYING e ritengono di aver scritto una licenza di
   software libero: come prova la mia lunga esperienza con la
   mailing list debian-legal molto spesso non  cos.

   Tentando un'analisi pi approfondita, sono d'accordo con Karl
   Fogel che divide le licenze in due gruppi: le GPL, e quelle
   diverse dalla GPL.

   Personalmente, licenzio tutto il mio software sotto la GPL.
   Creata e difesa dalla Free Software Foundation e dal GNU
   Project, la GPL  la licenza usata dal kernel Linux, da GNOME,
   da Emacs, e dalla gran parte del software GNU/Linux.  la
   scelta naturale, ed io penso che sia una buona scelta. Ogni
   fanatico BSD ci tiene a ricordare che la peculiare
   contagiosit della GPL impedisce la mescolanza di codice GPL
   con codice non-GPL; secondo molte persone (me compreso) questo
    un beneficio, ma secondo alcuni  un grosso svantaggio.

   Molte persone scrivono tre o quattro frasi in un file COPYING
   e ritengono di aver scritto una licenza di software libero:
   come prova la mia lunga esperienza con la mailing list
   debian-legal, molto spesso non  cos. Pu non proteggere
   l'autore, pu non proteggere il software, e pu rendere le
   cose molto difficili per chi voglia usare il software ma
   presta molta attenzione ai sottili dettagli legali delle
   licenze. Se ci si tiene molto ad una licenza fatta in casa, la
   si passi prima a qualcuno all'OSI o alla mailing list
   debian-legal, prima di tutto per proteggersi da imprevisti
   effetti collaterali.

   Le tre licenze pi importanti si possono trovare ai seguenti
   siti:

     * La GNU General Public License;
     * la licenza BSD;
     * la licenza Artistica. 

   In ogni caso, si legga ogni licenza prima di usarla per
   rilasciare il proprio software. Come sviluppatori principali,
   non ci si possono permettere sorprese sulle licenze.
     _________________________________________________________

2.3.2. Il meccanismo delle licenze

   Il testo della GPL offre una buona descrizione della meccanica
   di applicazione di una licenza ad un nuovo software. La mia
   lista di controllo rapido per l'applicazione di una licenza
   comprende:

     * rendere se stessi o la FSF il detentore del copyright per
       il lavoro. In qualche raro caso, si potrebbe desiderare
       che il detentore del copyright sia qualche organizzazione
       sponsorizzatrice (se  sufficientemente grande e potente).
       Fare questo  semplice, basta inserirne il nome nello
       spazio apposito quando si modifica la nota sul copyright
       riportata sotto. Contrariamente a quanto comunemente si
       crede, non c' bisogno di affiliarsi ad alcuna
       organizzazione: la nota da sola  sufficiente per
       rivendicare il diritto d'autore sul proprio lavoro;
     * se mai fosse possibile, attaccare e distribuire una copia
       completa della licenza sia con i sorgenti che con i
       binari, aggiungendo un file a se stante;
     * in cima ad ogni file sorgente del proprio programma
       inserire una nota di copyright, ed includere informazioni
       su dove pu essere reperita la licenza integrale. La GPL
       raccomanda che ogni file cominci con:
una riga per specificare il nome del programma e dare un'idea di cosa f
a.
Copyright (C) yyyy  nome dell'autore

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 prosegue raccomandando di aggiungere indicazioni su
       come contattare l'autore, via email o posta;
     * la GPL continua consigliando, se il programma viene
       eseguito in modalit interattiva, di far s che ogni volta
       che entra in tale modalit stampi una nota che includa un
       messaggio come il seguente, che indirizza alle
       informazioni complete sulla licenza del programma:
Gnomovision version 69, Copyright (C) anno nome dell'autore
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'.  This is free software, and you are welcome
to redistribute it under certain conditions; type `show c'
for details.

     * infine, pu essere utile includere una "copyright
       disclaimer" da parte del datore di lavoro o di una scuola,
       se si lavora come programmatori o se  verosimile che il
       proprio datore di lavoro, o scuola, possa in futuro
       accampare diritti di propriet sul proprio codice. Non ce
       n' bisogno frequentemente, ma ci sono molti sviluppatori
       di software libero che sono finiti nei guai, e vorrebbero
       avere chiesto una rinuncia di questo genere.
     _________________________________________________________

2.3.3. Avvertimento finale sulle licenze

   Per favore, per favore, per favore, porre il proprio software
   sotto il riparo di qualche licenza. Pu non sembrare
   importante, e per voi pu non esserlo, ma le licenze sono
   importanti. Perch un pacchetto software sia incluso nella
   distribuzione GNU/Linux Debian, deve avere una licenza che
   soddisfi le linee guida per il software libero di Debian: se
   il proprio software non ha licenza, non potr essere
   distribuito come pacchetto Debian fino a che non sar
   ri-rilasciato sotto una licenza libera. Rilasciare la prima
   versione del proprio software sotto una licenza chiara
   risparmier a tutti una seccatura.
     _________________________________________________________

2.4. Scegliere un metodo di numerazione delle versioni

   La cosa pi importante per un sistema di numerazione delle
   versioni  che ce ne sia uno. Pu sembrare pedante enfatizzare
   questo punto, ma  sorprendente il numero di scripts e piccoli
   programmi che saltano fuori senza alcun numero di versione.

   La seconda cosa pi importante per un sistema di numerazione 
   che i numeri aumentino sempre. I sistemi di tracciamento
   automatico delle versioni, e la percezione comune di un ordine
   universale, finirebbero in pezzi se i numeri di versione non
   crescessero sempre. Non  molto importante che 2.1 sia un
   grande salto e 2.0.005 un piccolo salto, ma  importante che
   2.1 sia pi recente di 2.0.005.

   Seguendo queste due semplici regole non si sbaglier (troppo).
   Oltre a questo, la tecnica pi comune sembra essere lo schema
   di numerazione delle versioni "livello principale", "livello
   secondario", "livello di patch". Che si sia familiari o meno
   con questo nome, ci si interagisce di continuo. Il primo
   numero  il numero principale, e indica importanti cambiamenti
   o riscritture; il secondo numero  il numero secondario, e
   rappresenta funzionalit aggiunte o ritoccate basate su una
   struttura in gran parte coerente; il terzo numero  il numero
   di patch, e di solito si riferisce solo a rilasci che
   correggono dei bug.

   L'uso molto diffuso di questo schema  il motivo per cui si
   conoscono la natura e il grado relativo delle differenze tra
   un rilascio 2.4.12 del kernel Linux ed un 2.4.11, 2.2.12, e
   1.2.12, pur senza conoscere nulla su nessuno di questi
   rilasci.

   Si possono modificare o ignorare queste regole, e c' chi lo
   fa. Ma attenzione, se si sceglie di farlo, qualcuno si
   arrabbier, immaginer che non le conosciate, e tenter di
   insegnarvele, probabilmente non molto gentilmente. Io uso
   sempre questo metodo, e prego anche voi di farlo.

   Ci sono diversi sistemi di numerazione delle versioni
   piuttosto conosciuti, e che potrebbe valere la pena di
   investigare prima di rilasciare la propria prima versione.

   Numerazione delle versioni del kernel di Linux:
          Il kernel di Linux adotta un sistema di numerazione
          delle versioni in cui ogni numero di versione minore
          dispari si riferisce ad un rilascio di sviluppo o di
          collaudo, ed ogni numero di versione minore pari si
          riferisce ad una versione stabile. Pensandoci per un
          secondo, con questo sistema, i kernel 2.1 e 2.3 erano e
          saranno sempre kernel di sviluppo o di collaudo, mentre
          i kernel 2.0, 2.2 e 2.4 sono tutti codice di
          produzione, con maggior grado di stabilit e pi
          collaudati.

          Sia che si preveda di avere un modello di sviluppo
          suddiviso (come descritto nel la Sezione 3.3), sia che
          si preveda di rilasciare una sola versione alla volta,
          la mia esperienza con diversi progetti di software
          libero e con il progetto Debian mi ha insegnato che
          l'uso del sistema di numerazione delle versioni di
          Linux merita di essere preso in considerazione. In
          Debian, tutte le versioni secondarie sono distribuzioni
          stabili (2.0, 2.1, etc). Ciononostante, molta gente
          crede che la versione 2.1 sia instabile o di sviluppo,
          e continua ad usare una versione pi vecchia fino a che
           cos frustrata dalla mancanza di progressi nello
          sviluppo che protesta, e capisce il sistema. Se non si
          rilascia mai un numero di versione secondaria dispari
          ma solo quelli pari, nessuno viene danneggiato, e meno
          persone saranno confuse:  un'idea che merita di essere
          presa in considerazione.

   Numerazione delle versioni di Wine:
          A causa della natura insolita dello sviluppo di Wine,
          per cui il non-emulatore migliora costantemente, ma non
          si dirige verso un obiettivo immediatamente
          raggiungibile, Wine  rilasciato ogni tre settimane.
          Questo viene fatto etichettando i rilasci in un formato
          "Anno Mese Giorno", in cui ogni rilascio sar
          etichettato "wine-XXXXXXXX", cio la versione del 4
          Gennaio 2000 sarebbe "wine-20000104". Per certi
          progetti, il formato "Anno Mese Giorno" pu avere molto
          senso.

   Le pietre miliari di Mozilla:
          Se si considerano Netscape 6 e le sue versioni
          commerciali, si nota che la struttura degli sviluppi
          del progetto Mozilla  uno dei modelli di software
          libero pi complicati in circolazione. La numerazione
          delle versioni riflette la situazione, unica nel suo
          genere, in cui questo progetto viene sviluppato.

          La struttura dei numeri di versione di Mozilla
          storicamente  stata composta di pietre miliari. Sin
          dall'inizio del progetto Mozilla, gli obiettivi del
          progetto, nell'ordine e nella misura in cui li si
          sarebbe dovuti raggiungere, erano tracciati su una
          serie di road map; i punti ed i risultati principali
          lungo queste road-map erano contrassegnati come pietre
          miliari. Quindi, anche se Mozilla era compilato e
          distribuito ogni sera come "nightly build", nel giorno
          in cui gli obiettivi di una pietra miliare erano stati
          raggiunti, quella particolare build era contrassegnata
          come "release milestone".

          Anche se non ho visto impiegare questo metodo in nessun
          altro progetto sinora, l'idea mi piace, e penso che sia
          valida per i rami di collaudo o di sviluppo di una
          grande applicazione con una intensa attivit di
          sviluppo.
     _________________________________________________________

2.5. Documentazione

   Un numero enorme di applicazioni altrimenti fantastiche 
   avvizzito e morto perch il loro autore era la sola persona
   che sapesse usarle appieno. Anche se il proprio programma 
   scritto principalmente per un gruppo di utenti
   tecnologicamente preparati, la documentazione  di aiuto, e
   finanche necessaria, per la sopravvivenza del progetto. Si
   imparer pi avanti, nel la Sezione 4.3, che bisogna sempre
   rilasciare qualcosa di utilizzabile. Un software privo di
   documentazione non  utilizzabile.

   La documentazione deve essere scritta per un pubblico molto
   vario, e ci sono molti modi per documentare un progetto.
   L'importanza della documentazione all'interno del codice per
   facilitare lo sviluppo da parte di una comunit estesa 
   vitale, ma esula dagli intenti di questo HOWTO. Stando cos le
   cose, questa sezione tratta tecniche utili per la
   documentazione rivolta agli utenti finali.

   Un sistema semi-ufficiale di documentazione, valido per la
   maggior parte dei progetti di software libero, e che vale la
   pena di seguire,  il risultato finale di una combinazione di
   tradizione e necessit. Sia gli utenti che gli sviluppatori si
   aspettano di poter ottenere documentazione in diversi modi, e
   se si vuole far decollare il progetto  essenziale fornire, in
   una forma leggibile, le informazioni che stanno cercando. La
   gente si aspetta di trovare:
     _________________________________________________________

2.5.1. Pagine di manuale

   Gli utenti vorrano poter digitare "man nomedelprogetto" ed
   ottenere una pagina di manuale gradevolmente impaginata che
   illustri le basi dell'uso dell' applicazione. Ci si assicuri,
   prima di rilasciare il programma, di averci pensato.

   Non  difficile scrivere le pagine di manuale. Eccellente
   documentazione sul processo di scrittura delle pagine di
   manuale  disponibile nel "Linux Man-Page-HOWTO", accessibile
   tramite il progetto Linux Documentation (LDP) e scritto da
   Jens Schweikhardt.  reperibile dal suo sito o presso (LDP).

    anche possibile scrivere pagine man usando l'SGML di
   DocBook. Poich le pagine man sono cos semplici, e la
   metodologia DocBook relativamente nuova, non ho avuto modo di
   seguire l'argomento, ma sarei felice di ricevere aiuto da
   chiunque possa darmi ulteriori informazioni sulla cosa.
     _________________________________________________________

2.5.2. Documentazione accessibile a linea di comando

   La maggior parte degli utenti si aspetta che una quantit
   minima di documentazione sia facilmente disponibile dalla
   linea di comando. Questo tipo di documentazione dovrebbe
   difficlmente superare una schermata (24 o 25 righe), ma
   dovrebbe coprire l'uso di base, una breve descrizione del
   programma (una o due frasi), una lista dei comandi con
   spiegazione, e tutte le opzioni principali (anche queste con
   spiegazione), pi un riferimento a documentazione pi
   approfondita per chi ne avesse bisogno. La documentazione a
   linea di comando per il programma Debian apt-get fornisce un
   ottimo esempio e un utile modello:
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.


    diventata una convenzione GNU quella di rendere accessibili
   queste informazioni con le opzioni "-h" e "--help". La maggior
   parte degli utenti GNU/Linux si aspetter di poter recuperare
   in questo modo la documentazione di base, perci se si sceglie
   di usare metodi diversi ci si prepari alle polemiche e alle
   conseguenze che ne possono derivare.
     _________________________________________________________

2.5.3. File che gli utenti si aspettano di trovare

   In aggiunta alle pagine man e all'help a linea di comando, ci
   sono dei file che chi  in cerca di documentazione
   controller, specialmente nei pacchetti che contengono codice
   sorgente. In una distribuzione di sorgenti, la maggior parte
   di questi file pu essere conservata nella directory radice
   della distribuzione, o in una sotto-directory chiamata "doc" o
   "Documentation". File comunemente in queste posizioni sono:

   README o Readme
          Un documento che contiene tutte le istruzioni di base
          per l'installazione, la compilazione, ed anche l'uso:
          l'insieme minimo di informazioni necessarie per far
          funzionare il programma. Un README non  l'occasione
          giusta per essere prolissi, dovrebbe essere conciso ed
          efficace. Un README ideale  lungo almeno 30 righe, e
          non pi di 250.

   INSTALL o Install
          Il file INSTALL dovrebbe essere molto pi breve del
          README, e dovrebbe descrivere brevemente e con rapidit
          come compilare e installare il programma. Di solito un
          file di INSTALL dice semplicemente all'utente di
          lanciare "./configure; make; make install", ed accenna
          a eventuali opzioni o azioni insolite che possono
          rendersi necessarie. Per la maggior parte delle
          procedure di installazione relativamente standard, e
          per la maggior parte dei programmi, i file INSTALL sono
          il pi brevi possibile: raramente superano le 100
          righe.

   CHANGELOG, Changelog, ChangeLog, o changelog
          Un CHANGELOG  un file semplice che ogni progetto di
          software libero ben gestito dovrebbe includere. Un
          CHANGELOG non  altro che il file che, come suggerisce
          il nome, registra o documenta i cambiamenti che vengono
          fatti ad un programma. Il modo pi semplice di tenere
          un CHANGELOG  semplicemente conservare tale file
          insieme al codice sorgente del programma, e a ogni
          rilascio aggiungervi in cima una sezione che descrive
          cosa  stato cambiato, corretto, o aggiunto, al
          programma.  una buona idea pubblicare il CHANGELOG
          anche sul sito web, perch pu aiutare la gente a
          capire se vogliono o  necessario aggiornarsi ad una
          versione pi recente, o se invece  meglio aspettare
          dei miglioramenti pi significativi.

   NEWS
          Un file NEWS e un ChangeLog si assomigliano, ma
          diversamente da un CHANGELOG, un file NEWS non 
          solitamente aggiornato in occasione di nuove versioni:
          ogni qualvolta si aggiungono nuove funzionalit, lo
          sviluppatore responsabile lo annoter sul file NEWS. I
          file NEWS non dovrebbero essere cambiati prima di un
          rilascio (dovrebbero essere mantenuti aggiornati di
          continuo), ma di solito  una buona idea controllare in
          ogni caso perch spesso gli sviluppatori semplicemente
          dimenticano di mantenerli aggiornati.

   FAQ
          Per i pochi che ancora non lo sanno, FAQ sta per
          Frequently Asked Questions (domande frequenti), e una
          FAQ per l'appunto  una loro raccolta. Non  difficile
          costruire un file di FAQ: semplicemente si stabilisca
          una prassi per cui se viene posta una domanda, o si
          legge una domanda su una mailing list, pi di una
          volta, la domanda (e la relativa risposta) verr
          aggiunta alle FAQ. Le FAQ sono meno indispensabili dei
          file elencati sopra, ma possono far risparmiare tempo,
          migliorare l'usabilit, e diminuire il mal di testa a
          tutti quanti.
     _________________________________________________________

2.5.4. Sito web

    solo indirettamente una questione di documentazione, ma un
   buon sito web sta rapidamente diventando una parte essenziale
   di ogni progetto di software libero. Il sito web dovrebbe
   fornire accesso alla documentazione (in HTML se possibile);
   dovrebbe anche includere una sezione per notizie ed eventi
   relativi al programma, ed una sezione che descriva in
   dettaglio come partecipare allo sviluppo o al collaudo,
   invitando esplicitamente alla collaborazione. Dovrebbe anche
   fornire collegamenti a mailing lists, ad altri siti
   pertinenti, e fornire un collegamento diretto a tutte le
   modalit possibili di scaricamento del software.
     _________________________________________________________

2.5.5. Altri suggerimenti sulla documentazione

     * Tutta la documentazione dovrebbe essere in formato di
       testo semplice, o, nel caso in cui sia accessibile
       principalmente dal sito, in HTML: tutti sono in grado di
       visualizzare un file con cat, tutti sono in grado di
       visualizzare il testo una pagina per volta, (quasi) tutti
       sono in grado di leggere documenti HTML. Se si vogliono
       distribuire informazioni in PDF, PostScript, RTF, o
       qualsiasi altro formato ampiamente usato, saranno ben
       accolte, ma queste informazioni devono essere disponibili
       anche in testo semplice o HTML, altrimenti c' chi si
       arrabbier molto. Secondo me anche info ricade in questa
       categoria. C' un sacco di fantastica documentazione GNU
       che qualcuno semplicemente non legge perch c' solo sotto
       forma di info. E questo infastidisce davvero la gente. Non
        una questione di formati migliori o peggiori;  una
       questione di accessibilit, e lo stato di cose attuale 
       la causa principale di questa intransigenza;
     * non guasta distribuire tutta la documentazione presente
       sul sito web (FAQ eccetera) insieme al programma. Non si
       esiti a buttare tutto quanto nel tarball del programma: se
       la gente non ne avr bisogno, lo canceller. Continuo a
       ripeterlo: troppa documentazione non  peccato;
     * a meno che il software sia valido solo per una lingua
       diversa dall'inglese (un editor di lingua giapponese, per
       esempio), per favore lo si distribuisca con documentazione
       in lingua inglese. Se non si parla l'inglese o comunque
       non si ha fiducia nel proprio livello di conoscenza, si
       chieda aiuto ad un amico. Che piaccia o no, giusto o
       ingiusto che sia, l'inglese  la lingua del software
       libero. Comunque, questo non vuol dire che la
       documentazione debba essere limitata all'inglese; chi
       parla un'altra lingua pu distribuire traduzioni della
       documentazione insieme al software, se ha il tempo e
       l'energia per farlo. Sicuramente la cosa sar utile a
       qualcuno;
     * infine, per favore controllare l'ortografia della propria
       documentazione; gli errori ortografici nella
       documentazione sono dei bug. Io sono tra i primi colpevoli
       di questo errore, che  estremamente facile da commettere.
       Se l'inglese non  la propria lingua madre, si faccia
       controllare o correggere la documentazione e le pagine web
       da qualcuno di madrelingua inglese: ortografia o
       grammatica imprecise contribuiscono molto a far apparire
       il codice poco professionale. Nei commenti al codice
       queste cose sono meno importanti, ma nelle pagine di
       manuale e nelle pagine web errori del genere non sono
       accettabili.
     _________________________________________________________

2.6. Altri problemi di presentazione

   Molti dei restanti problemi legati alla creazione di un nuovo
   programma di software libero ricadono sotto quello che molta
   gente chiama buon senso. Si dice spesso che l'ingegneria del
   software  al 90 per cento buon senso, combinato con il 10 per
   cento di conoscenze specialistiche; eppure, vale la pena di
   sottolineare questi problemi, nella speranza che possano far
   ricordare ad uno sviluppatore qualcosa che aveva dimenticato.
     _________________________________________________________

2.6.1. Nomi dei file di pacchetto

   Sono d'accordo con Eric Steven Raymond quando dice che: "
   utile a tutti che i file di archivio abbiano dei nomi
   strutturati come in GNU: una radice alfanumerica tutta
   minuscola, seguita da un punto, seguito da un numero di
   versione, da un'estensione, ed altri suffissi." Ci sono altre
   informazioni (inclusi molti esempi di cosa non fare) nel suo
   Software Release Practices HOWTO, che  incluso nella
   bibliografia di questo HOWTO e si pu recuperare dal LDP.
     _________________________________________________________

2.6.2. Formati dei pacchetti

   I formati dei pacchetti possono differenziarsi a seconda del
   sistema per cui si sta sviluppando: per software basato su
   Windows gli archivi zip (.zip) di solito sono il formato
   eletto; se si sta sviluppando per GNU/Linux, *BSD, o qualche
   UN*X, ci si assicuri che il codice sorgente sia sempre
   disponibile in formato tar compresso con gzip (.tar.gz). Il
   compress di UNIX (.Z)  fuori moda ed inutile; la maggior
   velocit dei computer ha portato alla ribalta bzip2 (.bz2)
   come mezzo di compressione pi efficace. Ora io rendo
   disponibili tutti i miei rilasci come tarball compressi sia
   con gzip che con bzip2.

   I pacchetti binari dovrebbero sempre essere specifici per una
   distribuzione; se si ha la possibilit di compilare pacchetti
   binari per la versione attuale di una delle distribuzioni
   principali di Linux, gli utenti ne saranno felici. Si cerchi
   di promuovere le relazioni con gli utenti o gli sviluppatori
   di grandi distribuzioni, per sviluppare un sistema per la
   creazione coerente di pacchetti binari.  spesso una buona
   idea fornire RPM per RedHat (.rpm), deb per Debian (.deb), e
   RPM di sorgenti (SRPM) se possibile. Da ricordare: anche se 
   una cosa gentile fornire questi pacchetti binari, confezionare
   e rilasciare i sorgenti dovrebbe avere sempre la priorit. Gli
   utenti o i colleghi sviluppatori possono creare i pacchetti
   binari, e lo faranno.
     _________________________________________________________

2.6.3. Sistemi di controllo di versione

   Un sistema di controllo di versione pu rendere meno
   problematici molti di questi problemi di confezionamento (e
   molti altri problemi menzionati in questo HOWTO). Se si sta
   usando *NIX, CVS  la scelta migliore; vi consiglio di tutto
   cuore il libro di Karl Fogel sull'argomento (e la versione
   pubblicata in HTML).

   CVS o no, si farebbe probabilmente bene ad investire un po' di
   tempo per imparare un sistema di controllo di versione, perch
   fornisce una soluzione automatica per risolvere molti dei
   problemi descritti in questo HOWTO. Non sono a conoscenza di
   alcun sistema di controllo di versione libero per Windows o
   Mac OS, ma so che esistono client CVS per entrambe le
   piattaforme. Siti web come SourceForge rendono un ottimo
   servizio, con una interfaccia web per CVS carina e facile da
   usare.

   Vorrei dedicare pi spazio in questo HOWTO a CVS, perch mi
   piace un sacco (lo uso anche per tenere ordine tra le versioni
   di questo HOWTO!), ma penso che sia al di fuori degli
   obiettivi di questo documento, e in pi ha gi i suoi HOWTO
   dedicati. Il pi degno di nota  CVS Best Practices HOWTO
   [CVSBESTPRACTICES], incluso nella bibliografia allegata.
     _________________________________________________________

2.6.4. Suggerimenti e dritte utili per la presentazione

   Altri suggerimenti utili comprendono:

     * ci si assicuri che il proprio programma sia sempre
       disponibile nello stesso posto. Spesso questo significa
       rendere accessibile via FTP o via web una singola
       directory in cui possa essere velocemente riconosciuta la
       versione pi recente. Una tecnica efficace  fornire un
       collegamento simbolico chiamato "ilproprioprogetto-latest"
       che punti sempre alla versione pi recente rilasciata, o
       di sviluppo, della propria applicazione. Si ricordi che
       questa locazione ricever molte richieste di download in
       corrispondenza delle date di rilascio, perci ci si
       assicuri che il server scelto abbia una larghezza di banda
       adeguata;
     * ci si assicuri che ci sia un indirizzo di email coerente
       per la segnalazione di bug. Di solito  una buona idea
       scegliere a questo scopo qualcosa che NON sia il proprio
       indirizzo di posta elettronica principale, ad esempio
       ilproprioprogetto@host o ilproprioprogetto-bugs@host. In
       questo modo, se mai si decidesse di passare in consegna la
       manutenzione a qualcun altro, o se il proprio indirizzo di
       posta cambiasse, basterebbe cambiare la destinazione di
       inoltro di questo indirizzo speciale. Questo permette
       anche che sia pi di una persona a gestire il flusso
       entrante di posta che si generer se il progetto diventer
       enorme, come si spera.
     _________________________________________________________

3. Mantenere un progetto: interagire con gli sviluppatori

   Una volta che il progetto  partito, sono stati superati gli
   ostacoli pi insidiosi nel processo di sviluppo del programma.
   Porre delle fondamenta salde  essenziale, ma il processo di
   sviluppo in s  ugualmente importante, e fornisce altrettante
   opportunit di fallimento. Nelle prossime due sezioni verr
   descritta la conduzione di un progetto, discutendo il modo per
   sostenere uno sforzo di sviluppo costante attraverso le
   interazioni con gli sviluppatori e con gli utenti.

   Al rilascio del programma, esso diventa software libero.
   Questa transizione  qualcosa di pi che avere un'utenza pi
   vasta: rilasciando il programma come software libero, il
   proprio software diventa software della comunit del software
   libero. Il corso degli sviluppi futuri sar rimodellato,
   rediretto, e completamente determinato dagli utenti e,
   principalmente, dagli altri sviluppatori della comunit.

   La differenza principale tra lo sviluppo di software libero e
   lo sviluppo di software proprietario  la base degli
   sviluppatori. Come leader di un progetto di software libero,
   sar necessario attrarre e tenersi stretti gli sviluppatori,
   mentre i leader di progetti di software proprietario non
   devono preoccuparsi di queste cose nella stessa misura. Come
   persona che dirige lo sviluppo di un progetto di software
   libero, si dovr controllare il lavoro dei colleghi
   sviluppatori prendendo decisioni responsabili, e scegliendo
   responsabilmente di non prendere decisioni. Gli sviluppatori
   dovranno essere diretti senza essere autoritari o dispotici.
   Si dovr lottare per guadagnarne il rispetto, e averne sempre
   per loro.
     _________________________________________________________

3.1. Delegare il lavoro

   A questo punto, avete ipoteticamente seguito i primi passi
   della programmazione di un software, la creazione di un sito
   web e di un sistema di documentazione, per poi procedere (come
   sar descritto nella Sezione 4.3) al rilascio, a beneficio del
   resto del mondo. Il tempo passa, e se le cose andranno bene la
   gente sar interessata e vorr aiutare. Le patch cominceranno
   ad affluire.

   Come il genitore di un figlio che cresce,  ora tempo di
   reprimere una smorfia di dispiacere, sorridere, e fare la cosa
   pi difficile nella vita di un genitore:  tempo di lasciarlo
   andare via.

   La delega  il modo politico di descrivere questo processo di
   "lasciare andare via":  il processo di affidare parte della
   responsabilit e del potere sul progetto ad altri sviluppatori
   responsabili e coinvolti.  difficile farlo, per chiunque
   abbia investito una grande quantit di tempo ed energie in un
   progetto, ma  essenziale per la crescita di qualsiasi
   progetto di software libero. Una persona da sola pu seguire
   solo una quantit limitata di cose; un progetto di software
   libero  nulla senza il coinvolgimento di un gruppo di
   sviluppatori, che pu essere mantenuto vivo solo attraverso
   una guida rispettosa e responsabile, e attraverso la delega.

   Mentre il progetto procede, si noteranno persone che investono
   quantit significative di tempo e di sforzi nel progetto;
   saranno quelle che inviano pi patch, che pubblicano pi
   messaggi sulle mailing list, e che partecipano a lunghe
   discussioni via email.  responsabilit del manutentore del
   progetto contattare queste persone, e tentare di spostare un
   po' del potere e della responsabilit della posizione di
   manutentore su di loro (se lo vogliono). Ci sono diversi
   semplici modi per farlo.

   Smentendomi un po', delegare non vuol dire necessariamente
   decidere in comitato. In molti casi s, ed  provato che
   funziona; in altri casi ha creato dei problemi. Managing
   Projects the Open Source Way sostiene che "i progetti OSS
   funzionano bene quando una persona  il leader indiscusso di
   un team e prende le decisioni importanti (modifiche di
   progettazione, date di rilascio, e cos via)." Questo spesso 
   vero, ma vorrei spronare gli sviluppatori a prendere in
   considerazione le idee che il leader del progetto non deve
   essere necessariamente il fondatore, e che questi importanti
   poteri non necessariamente devono essere tutti nelle mani di
   una stessa persona: il gestore dei rilasci pu essere diverso
   dal capo sviluppatore. Queste situazioni sono politicamente
   delicate, perci si faccia attenzione e ci si assicuri che sia
   inevitabile, prima di dare pieni poteri alle persone.
     _________________________________________________________

3.1.1. Come delegare

   Si potrebbe scoprire che altri sviluppatori sono pi esperti o
   competenti. Il lavoro come manutentori non significa dover
   essere il migliore o il pi brillante; significa avere la
   responsabilit di mostrare buona capacit di giudizio, e di
   riconoscere quali soluzioni sono mantenibili e quali no.

   Come ogni cosa,  pi facile guardare gli altri delegare che
   farlo in prima persona. In una frase: essere sempre in cerca
   di altri sviluppatori qualificati che mostrino un interesse e
   un coinvolgimento continuato nel proprio progetto, e cercare
   di spostare la responsabilit verso di loro. Le idee seguenti
   potrebbero essere buoni punti di partenza o buone fonti di
   ispirazione.
     _________________________________________________________

3.1.1.1. Concedere ad un gruppo pi ampio di persone il permesso di
scrittura sul proprio repository CVS, e fare uno sforzo effettivo
per promuovere la gestione in comitato

   Apache  un esempio di progetto condotto da un piccolo gruppo
   di sviluppatori, che votano sulle principali problematiche
   tecniche e sull'ammissione di nuovi membri, ed hanno tutti
   accesso in scrittura al repository principale dei sorgenti. Il
   loro processo  descritto nei dettagli online.

   Il Debian Project  un esempio estremo di gestione in
   comitato. Ad un conteggio aggiornato, pi di 700 sviluppatori
   hanno piena responsabilit su qualche aspetto del progetto;
   tutti questi sviluppatori possono caricare file sul server FTP
   principale, e votare sulle problematiche principali. Il corso
   del progetto  determinato dal suo contratto sociale, e da una
   costituzione. Per facilitare questo sistema ci sono dei team
   speciali (ad esempio il team per l'installazione, quello per
   la lingua giapponese), ed anche un comitato tecnico ed un capo
   progetto. La responsabilit principale del capo progetto  di
   "nominare delegati o delegare decisioni al Comitato Tecnico."

   Anche se entrambi questi progetti operano su una scala che il
   proprio progetto non avr (almeno all'inizio), il loro esempio
    utile. L'idea di Debian di un capo progetto che non fa
   niente altro che delegare serve da esempio portato all'estremo
   di come un progetto pu coinvolgere e dar poteri ad un numero
   enorme di sviluppatori, e crescere sino ad una dimensione
   enorme.
     _________________________________________________________

3.1.1.2. Nominare pubblicamente qualcuno come gestore del
rilascioper uno specifico rilascio

   Un gestore del rilascio ha solitamente la responsabilit di
   coordinare il collaudo, imporre un congelamento del codice,
   controllarne la stabilit e la qualit, impacchettare il
   software, e metterlo nei posti appropriati per essere
   scaricato.

   Quest'uso del gestore del rilascio  un buon modo per prendere
   una pausa e spostare su qualcun altro la responsabilit di
   accettare e rifiutare patch.  un buon modo di definire molto
   chiaramente un segmento di lavoro del progetto come
   appartenente ad una certa persona, ed  un ottimo modo di
   concedere a se stessi lo spazio per respirare.
     _________________________________________________________

3.1.1.3. Delegare il controllo di un intero ramo

   Se il proprio progetto sceglie di avere rami (come descritto
   nel la Sezione 3.3), potrebbe essere una buona idea nominare
   qualcun altro responsabile di un ramo. Se si preferisce
   concentrare le proprie energie sui rilasci di sviluppo e
   sull'implementazione di nuove funzionalit, si lasci il
   controllo totale sui rilasci stabili ad uno sviluppatore
   adatto al compito.

   L'autore di Linux, Linus Torvalds, incoron pubblicamente Alan
   Cox come "l'uomo dei kernel stabili": tutte le patch per i
   kernel stabili vanno ad Alan, e se Linus fosse per qualsiasi
   ragione strappato via dal suo lavoro su Linux, Alan Cox
   sarebbe pi che adeguato a prendere il suo posto, in quanto
   erede riconosciuto per la manutenzione di Linux.
     _________________________________________________________

3.2. Accettare e rifiutare patch

   Questo HOWTO ha gi accennato al fatto che come manutentori di
   un progetto di software libero, una delle primarie e pi
   importanti responsabilit sar accettare e rifiutare patch
   inviate da altri sviluppatori.
     _________________________________________________________

3.2.1. Incoraggiare un buon patching

   Come persone che gestiscono o curano la manutenzione del
   progetto non si realizzeranno materialmente molte patch.
   Comunque val la pena di conoscere la sezione di ESR sulle
   Buone pratiche di patching nel Software Release Practices
   HOWTO[ESRHOWTO]. Non sono d'accordo con la sua affermazione
   che le patch bruttissime da vedere o non documentate meritino
   probabilmente di essere gettate via alla prima occhiata:
   semplicemente, questa non  stata la mia esperienza,
   specialmente avendo a che fare con correzioni di bug che
   spesso non sono affatto nella forma di patch. Naturalmente,
   questo non vuol dire che mi piace ricevere patch fatte
   malamente: se si ricevono brutte patch, se si ricevono patch
   senza alcuna documentazione, specialmente se sono qualcosa di
   pi di correzioni di bug banali, potrebbe valer la pena di
   giudicare la patch secondo qualcuno dei criteri spiegati
   nell'HOWTO citato, e poi inviare alla gente il link al
   documento cosicch possano rifarla nel "modo giusto."
     _________________________________________________________

3.2.2. Giudizio tecnico

   In Open Source Development with CVS, Karl Fogel sostiene in
   modo convincente che le cose pi importanti da ricordare
   quando si rifiutano o accettano patch sono:

     * una solida conoscenza dello scopo del programma ( l'
       "idea" di cui si parlava in la Sezione 2.1);
     * la capacit di riconoscere, facilitare, e dare una
       direzione all'"evoluzione" del programma, cosicch esso
       possa crescere e cambiare e incorporare funzionalit che
       non erano state originariamente previste;
     * la necessit di evitare divagazioni che possano espandere
       troppo la portata del programma, divagazioni che
       spingerebbero il progetto verso una morte prematura sotto
       il peso della propria ingestibilit.

   Questi sono i criteri che, come manutentori del progetto, si
   dovrebbero tenere in conto ogni volta che si riceve una patch.

   Fogel approfondisce la questione, ed afferma che "le domande
   da porsi quando si deve decidere se implementare (od
   approvare) un cambiamento sono:"

     * porter benefici ad una percentuale significativa della
       comunit di utenti del programma?
     * si adatta bene al dominio del programma, o ad una
       estensione naturale ed intuitiva di tale dominio?

   Le risposte a queste domande non sono mai semplici, ed 
   sicuramente possibile (e persino probabile) che la persona che
   ha inviato la patch possa avere opinioni diverse dalla propria
   su tali risposte. Tuttavia, se la risposta ad almeno una di
   queste domande  "no,"  proprio dovere rifiutare il
   cambiamento: contrariamente, il progetto diventer ingestibile
   e non mantenibile, e potr alla lunga fallire.
     _________________________________________________________

3.2.3. Rifiutare delle patch

   Rifiutare una patch  probabilmente il lavoro pi difficile e
   delicato che il manutentore di un qualsiasi progetto di
   software libero deve affrontare; ma qualche volta deve essere
   fatto. Come accennato prima (nel la Sezione 3 e nel la Sezione
   3.1), si dovr cercare di bilanciare le proprie responsabilit
   e i propri poteri nel prendere quelle che si pensa siano le
   migliori decisioni tecniche, con il fatto che si potr perdere
   supporto dagli altri sviluppatori sembrando ubriachi di potere
   o troppo autoritari o possessivi verso il progetto, che
   dopotutto appartiene alla comunit. Si consiglia di tenere a
   mente questi tre concetti principali quando si rifiutano delle
   patch (o altri cambiamenti).
     _________________________________________________________

3.2.3.1. Proporlo alla comunit

   Uno dei modi migliori di giustificare una decisione di
   rifiutare una patch, cercando di non far sembrare di mantenere
   una presa ferrea sul proprio progetto,  di non prendere la
   decisione completamente da soli. Potrebbe aver senso
   redirigere le proposte di cambiamenti e le decisioni pi
   difficili verso una mailing list di sviluppo dove possano
   essere discussi e dibattuti. Ci saranno alcune patch
   (correzione di bug, etc.) che saranno sicuramente accettate,
   ed alcune che saranno ritenute cos fuori posto da non
   meritare neanche un'ulteriore discussione: sono quelle che
   rientrano nella zona grigia tra questi due gruppi a poter
   meritare un rapido inoltro ad una mailing list.

   Si consiglia caldamente di seguire questo processo. Come
   manutentore del progetto si avr la preoccupazione di prendere
   la decisione migliore per il progetto, per gli utenti e gli
   sviluppatori del progetto, e per voi stessi come capi progetto
   responsabili: redirigere le cose ad una mailing list
   dimostrer il proprio senso di responsabilit e la propria
   conduzione attenta, poich chiede lumi sugli interessi della
   comunit per poter meglio porsi al suo servizio.
     _________________________________________________________

3.2.3.2. I problemi tecnici non sono sempre una buona
giustificazione

   Specialmente all'inizio della vita del progetto, si scoprir
   che molti cambiamenti sono difficili da implementare,
   introducono nuovi bug, o hanno altri problemi tecnici. Si
   cerchi di vedere oltre: specialmente per le funzionalit
   aggiunte, le buone idee non sempre vengono da buoni
   programmatori. Il valore tecnico  una ragione valida per
   rimandare l'applicazione di una patch, ma non  sempre una
   buona ragione per rifiutare un cambiamento immediatamente.
   Anche i cambiamenti piccoli valgono lo sforzo di lavorare
   insieme allo sviluppatore per risolvere i bug ed incorporare
   il cambiamento, se si pensa che sia una buona aggiunta al
   progetto: questo sforzo contribuir a rendere il proprio
   progetto un progetto della comunit, attirer uno sviluppatore
   nuovo o con meno esperienza nel progetto, ed insegner perfino
   ai suoi membri qualcosa che potrebbe tornare utile nel
   preparare la prossima patch.
     _________________________________________________________

3.2.3.3. Buone maniere

   Dovrebbe essere superfluo dirlo, ma prima di tutto, in ogni
   occasione, essere cortesi. Se qualcuno ha un'idea, e ci tiene
   a sufficienza da scrivere del codice ed inviare una patch,
   significa che ci tiene davvero,  motivato, ed  gi
   coinvolto: il proprio obiettivo come manutentore  assicurarsi
   che ne invii altre. Pu aver fatto cilecca questa volta, ma la
   prossima volta la sua potr essere l'idea o la funzionalit
   che rivoluzioner il progetto.

   Per prima cosa,  proprio dovere giustificare con chiarezza e
   concisione la scelta di non incorporare un cambiamento, e
   ringraziare; far capire che l'aiuto  stato molto apprezzato,
   e che dispiace davvero non poter incorporare i cambiamenti.
   Poi far capire che si desidera che l'autore resti coinvolto, e
   che si spera che la prossima patch o idea si integri meglio
   col progetto, perch il suo lavoro  stato apprezzato e si
   vorrebbe vederlo nella propria applicazione. Se mai  capitato
   di veder rifiutata una propria patch dopo avervi investito una
   grossa quantit di tempo, riflessione, ed energie, si cerchi
   di ricordare come ci si sente: non  piacevole; tenerlo a
   mente quando si dovr deludere qualcuno. Non  mai facile, ma
    necessario fare tutto il possibile per renderlo il meno
   spiacevole possibile.
     _________________________________________________________

3.3. Rami stabili e rami di sviluppo

   L'idea di avere rami stabili e rami di sviluppo  stata gi
   descritta brevemente nel la Sezione 2.4 e nel la Sezione
   3.1.1.3; questi cenni testimoniano alcuni dei modi in cui i
   rami multipli possono influenzare il software. I rami possono
   far evitare (in qualche misura) alcuni dei problemi legati al
   rifiuto delle patch (descritti nel la Sezione 3.2), in quanto
   permettono di compromettere temporaneamente la stabilit del
   progetto senza incidere sugli utenti che hanno bisogno di
   quella stabilit.

   Il modo pi comune di dividere in rami il progetto  avere un
   ramo stabile e uno per lo sviluppo. Questo  il modello
   seguito dal kernel Linux, ed  descritto nel la Sezione 2.4.
   In questo modello, c' sempre un ramo stabile ed un ramo in
   sviluppo. Prima di ogni nuovo rilascio, il ramo di sviluppo
   entra in un "blocco delle funzionalit", come descritto nel la
   Sezione 3.4.1, in cui i cambiamenti principali e le
   funzionalit aggiunte sono rifiutati o messi in attesa fino a
   che il kernel di sviluppo viene rilasciato come nuovo ramo
   stabile, e gli sviluppi principali riprendono sul nuovo ramo
   di sviluppo. Le correzioni di bug e i piccoli cambiamenti che
   presumibilmente non avranno grandi ripercussioni negative,
   vengono incorporati sia nel ramo stabile che nel ramo di
   sviluppo.

   Il modello di Linux fornisce un esempio estremo. In molti
   progetti non c' bisogno di avere costantemente disponibili
   due versioni: pu avere senso avere due versioni solo in
   prossimit di una release. Il progetto Debian ha sempre
   storicamente reso disponibili sia una distribuzione stabile
   che una instabile, ed ha allargato l'insieme sino ad
   includere: versione stabile, instabile, di collaudo,
   sperimentale, e (intorno alla data di rilascio) una
   distribuzione congelata che incorpora solo correzioni di bug
   nella transizione da instabile a stabile. Ci sono pochi
   progetti la cui dimensione avrebbe bisogno di un sistema come
   quello di Debian; tuttavia, questo uso dei rami dimostra come
   essi possano essere usati per far coesistere uno sviluppo
   coerente ed efficace con il bisogno di produrre rilasci
   regolari ed utilizzabili.

   Nel cercare di impostare un albero di sviluppo, pu essere
   utile tenere a mente alcune cose.

   Minimizzare il numero di rami
          Debian pu riuscire a fare buon uso di quattro o cinque
          rami, per contiene dei gigabyte di software, in pi di
          5000 pacchetti, compilati per 5 o 6 diverse
          architetture. Due  probabilmente un buon limite
          superiore. Troppi rami confonderanno i propri utenti
          (non si possono contare le volte che ho dovuto
          descrivere il sistema di Debian, quando ancora aveva
          solo due o certe volte tre rami!), i potenziali
          sviluppatori, ed anche voi stessi. I rami possono
          aiutare, ma hanno un costo, perci vanno usati con
          molta parsimonia.

   Assicurarsi che tutti i diversi rami abbiano una spiegazione
          Come accennato nel paragrafo precedente, rami
          differenti confonderanno gli utenti. Si faccia tutto il
          possibile per evitarlo, spiegando chiaramente i diversi
          rami in una pagina ben visibile sul proprio sito, ed in
          un file README nella directory FTP o web.

          Si potrebbe anche mettere in guardia da un errore che
          Debian potrebbe aver fatto: i termini "instabile," "in
          collaudo," e "sperimentale" sono vaghi, e difficili da
          classificare in ordine di stabilit (o di instabilit,
          secondo le circostanze); si cerchi di spiegare a
          qualcuno che "stabile" significa in realt "ultra
          stabile", e che "instabile" non comprende in realt
          alcun software instabile, ma  in realt software
          stabile non collaudato come distribuzione.

          Se si ha l'intenzione di usare dei rami, specialmente
          nelle prime fasi, si ricordi che le persone sono
          abituate a comprendere i termini "stabile" e "di
          sviluppo", e con questa semplice e comune divisione dei
          rami probabilmente non si sbaglier.

   Assicurarsi che tutti i rami siano sempre disponibili
          Come molte delle cose scritte in questo documento,
          probabilmente non dovrebbe essere necessario dirlo ma
          l'esperienza insegna che non  sempre ovvio per tutti:
           una buona idea separare fisicamente rami diversi in
          directory, o alberi di directory diversi sul proprio
          sito FTP o web. Linux lo realizza mantenendo i kernel
          in sottodirectory v2.2, v2.3, ecc., cos 
          immediatamente ovvio (una volta che si conosce il loro
          schema di numerazione delle versioni) quale directory 
          per il pi recente rilascio stabile, e quale per lo
          sviluppo corrente. Debian lo realizza dando a tutte le
          distribuzioni dei nomi (ad esempio woody, potato, etc.)
          e modificando i collegamenti simbolici chiamati
          "stable," "unstable" e "frozen" per puntare (per nome)
          a quella certa distribuzione che si trova in quel certo
          stato. Entrambi i metodi funzionano, e ce ne sono
          altri: in ogni caso,  importante che i diversi rami
          siano sempre disponibili, siano accessibili da
          posizioni coerenti, e che i diversi rami siano
          chiaramente distinguibili l'uno dall'altro, cosicch
          gli utenti sappiano esattamente cosa vogliono e dove
          trovarlo.
     _________________________________________________________

3.4. Altri problemi nella gestione dei progetti

   In un progetto di software libero possono sorgere altri
   problemi nell'interazione con gli sviluppatori, ma non 
   possibile trattarli in dettaglio in un HOWTO di queste
   dimensioni, e con questi obiettivi. Vi prego di non esitare a
   contattarmi se scoprite delle omissioni importanti.

   Altre pi piccole questioni che vale la pena di menzionare
   sono:
     _________________________________________________________

3.4.1. Congelamento

   Per quei progetti che scelgono di adottare un modello di
   sviluppo suddiviso (la Sezione 3.3), il congelamento  un
   concetto con cui vale la pena di familiarizzare.

   I congelamenti possono avere due forme principali. Un
   "congelamento delle funzionalit"  un periodo in cui al
   programma non vengono aggiunte funzionalit significative. Le
   funzionalit esistenti (anche ossature di funzionalit a
   malapena funzionanti) possono essere migliorate e
   perfezionate, ed  un periodo in cui si correggono i bug.
   Questo tipo di congelamento viene solitamente messo in atto
   qualche tempo (un mese o due) prima di un rilascio:  facile
   rimandare un rilascio in attesa di "ancora una sola
   funzionalit", e un congelamento aiuta ad evitare questa
   situazione, piantando i paletti che servono; d agli
   sviluppatori lo spazio di cui hanno bisogno per rendere un
   programma pronto per il rilascio.

   Il secondo tipo di congelamento  il "congelamento del
   codice", che  molto pi simile al rilascio di un software:
   una volta che un software  entrato in un "congelamento del
   codice", tutti i cambiamenti al codice sono scoraggiati e sono
   consentite solo le modifiche volte a correggere bug noti.
   Questo tipo di congelamento di solito segue un "congelamento
   delle funzionalit", e precede di poco un rilascio. La maggior
   parte del software rilasciato  in quello che potrebbe essere
   interpretato come una sorta di "congelamento del codice" di
   alto livello.

   Anche si sceglie di non nominare mai un gestore dei rilasci
   (la Sezione 3.1.1.2), se  in atto un congelamento dichiarato
   pubblicamente sar pi agevole giustificare il rifiuto o lo
   slittamento di patch (la Sezione 3.2) prima di un rilascio.
     _________________________________________________________

3.5. Forks

   Non ero sicuro sul modo di trattare il forking in questo
   documento (o se dovessi davvero trattarlo). Un "fork" si ha
   quando un gruppo di sviluppatori prende del codice da un
   progetto di software libero e lo usa per iniziare un progetto
   di software libero completamente nuovo. L'esempio pi famoso
   di fork fu quello tra Emacs and XEmacs: i due emacs sono
   basati sulla stessa base di codice, ma per ragioni tecniche,
   politiche e filosofiche lo sviluppo fu spezzato in due
   progetti, che ora sono in competizione.

   La versione breve della sezione sul fork : non lo si faccia.
   I fork costringono gli sviluppatori a scegliere di lavorare
   con uno solo dei due progetti, causando divisioni politiche
   molto spiacevoli, e lavoro ridondante. Fortunatamente, di
   solito la sola minaccia di un fork  sufficiente a spaventare
   il manutentore o i manutentori del progetto, al punto di
   convincerli a correggere il loro modo di condurlo.

   Nel suo capitolo su "The Open Source Process", Karl Fogel
   descrive il modo migliore di fare un fork, se proprio 
   necessario; se si  stabilito che  assolutamente necessario,
   e che le divergenze con le persone che minacciano il fork sono
   assolutamente senza soluzione, il libro di Fogel sar buon
   punto di partenza.
     _________________________________________________________

4. Mantenere un progetto: interagire con gli utenti

   Se avete seguito fino a qui, congratulazioni: ci si sta
   avvicinando alla fine di questo documento. Questa ultima
   sezione descrive alcune delle situazioni in cui, nella propria
   veste di manutentori del progetto, si interagisce con gli
   utenti, e fornisce alcuni suggerimenti su come queste
   situazioni possano essere gestite efficacemente.

   Interagire con gli utenti  difficile. Nella discussione
   dell'interazione con gli sviluppatori, l'assunto di partenza 
   che in un progetto di software libero un manutentore del
   progetto debba costantemente adoperarsi per attrarre e
   conservarsi gli sviluppatori, che possono andarsene con
   facilit in qualsiasi momento.

   Gli utenti della comunit del software libero sono diversi
   dagli sviluppatori, e sono anche diversi dagli utenti del
   mondo del software proprietario, quindi dovrebbero essere
   trattati diversamente da ciascuno di questi due gruppi.
   Seguono alcuni dei punti in cui i gruppi differiscono
   significativamente:

     * le linee di demarcazione tra utenti e sviluppatori si
       confondono in modo totalmente estraneo a qualsiasi modello
       di sviluppo proprietario: i propri utenti sono spesso i
       propri sviluppatori, e viceversa;
     * nel mondo del software libero, spesso si sar l'unica
       scelta per i propri utenti. Poich nel mondo del software
       libero c' cos tanta enfasi sul non replicare il lavoro
       degli altri, e poich l'elemento della competizione,
       presente nel modello del software proprietario,  assente
       (o almeno  presente in una forma estremamente diversa)
       nel modello di sviluppo del software libero, probabilmente
       il proprio sar il solo progetto che fa quello che fa, nel
       modo in cui lo fa. Questo vuol dire che la propria
       ricettivit nei confronti degli utenti  ancora pi
       importante che nel mondo del software proprietario;
     * in modo quasi paradossale, i progetti di software libero
       soffrono conseguenze meno immediate o terribili
       dall'ignorare del tutto i propri utenti. Spesso  anche la
       cosa pi facile da fare: poich non si deve competere con
       un altro prodotto, ci sono buone possibilit che non ci si
       dovr affrettare a raggiungere le funzionalit dell'ultimo
       prodotto della concorrenza. Questo vuol dire che il
       processo di sviluppo dovr essere guidato o da una forte
       automotivazione, o da un obbligo morale verso i propri
       utenti, o da entrambi.

   Si pu cercare di affrontare questa situazione, unica nel suo
   genere, solo indirettamente: gli sviluppatori e i manutentori
   devono necessariamente dare ascolto agli utenti, ed essere
   quanto pi ricettivi possibile. Una solida conoscenza della
   situazione descritta sopra  lo strumento migliore a
   disposizione di uno sviluppatore di software libero per
   correggere il suo stile di sviluppo o di conduzione del
   progetto per meglio adattarsi a questo singolare processo.
   Questi capitoli cercheranno di introdurre alcuni dei punti pi
   difficili o importanti nelle interazioni di un progetto con
   gli utenti, e forniranno alcuni consigli su come affrontare
   tali interazioni.
     _________________________________________________________

4.1. Collaudo e collaudatori

   Gli utenti, oltre che essere sviluppatori, sono anche (e forse
   pi frequentemente) collaudatori. Prima di diventare il
   bersaglio di invettive, riformulo la frase: alcuni utenti
   (quelli che si prestano esplicitamente come volontari) sono
   anche collaudatori.

    importante che questa distinzione sia fatta al pi presto,
   perch non tutti gli utenti vogliono diventare collaudatori:
   molti utenti vogliono usare software stabile, e non gli
   interessa avere l'ultimo, bellissimo software, con le ultime,
   bellissime funzionalit. Questi utenti si aspettano un
   software stabile, collaudato, senza bug importanti o evidenti,
   e si arrabbieranno se si ritroveranno a fare da collaudatori.
   Questo  un'altro modo ancora in cui un modello di sviluppo
   separato (citato nel la Sezione 3.3) pu tornare utile.

   "Managing Projects the Open Source Way" descrive ci di cui un
   buon collaudo dovrebbe andare in cerca.

   Condizioni limite
          Lunghezze massime dei buffer, conversione dati, limiti
          superiori/inferiori, e cos via.

   Comportamento inappropriato
           una buona idea scoprire cosa far un programma se un
          utente gli fornisce un valore che non si aspetta, preme
          il pulsante sbagliato, ecc. Porsi un sacco di domande
          del tipo "cosa succederebbe se"; pensare a qualsiasi
          cosa che potrebbe fallire o potrebbe andare storto, e
          scoprire cosa il programma fa in quei casi.

   Fallimenti gradevoli
          La risposta a molti dei "cosa succederebbe se" di cui
          sopra  probabilmente "un fallimento", che spesso  la
          sola risposta possibile. Ora, ci si assicuri che
          avvenga gradevolmente, e che quando il programma si
          arresta dia qualche indicazione del perch si 
          arrestato o ha dato un malfunzionamento, cosicch
          l'utente o il programmatore capiscano cosa sta
          succedendo.

   Conformit agli standard
          Se possibile, ci si assicuri che i propri programmi
          siano conformi agli standard. Se il programma 
          interattivo, non essere troppo creativi con le
          interfacce: se non  interattivo, assicurarsi che
          comunichi con altri programmi, e con il resto del
          sistema, attraverso canali appropriati e comunemente
          riconosciuti.
     _________________________________________________________

4.1.1. Collaudo automatizzato

   Per molti programmi, molti errori comuni possono essere
   individuati con mezzi automatici. I test automatizzati sono
   solitamente abbastanza efficaci nell'individuare errori in cui
   si  incappati spesso in passato, o semplici dimenticanze; non
   sono molto efficaci nel trovare errori, anche importanti, che
   siano completamente imprevisti.

   CVS  fornito di uno script per la shell Bourne chiamato
   sanity.sh, che vale la pena di guardare; Debian usa un
   programma, lintian, che controlla i pacchetti Debian in cerca
   di tutti gli errori pi comuni. Anche se l'uso di questi
   script pu non essere di aiuto, c' un gran numero di altri
   software per il controllo dell'integrit sulla rete che pu
   fare al proprio caso (ci si senta liberi di inviarmi delle
   segnalazioni); nessuno di essi produrr un rilascio privo di
   bug, ma eviteranno almeno alcune sviste importanti. Infine, se
   i propri programmi diventano uno sforzo a lungo termine, si
   scoprir che ci sono certi errori che si tende a ripetere: si
   dia inizio ad una raccolta di script che individuano questi
   errori, per contribuire a tenerli fuori dai rilasci futuri.
     _________________________________________________________

4.1.2. Collaudo eseguito da collaudatori

   Per tutti i programmi che si basano sull'interattivit con
   l'utente, molti bug saranno scoperti solo attraverso il
   collaudo eseguito da utenti, che premono veramente i tasti e i
   pulsanti del mouse. Per questo avete bisogno di collaudatori:
   il maggior numero possibile di collaudatori.

   La parte pi difficile del collaudo  trovare i collaudatori;
    solitamente una buona tattica pubblicare su una mailing list
   o un newsgroup pertinente un messaggio che annuncia una
   determinata data di rilascio prevista, e descrive a grandi
   linee le funzionalit del programma: se si dedica un po' di
   tempo alla stesura dell'annuncio, si avr la certezza di
   ricevere qualche risposta.

   La seconda parte pi difficile del collaudo  mantenere i
   collaudatori, e mantenerli attivamente coinvolti nel processo
   di collaudo. Fortunatamente, ci sono alcune tattiche
   sperimentate che si possono applicare a questo scopo.

   Rendere le cose facili ai collaudatori
          I collaudatori stanno facendo un favore, perci si
          renda loro la vita quanto pi facile possibile. Questo
          significa che si dovrebbe avere cura di impacchettare
          il proprio programma in modo che sia facile da trovare,
          estrarre, installare, e disinstallare; significa anche
          che si dovrebbe spiegare ad ogni collaudatore che cosa
          si sta cercando, e rendere il modo per segnalare i bug
          semplice e certo. La chiave  fornire una struttura il
          pi definita possibile, per rendere il lavoro dei
          collaudatori facile, ma di conservare quanta pi
          flessibilit possibile, per quelli che vogliono fare le
          cose in modo un po' diverso.

   Essere reattivi verso i collaudatori
          Quando i collaudatori inviano delle segnalazioni di bug
          gli si risponda, e in fretta: anche se si risponde solo
          per dire che il bug  gi stato corretto, risposte
          veloci e coerenti danno la sensazione che il loro
          lavoro sia ascoltato, importante, ed apprezzato.

   Ringraziare i propri collaudatori
          Ringraziare personalmente i collaudatori ogni volta che
          mandano una patch. Ringraziarli pubblicamente nella
          documentazione, e nella sezione "about" del proprio
          programma. Essere grati ai propri collaudatori, il
          proprio programma non sarebbe possibile senza il loro
          aiuto: assicurarsi che lo sappiano. Si dia loro una
          pacca sulla spalla pubblicamente, per essere sicuri che
          il resto del mondo lo sappia: sar apprezzato pi di
          quanto si possa immaginare.
     _________________________________________________________

4.2. Impostare un'infrastruttura di supporto

   Anche se il collaudo  importante, la gran parte delle
   interazioni e responsabilit verso gli utenti ricade nella
   categoria del supporto. Il modo migliore di essere certi che
   gli utenti siano adeguatamente supportati nell'uso del
   programma  impostare una buona infrastruttura a questo scopo,
   cosicch gli sviluppatori e gli utenti si aiutino a vicenda, e
   su di voi ricada un peso pi leggero; in questo modo, la gente
   otterr anche risposte migliori e pi tempestive alle proprie
   domande. Questa infrastruttura pu avere diverse forme
   principali.
     _________________________________________________________

4.2.1. Documentazione

   Non dovrebbe sorprendere che il punto chiave per ogni
   infrastruttura di supporto sia una buona documentazione.
   Questo argomento  stato ampiamente trattato nel la Sezione
   2.5, e non sar ripetuto qui.
     _________________________________________________________

4.2.2. Mailing list

   A parte la documentazione, mailing list efficaci sono lo
   strumento pi importante per fornire supporto agli utenti.
   Portare avanti una mailing list nel modo giusto  qualcosa di
   pi complicato che semplicemente installare su una macchina un
   software che gestisca mailing list.
     _________________________________________________________

4.2.2.1. Liste separate

   Una buona idea  separare le mailing list per gli utenti e per
   gli sviluppatori (magari project-user@host e
   project-devel@host), e far rispettare la divisione: se la
   gente pubblica una domanda di sviluppo su -user, si chieda
   gentilmente di ripubblicarla su -devel, e viceversa. Si
   sottoscrivano entrambi i gruppi, e si incoraggino tutti gli
   sviluppatori principali a fare lo stesso.

   Questo sistema fa s che nessuno resti bloccato a fare tutto
   il lavoro di supporto, e fa s che gli utenti ne sappiano di
   pi sul programma, in modo da poter aiutare i nuovi utenti
   rispondendo alle loro domande.
     _________________________________________________________

4.2.2.2. Scegliete bene il software per le mailing list

   Il software per le mailing list non dovrebbe essere scelto
   d'impulso: si cerchi la maggior semplicit possibile, pensando
   ad una facile accessibilit per utenti senza molta esperienza
   tecnica. Anche l'accessibilit via web agli archivi della
   lista  importante.

   I due principali programmi di software libero per la gestione
   di mailing list sono majordomo e GNU Mailman. Dopo essere
   stato per lungo tempo un sostenitore di majordomo, ora
   consiglierei ad ogni progetto di usare GNU Mailman.
   Quest'ultimo rispetta i criteri sopra elencati e la fa pi
   semplice: fornisce un buon programma di gestione di mailing
   list ad un manutentore di un progetto di software libero,
   piuttosto che una buona applicazione di gestione di mailing
   list ad un amministratore di mailing list.

   Ci sono altre cose da tenere in considerazione nel mettere in
   piedi una mailing list: se fosse possibile collegare le
   mailing list a Usenet, e fornirle sia sotto forma di digest
   che renderle disponibili sul web, si far piacere ad alcuni
   utenti, e l'infrastruttura di supporto sar un po' pi
   accessibile.
     _________________________________________________________

4.2.3. Altre idee di supporto

   Una mailing list e della documentazione accessibile non
   esauriscono quello che si pu fare per mettere in piedi una
   buona infrastruttura di supporto agli utenti: siate creativi.
   Se inciampate in qualcosa che funziona bene, mandatemi una
   email e lo includer qui.
     _________________________________________________________

4.2.3.1. Rendetevi accessibili

   Non sono mai troppi i mezzi per farsi contattare: se si
   frequenta spesso un canale IRC, non si esiti ad elencarlo
   nella documentazione di progetto; riportare gli indirizzi di
   posta elettronica ed ordinaria, e i modi per essere raggiunti
   via ICQ, AIM, o Jabber, se pertinenti.
     _________________________________________________________

4.2.3.2. Software di gestione dei bug

   Per molti grandi progetti software, l'uso di software di
   gestione dei bug  essenziale per tenere traccia di quali
   errori sono stati corretti, quali non sono stati corretti, e
   quali sono in corso di correzione, e da parte di chi. Debian
   usa il Debian Bug Tracking System (BTS), anche se pu non
   essere la scelta migliore per ogni progetto (sembra che
   attualmente si stia piegando sotto il suo stesso peso). Oltre
   ad un browser web davvero buono, il progetto Mozilla ha
   generato un sotto-progetto che ha avuto come conseguenza la
   nascita di un sistema di tracciamento dei bug chiamato
   bugzilla, che  diventato estremamente affidabile, e che mi
   piace molto.

   Questi sistemi (ed altri simili) possono essere poco
   maneggevoli, perci gli sviluppatori dovrebbero fare
   attenzione a non passare pi tempo sul sistema di tracciamento
   dei bug che sui bug, o sui progetti, stessi. Se un progetto
   continua a crescere, l'uso di un sistema di tracciamento pu
   fornire una semplice via standard per utenti e collaudatori
   per segnalare bug, e per sviluppatori e manutentori per
   correggerli, e per tenerne traccia in modo ordinato.
     _________________________________________________________

4.3. Rilasciare il programma

   Come accennato in precedenza, la prima regola dei rilasci :
   rilasciare qualcosa di utile. Un software che non funziona, o
   non  utile, non attrarr nessuno verso il proprio progetto;
   la gente se ne allontaner, e probabilmente la prossima volta
   che vedr annunciare una nuova versione tirer diritto senza
   fermarsi. Un software che funziona a met, se  utile,
   incuriosir la gente, dester il loro appetito per le prossime
   versioni, e li incoragger a partecipare al processo di
   sviluppo.
     _________________________________________________________

4.3.1. Quando rilasciare

   Prendere la decisione di rilasciare il software per la prima
   volta  incredibilmente importante, e incredibilmente
   stressante; ma bisogna farlo. Si cerchi di fare qualcosa che
   sia abbastanza completo da essere usabile, ed abbastanza
   incompleto da lasciare una certa flessibilit ed un certo
   spazio per l'immaginazione dei futuri sviluppatori. Non  una
   decisione facile; si chieda aiuto alla mailing list di un
   Linux User Group locale, o ad un gruppo di amici sviluppatori.

   Una tattica  produrre prima un rilascio "alpha" o "beta",
   come descritto sotto nel la Sezione 4.3.3. In ogni caso, la
   maggior parte delle linee guida descritte sopra si applicano
   ancora.

   Quando si sente istintivamente che  il momento giusto, e si
   ritiene di avere ben soppesato la situazione diverse volte, si
   incrocino le dita, e si salti il fosso.

   Dopo aver rilasciato per la prima volta, decidere quando
   rilasciare diventa meno stressante, ma altrettanto difficile
   da giudicare. Mi piacciono i criteri per mantenere un buon
   ciclo di rilasci che fornisce Robert Krawitz nel suo articolo
   "Free Software Project Management". Consiglia di chiedersi:
   "questo rilascio..."

     * contiene un numero di nuove funzionalit o di correzioni
       di bug sufficiente a giustificare lo sforzo?
     *  abbastanza lontano dal precedente da lasciare all'utente
       il tempo di lavorarci?
     * funziona sufficientemente bene da consentire all'utente di
       portare a termine il proprio lavoro (qualit)?

   Se la risposta a queste tre domande  s, probabilmente 
   tempo per un rilascio. Se in dubbio, si ricordi che chiedere
   un consiglio non guasta.
     _________________________________________________________

4.3.2. Come rilasciare

   Se si sono seguite le linee guida descritte in questo HOWTO
   fino a questo punto, la tecnica per produrre un rilascio sar
   la parte facile della cosa: se sono state predisposte
   ubicazioni coerenti per la distribuzione, e il resto
   dell'infrastruttura descritta nelle sezioni precedenti, per
   rilasciare basta costruire il pacchetto, controllarlo quando 
   finito, caricarlo nel posto appropriato e poi far s che il
   sito web registri l'aggiornamento.
     _________________________________________________________

4.3.3. Rilasci alpha, beta, e di sviluppo

   Quando si progettano dei rilasci, vale la pena di considerare
   il fatto che non tutti i rilasci devono per forza essere dei
   rilasci completamente numerati, gli utilizzatori di software
   sono abituati ai pre-rilasci. Tuttavia, si dovr fare
   attenzione ad etichettare questi rilasci accuratamente,
   altrimenti causeranno pi problemi di quanto necessario.

   Si osserva spesso che molti sviluppatori di software libero
   sembrano avere le idee confuse sul ciclo di rilascio.
   "Managing Projects the Open Source Way" suggerisce di
   memorizzare la frase: "Una Alpha non  una Beta. Una Beta non
    un Rilascio"; penso anch'io che sia una buona idea.

   Rilasci alpha
          Il software in alpha ha funzionalit complete, ma
          talvolta solo parzialmente funzionanti.

          Ci si aspetta che i rilasci alpha siano instabili,
          forse un po' insicuri, ma certamente utilizzabili;
          possono avere bug noti e ghiribizzi che devono ancora
          essere risolti. Prima di rilasciare un'alpha, si
          ricordi che i rilasci alpha sono comunque rilasci, la
          gente non si aspetta nightly build dei sorgenti su CVS:
          un'alpha dovrebbe funzionare, ed aver passato ad un
          minimo di collaudo e correzione di bug.

   Rilasci beta
          Il software in beta ha funzionalit complete ed 
          operativo, ma  sotto collaudo, e contiene qualche bug
          ancora da risolvere.

          Ci si aspetta in genere che i rilasci Beta siano
          utilizzabili e leggermente instabili, anche se
          sicuramente non insicuri. I rilasci beta di solito non
          ammettono un rilascio completo a meno di un mese di
          distanza; possono contenere piccoli bug noti, ma
          nessuno importante. Tutte le funzionalit principali
          dovrebbero essere completamente implementate, anche se
          sui dettagli precisi ci pu ancora essere del lavoro da
          fare. I rilasci beta sono un ottimo strumento per
          aguzzare l'appetito dei potenziali utenti fornendo loro
          una visione molto realistica di dove il progetto andr
          in un prossimo futuro, e pu contribuire a mantenere
          vivo l'interesse, fornendo alla gente qualcosa.

   Rilasci di sviluppo
          "Rilascio di sviluppo"  un termine molto pi vago di
          "alpha" o "beta". Di solito scelgo di riservare questa
          espressione per la discussione di un ramo di sviluppo,
          anche se ci sono altri modi di usarla. Cos tanti modi,
          in realt, che secondo me questa espressione  troppo
          inflazionata: il popolare gestore di finestre
          Enlightenment non ha rilasciato niente altro che
          rilasci di sviluppo. Molto spesso si usa questo termine
          per descrivere rilasci che non sono ancora neanche
          alpha o beta; se dovessi rilasciare una versione
          pre-alpha di un pacchetto software per mantenere vivo
          l'interesse per un mio progetto, probabilmente la
          etichetterei cos.
     _________________________________________________________

4.4. Annunciare il progetto

   Bene,  fatta. Il proprio progetto di software libero  stato
   (almeno per gli scopi di questo HOWTO) progettato, costruito,
   e rilasciato. Tutto ci che rimane da fare  dirlo al mondo,
   cosicch vengano a provarlo e, si spera, saltino a bordo per
   lo sviluppo. Se ogni cosa  in ordine come descritto sopra,
   questo sar un processo rapido e indolore: baster un
   tempestivo annuncio per mettersi sullo schermo radar della
   comunit del software libero.
     _________________________________________________________

4.4.1. Mailing list e Usenet

   Annunciare il proprio software sul gruppo Usenet
   comp.os.linux.announce. Se si vuole mettere l'annuncio solo in
   due posti, scegliere c.o.l.a e freshmeat.

   In ogni caso, la posta elettronica  ancora il modo in cui su
   Internet la maggior parte della gente riceve informazioni: 
   una buona idea mandare un messaggio che annuncia il programma
   ad ogni mailing list pertinente che si conosce, e ad ogni
   altro gruppo di discussione Usenet pertinente.

   Karl Fogel raccomanda di inserire nel campo oggetto una
   semplice descrizione del fatto che il messaggio  un annuncio,
   il nome del programma, la versione, ed una descrizione della
   sua funzionalit lunga mezza riga. In questo modo, un
   eventuale utente o sviluppatore interessato sar
   immediatamente attratto dall'annuncio. L'esempio di Fogel
   assomiglia a:
Oggetto: ANN: aub 1.0, un programma per assemblare file binari Usenet

   Il resto della mail dovrebbe descrivere rapidamente e
   concisamente la funzionalit del programma, in non pi di due
   paragrafi, e dovrebbe fornire collegamenti alla pagina web del
   progetto, e collegamenti diretti ai download per quelli che
   vogliono provarlo subito; questo formato funzioner sia per la
   pubblicazione su Usenet che su mailing list.

   Si dovranno ripetere questi annunci costantemente, negli
   stessi posti, per ogni rilascio successivo.
     _________________________________________________________

4.4.2. freshmeat.net

   Citato in precedenza nel la Sezione 2.1.2.1. Nell'odierna
   comunit del software libero, annunciare il progetto su
   freshmeat  quasi pi importante che annunciarlo sulle mailing
   list.

   Si visiti il sito web freshmeat.net o la loro pagina di
   inserimento dei progetti per pubblicare il proprio progetto
   sul loro sito e nella loro base dati: oltre ad un grande sito
   web, freshmeat fornisce una newsletter quotidiana che
   evidenzia tutti i rilasci del giorno, e raggiunge un pubblico
   enorme (personalmente la scorro ogni giorno in cerca di nuovi
   rilasci interessanti).
     _________________________________________________________

4.4.3. Mailing List di progetto

   Se sono state create delle mailing list per il proprio
   progetto, le nuove versioni dovrebbero sempre essere
   annunciate su queste liste. Ho notato che per molti progetti
   gli utenti richiedono una mailing list di soli annunci, a
   bassissimo traffico, per essere avvisati quando vengono
   rilasciate nuove versioni; freshmeat.net ora consente agli
   utenti di sottoscrivere un particolare progetto, in modo da
   ricevere mail ogni volta che viene annunciata una nuova
   versione attraverso il loro sistema:  gratuito, e pu
   sostituire una mailing list di soli annunci. Secondo me, male
   non fa.
     _________________________________________________________

Bibliografia

Libri cartacei

   Karl Fogel, Open Source Development with CVS, Coriolis Open
   Press, 1999, 1-57610-490-7.

   La "Open Source Development with CVS" di Fogel  molto di pi
   del suo sottotitolo. Per usare le parole dell'editore: "Open
   Source Development with CVS  uno dei primi libri disponibili
   che insegna lo sviluppo e l'implementazione di software Open
   Source". Include anche il miglior manuale introduttivo e testo
   di riferimento per CVS che abbia mai visto. Il libro era cos
   ben fatto che mi ha spinto a scrivere questo HOWTO, perch il
   ruolo che esso cercava di esercitare mi era parso cos
   importante e utile. Gli si dia un'occhiata, o lo si compri se
   possibile, se seriamente interessati a condurre un progetto di
   software libero.

   Lawrence Lessig, Code and Other Laws of Cyberspace, Basic
   Books, 2000, 0-465-03913-8.

   Anche se tratta solo brevemente il software libero (e lo fa
   camminando in punta di piedi intorno alla questione software
   libero/open source, con l'uso della flaccida espressione
   "codice aperto", che solo un avvocato potrebbe coniare), il
   libro di Lessig  notevole. Scritto da un avvocato, parla di
   come la regolamentazione su Internet non sia esercitata con le
   leggi, ma con il codice stesso, e di come la natura del codice
   determiner la natura delle libert future. Oltre ad essere
   una lettura veloce e godibile, racconta un po' di storie
   carine, e spiega quanto c'e' bisogno di software libero, con
   molta pi intensit di qualsiasi cosa abbia letto, a parte
   "Right to Read" di RMS.

   Eric Raymond, The Cathedral and the Bazaar: Musings on Linux
   and Open Source by an Accidental Revolutionary, O'Reilly,
   1999, 1-56592-724-9.

   Anche se devo dire per onest che non sono pi quel fan di ESR
   che ero in passato, questo libro si  dimostrato
   insostituibile nel portarmi dove sono oggi. Il saggio che d
   il titolo al libro fa un buon lavoro nel tratteggiare il
   processo del software libero, e fa un lavoro sbalorditivo
   nell'argomentare a favore dello sviluppo di software
   libero/open source come direzione da prendere per avere del
   software migliore. Il resto del libro contiene altri articoli
   di ESR, articoli che per la maggior parte sono pubblicati sul
   suo sito: eppure,  una bella cosa da possedere in versione
   cartacea, ed  una cosa che ogni appassionato di software
   libero/open source dovrebbe leggere.
     _________________________________________________________

Risorse accessibili via web

   George N Dafermos, Management and Virtual Decentralized
   Networks: The Linux Project.

   Poich l'articolo ha un suo riassunto iniziale, ho pensato di
   inserirlo qui parola per parola:

     Questo articolo esamina il pi recente dei paradigmi -
     l'Organizzazione a rete virtuale - e si chiede se
     lavoratori della conoscenza dispersi geograficamente
     possano collaborare per un progetto senza alcuna
     pianificazione centralizzata. La coordinazione, la gestione
     ed il ruolo della conoscenza emergono come le aree centrali
     di interesse. Sono stati scelti come caso di analisi il
     Linux Project e il suo modello di sviluppo, e sono stati
     identificati i fattori critici di successo per questa
     struttura organizzativa. Lo studio prosegue con la
     formulazione di una struttura di massima che pu essere
     applicata a tutti i tipi di lavoro decentrato virtuale, e
     trae la conclusione che la creazione di valore viene
     massimizzata quando c' intensa interazione, e condivisione
     di informazioni senza inibizioni, tra l'organizzazione e la
     comunit che la circonda. Perci, il potenziale successo o
     fallimento di questo paradigma organizzativo dipende dal
     grado di dedizione e coinvolgimento della comunit
     circostante.

   Questo articolo  stato segnalato a me in quanto autore di
   questo HOWTO, e ne sono rimasto molto impressionato.  stato
   scritto da uno studente specializzando in management, e penso
   che l'articolo abbia centrato il bersaglio nel valutare il
   progetto Linux come esempio di un nuovo paradigma di gestione,
   un paradigma in cui vi porrete al centro, nel vostro ruolo di
   manutentori di un progetto di software libero.

   Come sviluppatore che cerca di controllare un'applicazione, e
   di condurla al successo nel mondo del software libero, non
   sono sicuro di quanto sia utile la discussione di Dafermos,
   tuttavia fornisce sicuramente una giustificazione teorica al
   mio HOWTO: la gestione di progetti di software libero  un
   animale diverso dalla gestione di progetti di software
   proprietario. Se si  interessati alle modalit concettuali e
   teoriche in cui la gestione di progetti di software libero
   differisce da altri tipi di gestione, questo  un ottimo
   articolo da leggere. Se questo HOWTO risponde a dei "come?",
   Dafermos risponde a dei "perch?" (ben pi difficili da
   sostenere), e fa davvero un buon lavoro.

   Richard Gabriel, The Rise of "Worse is Better".

   Un articolo ben scritto, anche se penso che il titolo abbia
   confuso tanta gente, quanta il resto del saggio ne abbia
   aiutata. Offre una buona spiegazione di come progettare
   programmi che avranno successo, e che si conserveranno
   mantenibili crescendo.

   Montey Manley, Managing Projects the Open Source Way, Linux
   Programming, 31 ottobre 2000.

   In uno dei migliori articoli sull'argomento che abbia letto,
   Monty ricapitola alcuni dei punti principali cui ho accennato,
   compresi: avvio di un progetto, collaudo, documentazione,
   organizzazione e leadership di un team, e diversi altri
   argomenti. Per quanto l'articolo sia pi dogmatico di quanto
   io cerchi di essere, penso sia un articolo importante, e l'ho
   trovato molto utile nello scrivere il presente HOWTO; in tutti
   i punti in cui ho attinto qualcosa da questo articolo, ho
   cercato di citarlo.

   Ho molti problemi in sospeso con questo pezzo; per avere un
   buon punto di vista critico si consiglia di leggerlo [KRAWITZ]
   contemporaneamente all'articolo di Monty.

   Eric Steven Raymond, Software Release Practice HOWTO.

   Ad una prima occhiata, l'HOWTO delle pratiche di rilascio
   scritto da ESR sembra avere molto in comune con questo
   documento; ad un esame pi dettagliato, le differenze
   diventano evidenti, anche se i due restano strettamente
   imparentati. Il suo documento, letto in congiunzione con
   questo, dar al lettore un buon quadro di come lavorare alla
   gestione di un progetto. L'HOWTO di ESR entra un po' pi nei
   dettagli su come scrivere, e in quali linguaggi scrivere, e
   tende a dare istruzioni e liste di controllo pi specifiche
   ("chiamate questo file cos, non cos"), mentre il presente
   HOWTO tratta le cose in modo pi astratto. Ci sono diverse
   sezioni molto simili. Questo HOWTO  anche molto pi breve.

   La mia citazione preferita dal suo HOWTO : ""Gestire un
   progetto bene, quando tutti i partecipanti sono volontari,
   presenta alcune sfide molto particolari. Questo  un argomento
   troppo vasto per essere trattato in un HOWTO." Ah, davvero?
   Forse sto solo facendo un lavoro scadente.

   Vivek Venugopalan, CVS Best Practices.

   Venugopalan fornisce uno dei migliori saggi sull'uso efficace
   di CVS in cui mi sono imbattuto.  scritto per gente che abbia
   gi una buona conoscenza di CVS. Nel capitolo sui rami
   descrive quando e come creare dei rami, ma non d informazioni
   su quali comandi CVS bisogna usare per farlo. Questo va bene
   (sono stati scritti altri HOWTO su CVS, pi tecnici), ma i
   novellini di CVS dovranno passare del tempo sul manuale di
   riferimento di Fogel, prima di poter trovare questo di qualche
   utilit.

   Venugopalan produce liste di controllo di cose da fare prima,
   dopo, e in prossimit dei rilasci. Vale sicuramente una
   lettura, poich molte delle sue idee risparmieranno un sacco
   di mal di testa agli sviluppatori, per un lungo periodo di
   tempo.
     _________________________________________________________

Articoli su Advogato

   Stephen Hindle, 'Best Practices' for Open Source?, Advogato,
   21 marzo 2001.

   Riferendosi principalmente alla pratica della programmazione
   (come fanno di solito la maggior parte degli articoli sull'
   argomento), l'articolo parla un po' della gestione dei
   progetti ("Usatela!"), e un pochino della comunicazione
   all'interno di un progetto di software libero.

   Bram Cohen, http://www.advogato.org/article/258.htmlHow to
   Write Maintainable Code, Advogato, 15 marzo 2001.

   Questo articolo accenna a quel dibattito sulla "scrittura di
   codice mantenibile" che ho cercato con ogni mezzo di evitare
   nel mio HOWTO.  uno dei migliori (e pi diplomatici) articoli
   sull'argomento che abbia trovato.

   Robert Krawitz, Free Source Project Management, Advogato, 4
   novembre 2000.

   Questo articolo mi ha reso felice, perch ha affrontato molti
   dei problemi che avevo riguardo l'articolo di Monty su
   LinuxProgramming. L'autore sostiene che Monty suggerisce
   semplicemente l'applicazione di tecniche di gestione dei
   progetti antiquate, per software proprietario, invece di
   cercare di elaborare qualcosa di nuovo. Ho trovato questo
   articolo estremamente ben meditato, e lo ritengo una lettura
   essenziale per ogni gestore di progetti di software libero.

   Lalo Martins, Ask the Advogatos: why do Free Software projects
   fail?, Advogato, 20 luglio 2000.

   Anche se l'articolo  poco pi di una domanda, leggere le
   risposte a questa domanda fornite dai lettori di Advogato pu
   essere d'aiuto. In molti modi, questo HOWTO costituisce la mia
   risposta alla domanda posta nell'articolo, ma ci sono altre
   risposte possibili, molte delle quali possono mettere in
   discussione quello che  scritto in questo HOWTO: vale la pena
   di dare un'occhiata.

   David Burley, In-Roads to Free Software Development, Advogato,
   14 giugno 2000.

   Questo documento  stato scritto come risposta a un'altro
   articolo su Advogato. Anche se non riguarda la conduzione di
   un progetto, descrive alcuni modi per iniziare con lo sviluppo
   di software libero senza iniziare un progetto. Penso sia un
   articolo importante. Se si  interessati ad impegnarsi nel
   software libero, questo articolo dimostra alcuni dei modi in
   cui si pu farlo senza iniziare veramente un progetto (cosa
   che, come spero questo HOWTO abbia mostrato, non va presa alla
   leggera).

   Jacob Moorman, Importance of Non-Developer Supporters in Free
   Software, , Advogato, 16 aprile 2000.

   Questo di Moorman  un articolo breve, ma apporta alcuni
   contributi utili. Il commento che ricorda agli sviluppatori di
   ringraziare i loro collaudatori ed utenti finali 
   preziosissimo, e spesso dimenticato.

   Leslie Orchard, On Naming an Open Source Project, Advogato, 12
   aprile 2000.

   Non avevo nemmeno una sezione, in questo HOWTO, su come
   scegliere il nome da dare al progetto, fino a che l'articolo
   di Leslie Orchard me lo ha ricordato: grazie a Leslie per aver
   scritto questo articolo!

   David Allen, Version Numbering Madness, Advogato, 28 febbraio
   2000.

   In questo articolo, David Allen affronta lo schema di
   numerazione delle versioni "Major.Minor.Patch" nella sua
   interezza;  bene leggerlo mentre si legge la Sezione 2.4.
   L'articolo mi  piaciuto, e inoltre descrive alcuni dei
   progetti che ho citato nella mia discussione della numerazione
   delle versioni.
     _________________________________________________________

A. GNU Free Documentation License

A.1. 0. 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.
     _________________________________________________________

A.2. 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.
     _________________________________________________________

A.3. 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.
     _________________________________________________________

A.4. 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.
     _________________________________________________________

A.5. 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 .
     _________________________________________________________

A.6. 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."
     _________________________________________________________

A.7. 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.
     _________________________________________________________

A.8. 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.
     _________________________________________________________

A.9. 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.
     _________________________________________________________

A.10. 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.
     _________________________________________________________

A.11. 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.
