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.
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.
Lunghezze massime dei buffer, conversione dati, limiti superiori/inferiori, e così via.
È 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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ì.
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.
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.
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).
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.