Indice
Il modello classico di avvio di un progetto di software libero fu fornito da Eric Raymond su un saggio oggi famoso sui metodi dell'open source intitolato La Cattedrale e il Bazaar. Egli scriveva:
Ogni buon lavoro di software nasce dall'atto dello sviluppatore di grattarsi un prurito personale.
Da notare che Raymond non stava dicendo che l'open source si ha quando qualche individuo ha prurito. Piuttosto stava dicendo che il buon software nasce quando il programmatore ha interesse a vedere risolti i problemi. La rilevanza di ciò per il software libero era che il prurito personale si rivelava essere la più frequente motivazione nel far partire un progetto di software libero.
Questo è ancora oggi il modo in cui i progetti liberi partono, ma meno oggi che nel 1997, quando Raymond scriveva queste parole. Oggi abbiamo il fenomeno di organizzazioni, incluse quelle che lo fanno per profitto—che danno il via a grossi progetti open source centralizzati organizzativamente. Il programmatore solitario che batte del codice per risolvere un problema locale e che poi si rende conto che il risultato ha una larga applicabilità è ancora la sorgente di molto nuovo software libero, ma non è la sola storia.
La condizione essenziale è che i produttori abbiano un interesse diretto al suo successo perchè lo usano essi stessi. Se il software non fa quello che si suppone faccia l'organizzazione o la persona che lo produce sentirà una insoddisfazione nel suo lavoro giornaliero. Per esempio, il progetto OpenAdapte (http://www.openadapter.org/), che fu avviato dalla banca di investimenti Dresdner Kleinwort Wasserstein come base open source per integrare disparati sistemi di informazione finanziaria, può a mala pena dirsi un progetto che gratta il prurito di un programmatore solitario. Esso gratta un prurito istituzionale. Ma quel prurito vien fuori dall'esperienza dell'istituzione e dei suoi partners, e quindi se il progetto fallisce nell'alleviare il loro prurito essi lo sapranno. Questo congegno produce buon software perchè il giro di ritorno va nella giusta direzione. Il programma non viene scritto per essere venduto a qualche altro in modo che questi possa risolvere il suo problema. Esso viene scritto per risolvere il proprio problema di qualcuno, quindi viene condiviso con chiunque, più o meno come se il problema fosse una malattia e il software una medicina la cui distribuzione intende sradicare completamente l'epidemia.Questo capitolo tratta di come mettere al mondo un nuovo software, ma molte delle sue raccomandazioni suoneranno familiari a una organizzazione della sanità distributrice di medicine. Gli obiettivi sono molto simili: voi volete chiarire ciò che la medicina fa, la mettete nelle mani delle persone giuste e vi assicurate che quelli che la ricevono sappiano usarla, ma col software voi volete attirare alcuni dei destinatari a unirsi al tentativo di migliorare la medicina.
Il software ha bisogno di acquisire utilizzatori e di acquisire sviluppatori. Queste due necessità non sono necessariamente in conflitto, ma aggiungono complessità alla presentazione iniziale del progetto. Qualche informazione è utile per ambedue le categorie, qualcuna è utile solo per l'una o solo per l'altra. Tutti e due i tipi di informazione dovrebbero dare un contributo al principio di una informazione adattata. Cioè il grado di dettaglio fornito ad ogni stadio dovrebbe corrispondere direttamente alla quantità di tempo e di sforzo immessovi dal lettore. Maggiore sforzo dovrebbe essere sempre uguale a maggior ricompensa. Quando le due cose non sono correlate fermamente la gente può velocemente perdere la fiducia e abbandonare il tentativo.
Il corollario a ciò è così la questione dell'apparenza. Ai programmatore spesso non piace pensare a ciò. Il loro amore per la sostanza più che per la forma è quasi un punto di vanto professionale. Non è un caso che così tanti programmatori mostrino una antipatia per il lavoro di marketing e di pubbliche relazioni né che i creatori di grafica professionale siano inorriditi di fronte a quello che i programmatori fanno pensare per conto proprio.
Questo è un peccato, perchè ci sono situazioni in cui la forma è sostanza, e la presentazione è una di quelle. Per esempio la primissima cosa di cui un visitatore viena a conoscenza circa un progetto è l'aparenza del suo sito web. Questa informazione è assorbita prima di quello che realmente vi è contenuto—di ogni testo sia stato letto o dei links cliccati. Per quanto ingiusto possa essere ciò, la gente non può astenersi dal formarsi una prima impressione. L'apparenza di un sito web dà un segno di quanta cura è stata messa nell'organizzare la presentazione di un progetto. Gli uomini hanno hanno antenne molto sensibili nel captare l'impiego di attenzione. Molti di noi possono dire a un prima occhiata se un sito è stato messo insieme disordinatamente o se è stato pensato seriamente. Questo è il primo pezzo di informazione che il vostro progetto dà e l'impressione che esso crea si trasferirà al resto del progetto per associazione.
Così mentre molta parte di questo capitolo parla del contenuto con cui il vostro progetto potrebbe partire, ricordatevi della questione del look e anche delle impressioni. Siccome il sito del progetto ha a che fare con due tipi di visitatori—utilizzatori e sviluppatori—una attenzione speciale si deve fare alla chiarezza e a chi è diretto. Sebbene questo non sia il luogo per una trattazione generale del web design, un principio è meritevole di menzione, specialmente quando il sito serve a molti tipi di pubblico (anche se e una sovrapposizione): la gente deve avere una grezza idea di dove il link va, prima di cliccarlo. Per esempio dovrebbe essere ovvio nel guardare ai links che portano alla documentazione utente che essi portano alla documentazione utente, e non, per esempio, alla documentazione sviluppatore. Il mandare avanti un progetto consiste in parte nel fornire informazioni, ma anche nel dare comodità. La sola presenza di certe offerte standard, in luoghi determinati, riassicura gli utilizzatori e gli sviluppatori che stanno decidendo se essere coinvolti. Ciò vuol dire che questo progetto ha la caratteristica di procedere insieme, anticipa le domande che la gente farà e ha fatto lo sforzo di rispondere loro in modo che è richiesto un minimo sforzo da parte di chi fa le domande. Creando questa atmosfera di preparazione, il progetto dà questo messaggio: “Il vostro tempo non sarà sprecato se sarete coinvolti”, che è esattamente la cosa che la gente vuole sentirsi dire.
Prima di partire con un nuovo progetto c'è un importante avvertimento:
Sempre guardarci intorno per vedere se c'è un progetto esistente che fa ciò che noi vogliamo. Sono molto buone le possibilità che un problema che volete risolvere ora, qualcun altro lo ha voluto risolvere prima di voi. Se lo hanno risolto e hanno rilasciato il loro codice sotto una licenza libera, allora non c'è motivo per voi di reinventare la ruota oggi. Ci sono eccezioni, certamente: se volete avviare un progetto per una esigenza educativa un codice preesistente non vi aiuterebbe; oppure può essere che il progetto che avete i mente è così specializzato che voi sapete che non c'è alcuna possibilità che qualcuno lo abbia fatto. Ma generalmente non c'è nessun motivo per non guardare e la ricompensa può essere enorme. Se la ricerca sui motori di ricerca di Internet non dà risultato, cercate su http://freshmeat.net/ (un sito di notizie sui progetti open source di cui si parlerà molto, più in là), su http://www.sourceforge.net/, nella Free Software Foundation's directory a http://directory.fsf.org/.
Anche se non trovate esattamente ciò che state cercando, potreste trovare qualcosa così vicina che avrebbe più senso unirsi a quel progetto e aggiungervi funzionalità, che partire da un vostro abbozzo.
Vi siete guardati intorno, trovato che niente fuori soddisfa veramente i vostri bisogni, e avete deciso di partire con un nuovo progetto.
Cosa viene ora?
La parte più difficile nel lanciare un nuovo progetto è trasformare una visione privata in una visione pubblica. Voi nella vostra organizzazione potete conoscere alla perfezione ciò che volete, ma esprimere chiaramente al mondo l'obiettivo è una chiara quantità di lavoro. E' essenziale, comunque, che vi prendiate il tempo per farlo. Voi e gli altri fondatori dovete decidere su che cosa sarà in realtà il progetto—cioè, stabilire i suoi limiti, ciò che non farà allo stesso modo di ciò che farà—e scrivere una dichiarazione delle vostre intenzioni. Questa parte non è usualmente troppo difficile, sebbene essa può rivelare supposizioni non dette e anche disaccordi sulla natura del progetto, che è cosa buona: meglio risolvere queste cose ora che più tardi. Il passo successivo è confezionare il progetto per il pubblico consumo, e questa è, fondamentalmente, una vera e propria sgobbata.
Ciò che lo rende così laborioso è che esso consiste principalmente nell'organizzare e documentare cose che ognuno conosce già—“ognuno”, cioè, coloro che sono stati finora coinvolti nel progetto. Cosicchè per coloro che fanno il lavoro non c'è un immediato beneficio. Essi non hanno bisogno di un file README che dia una panoramica, né di un documento di progetto o di un manuale utente. Essi non hanno bisogno di un albero del codice messo in ordine con cura, conforme agli informali ma assai diffusi standards delle distribuzioni di codice sorgente. Ad ogni modo il codice sorgente messo a punto è buono per loro perchè vi sono avvezzi comunque, e se il codice non gira affatto, essi sanno come usarlo. E non ha importanza, per essi, se i presupposti fondamentali dell'architettura del progetto rimangono non documentati; essi invece sono familiari con esso.
I nuovi arrivati, d'altra parte, hanno bisogno di queste cose. Fortunatamente essi non ne hanno bisogno tutti in una volta. Non è necessario per voi fornire ogni possibile risorsa prima di rendere pubblico un progetto. In un mondo perfetto, forse, ogni nuovo progetto open source prenderebbe vita con una completa documentazione della fase di progettazione, un manuale utente completo (con speciali note su funzionalità pianificate ma non ancora implementate), bel codice confezionato in modo che sia trasportabile, capace di girare su ogni piattaforma di elaborazione, e così via. In realtà prendersi cura di tutti questi disparati fini sarebbe una proibitiva perdita di tempo e, comunque, è lavoro in cui uno può ragionevolmente sperare di essere aiutato da volontari, una volta che il progetto sia avviato.
Ciò che è necessario, comunque, è che un sufficiente impiego di energie venga attuato nella presentazione che i nuovi arrivati possono trovare dopo dopo la difficoltà o la non familiarità iniziale. Pensate a ciò come ad un primo passo di un processo che si sta avviando, per tenere il progetto a un specie di minima energia di attivazione. Ho sentito che questa soglia veniva chiamata la hacktivation energy: la quantità di energia che il nuovo arrivato deve immettere prima di incominciare ad entrare in possesso di qualcosa. Più piccola è l'energia di attivazione di un progetto, tanto meglio è. Il vostro primo compito è tenere l'energia di attivazione bassa, a un livello che incoraggi la gente a farsi coinvolgere.
Ciascuna delle sottosezioni seguenti descrive un aspetto importante nell'avvio di un nuovo progetto. Esse sono presentate approssimativamente nell'ordine in cui un nuovo visitatore le incontrerebbe, sebbene certamente l'ordine in cui voi in realtà le implementate potrebbe essere diverso. Voi potete trattarle come una lista da spuntare. Quando avviate un progetto andate fino in fondo alla lista e vi assicurate di aver incluso tutti le voci, o almeno che siate sereni sulle potenziali conseguenze di averne lasciata fuori una.
Mettetevi nei panni di qualcuno che ha appena saputo del vostro progetto, forse per essersi imbattuto in esso alla ricerca di un software che risolvesse il suo problema. La prima cosa che egli incontra è il nome del progetto.
Un bel nome non renderà il vostro progetto un progetto di successo e un brutto nome non lo rovinerà;—beh, un nome veramente brutto potrebbe farlo, ma noi partiamo dall'ipotesi che nessuno stia cercando di far fallire il proprio progetto. Comunque, un brutto nome può rallentare l'adozione di un progetto, sia perchè la gente non lo prende seriamente, sia perchè semplicemente ha difficoltà a ricordarlo.
Un nome bello:
: dà un'idea di ciò che il progetto fa, o almeno vi è correlato un modo chiaro, cosicchè se uno conosce il nome e conosce quello che il progetto fa, il nome verrà subito in mente dopo.
E' facile da ricordare. Qui, ecco non c'è da girare intorno al fatto che l'inglese è la lingua predefinita di Internet: “facile da ricordare” significa ”facile da ricordare per qualcuno che sa leggere l'inglese”. Nomi che sono dipendenti da giochi di parole della pronuncia nativa, per esempio, saranno poco chiari a molti lettori non nativi di inglese là fuori. Se il gioco di parole suscita particolare interesse ed è particolarmente memorizzabile può ancora valere la pena di usarlo; solo mettetevi in testa che molta gente vedendo il nome non lo sente nella testa allo stesso modo di chi parla l'inglese come nativo.
Non è come con altri nomi di progetti e non viola il marchio. Questa è solo una buona maniera e buona anche in senso legale. Voi non volete creare confusione di identità. E' abbastanza difficile tener traccia di ciò che è disponibile in rete già ora, senza cose differenti che hanno lo stesso nome.
L risorse menzionate prima in sezione chiamata «Ma Prima, Guardiamoci Intorno» Sono utili a scoprire se progetto ha lo stesso nome a cui state pensando voi. Libere ricerche di marchi liberi sono disponibili a http://www.nameprotect.org/ e http://www.uspto.gov/.
Se possibile, sia disponibile come nome del dominio
.com,
.net, e
.org domini di primo livello. Voi dovreste sceglierne uno, forse .org,
da annunciare come sito ufficiale del progetto; gli altri due doverebbero condurre lì e sono un modo semplice per impedire a terze parti di creare confusione sul nome del progetto. Anche se volete hostare il progetto su un altro sito (vedere
sezione chiamata «L' Hosting In Scatola»), potete ugualmente registrare domini specifici per il progetto e redirigerli al sito ospitante. Ciò aiuta molto gli utilizzatori ad avere un URL facile da ricordare.
Una volta che avete trovato il sito web del progetto, la cosa successiva che la gente cercherà è una breve ma veloce descrizione, una dichiarazione di intenti in modo da poter decidere (in 30 secondi) se è interessata a saperne di più. Questa deve essere messa in evidenza in prima pagina, preferibilmente sotto al nome del progetto.
La dichiarazione di intenti deve essere concreta, limitativa, e soprattutto breve. Qui c'è n'è un esempio di una buona, da http://www.openoffice.org/:
Per creare, come comunità, la swite leader a livello internazionale per ufficio che gira su tutte le principali piattaforme e che fornisce accesso a tutte le funzionalità e ai dati grazie a un componente basato sulle API e a un formato di file basato sull'XML.
Giusto in poche parole, essi hanno centrato tutti i punti principali prendendo largamente ispirazione dalla conoscenza precedente dei lettori. Dicendo "come comunità", essi segnalano che nessuna grossa impresa dominerà lo sviluppo; "internazionale" significa che il software permetterà alla gente di lavorare in molti lingue e luoghi; "Tutte le principali piattaforme" significa che esso sarà trasportabile su Unix, Macintosh, e Windows. Il resto segnala che le interfacce aperte e i formati facilmente comprensibili sono una parte importante dell' obiettivo. Essi non vengono direttamente allo scoperto e dicono che stanno cercando di essere una alternativa libera all'Office della Microsoft, ma molta gente può verosimilmente leggere tra le righe. Sebbene questa dichiarazione di intenti sembri ampia ad una prima occhiata, nei fatti è piuttosto circoscritta: le parole "swite per ufficio" hanno il significato di qualcosa di molto concreto a quelli che sono familiari con questo software .Inoltre la presunta precedente conoscenza del lettore (in questo caso probabilmente di Office della Microsoft) è usata per mantenere concisa la dichiarazione di intenti.
La natura di una dichiarazione di intenti dipende in parte da chi la sta scrivendo, non dal software che descrive. Per esempio per Openoffice.org ha senso usare le parole "come una comunità", perchè il progetto fu avviato ed è ancora sponsorizzato da Sun Microsystems. Includendo quelle parole Sun manifesta la sua sensibilità alle preoccupazioni circa il fatto che essa potrebbe dominare il processo di sviluppo. Con una cosa di questo tipo, dimostrando unicamente la consapevolezza del potenziale per un problema va lontano nell'evitare del tutto il problema. D'altra parte i progetti che non sono sponsorizzati da una singola grande impresa non hanno bisogno probabilmente di un simile linguaggio; dopotutto lo sviluppo da parte di una comunità è la norma, sicchè non ci sarebbe ragione di metterlo in lista come parte degli intenti.
Quelli che restano interessati dopo aver letto la dichiarazione di intenti vorranno poi vedere più dettagli, forse qualche documentazione utente o sviluppatore e eventualmente vorranno scaricare qualcosa. Ma prima di ognuna di queste cose essi vorranno essere sicuri che è open source.
La pagina principale deve rendere inequivocabilmente chiaro che quel progetto è open source. Ciò può sembrare ovvio, ma sareste sorpresi dal fatto di quanti progetti dimenticano di farlo. Ho visto tanti siti di progetti di software libero dove la pagina principale non solo non diceva sotto quale licenza particolare il software era distribuito, ma nemmeno specificava chiaramente che il software era libero. A volte il dato fondamentale informativo era relegato nella pagina dei downloads, o nella pagina degli sviluppatori, o in qualche altro posto che richiedeva un ulteriore clic del mouse per arrivarvi. In casi estremi la licenza non era inserita affatto nel sito web e l'unico modo per vederla era quello di scaricare il software e di guardarvi dentro.
Non fate questo errore. Tale omissione può far perdere molti potenziali sviluppatori e utilizzatori. Specificate in modo aperto, giusto sotto la dichiarazione di intenti che il progetto e “software libero” e “open source” e fornite la licenza esatta. Una guida rapida alla scelta della licenza è data in sezione chiamata «Scegliere una Licenza e Applicarla» più in là in questo capitolo , e le questioni sulle licenze sono discusse in dettaglio in Capitolo 9, Licenze, Diritti d'Autore e Brevetti.
A questo punto i nostri ipotetici visitatori hanno deciso—probabilmente in un minuto o meno—che sono interessati a spendere, per esempio, almeno cinque ulteriori minuti nell' esaminare questo progetto. Le prossime sezioni descrivono ciò che essi potrebbero incontrare in quei cinque minuti.
Ci potrebbe essere una lista delle funzionalità del software (se qualcosa non è ancora completa potete ugualmente metterla in lista ma mettete "pianificato" o "in corso" vicino ad essa), e il tipo di ambiente di elaborazione richiesto dal software. Pensate alla lista di funzionalità/requisiti come a qualcosa che dareste a uno che chiedesse un sommario veloce del software. E' spesso giusto una logica espansione della dichiarazione di intenti. Per esempio la dichiarazione di intenti potrebbe dire:
Per creare un indice full-text e un motore di ricerca con una ricca API ad uso dei programmatori nel fornire servizi di ricerca per grosse quantità di files di testo.
L'elenco delle caratteristiche e dei requisiti darebbe i dettagli, chiarendo la portata della dichiarazione di intenti :
Caratteristiche:
Testo di ricerca non formattato, HTML, e XML
Ricerca di una parola o di una frase
(pianificata) Ricerca diffusa
(pianificata) Aggiornamento incrementale degli indici
(pianificata) Indicizzazione dei siti web
Requisiti:
Python 2.2 o superiore
Sufficiente spazio su disco da contenere gli indici (approssimativamente 2x dimensione dei dati)
Con queste informazioni i lettori possono velocemente farsi un'idea di quanto questo software abbia speranza di funzionare per loro e possono pensare di farsi coinvolgere anche come sviluppatori.
La gente vuole sempre sapere quanto il progetto sta facendo. Per i nuovi progetti, essi vogliono sapere il ritardo fra le promesse del progetto e la corrente realtà. Per i progetti maturi vogliono sapere quanto è attiva è la sua manutenzione, quanto spesso escono le nuove releases, come probabilmente si reagisce ai rapporti dei bugs, ecc..
Per rispondere a queste domande dovreste metter su una pagina dello stato dello sviluppo con l'elenco degli obiettivi a breve termine del progetto e delle sue necessità (per esempio, si potrebbe essere alla ricerca di sviluppatori con una particolare esperienza). La pagina può anche fornire una storia della passate releases, con gli elenchi delle caratteristiche, cosicchè i visitatori possano farsi un'idea di come il progetto definisce l'“avanzamento” e di quanto velocemente avanza in accordo con tale definizione.
Non vi spaventate se vi vedete impreparati, e non siate tentati di esagerare sullo stato di sviluppo. Chiunque sa che il software si evolve per stadi; non c'è da vergognarsi a dire “Questo è il software alfa con bugs noti. Esso gira, e funziona almeno per qualche tempo, ma lo usate a vostro rischio” Un tale linguaggio non farà fuggire per lo spavento il tipo di sviluppatori di cui voi avete bisogno in quello stadio. Per quanto riguarda gli utilizzatori, una delle peggiori cose che un progetto può fare è attrarre utilizzatori prima che sia finito. Una reputazione per l'instabilità o per gli errori è difficile da scrollarsela di dosso, una volta che se la si è fatta. La prudenza paga a lungo andare. E' sempre meglio che il software sia più stabile di quanto gli utilizzatori si aspettino che meno stabile, e le sorprese piacevoli producono il più bel tipo di voci.
Il software dovrebbe essere scaricabile come codice sorgente in formato standard. Quando il progetto sta inizialmente prendendo avvio il pacchetto binario (eseguibile) non è necessario, amenochè il software abbia i requisiti di costruzione o aspetti annessi talmente complicati che il semplice prelevarlo per farlo girare sarebbe un gran lavoro per molta gente. (Ma in questo caso il progetto è in un brutto periodo per attrarre sviluppatori comunque!)
Il meccanismo di distribuzione dovrebbe essere agevole, standardizzato e il meno astratto possibile. Se steste cercando di sradicare un male, non distribuireste la medicina in modo tale che essa richieda una grandezza della siringa non standard per somministrarla. Allo stesso modo il software doverebbe conformarsi a metodi standard di costruzione e di installazione; più esso devia dagli standards più i potenziali utilizzatori e sviluppatori abbandoneranno e andranno via confusi.
Il che suona ovvio, ma molti progetti non si infastidiscono a standardizzare le loro procedure di installazione prima che sia molto tardi nel gioco, dicendo che possono farlo in qualsiasi momento: "Sistemeremo tutte quelle cose quando il codice sarà più vicino ad essere pronto." Ciò di cui non si rendono conto è che rimandando il lavoro noioso di portare a termine le procedure di costruzione e di installazione, in realtà stanno facendo in modo che il codice tardi ulteriormente ad essere pronto—perchè scoraggiano gli sviluppatori che altrimenti avrebbero contribuito al codice. Molto insidiosamente, essi non sanno che stanno perdendo tutti quegli sviluppatori, perchè il processo è accumulazione di non eventi: qualcuno visita il sito, scarica il software, cerca di svilupparlo, fallisce, abbandona e va via. Chi mai saprà che ciò è accaduto, al di fuori delle stesse persone? Nessuno di quelli che lavorano al progetto si renderà conto che che l'interesse e la buona volontà di qualcuno è stata dissipata.
Un lavoro noioso con un'alta ricompensa dovrebbe essere fatto all'inizio e abbassando significativamente l'ostacolo di presentare un progetto con una buona confezione porta una ricompensa molto alta.
Quando rilasciate un pacchetto scaricabile è di vitale importanza che voi diate un numero univoco di versione alla release, così la gente può confrontare due release e sapere quale sostituisce l'altra. Una trattazione dettagliata sulla numerazione delle versioni può essere trovata in sezione chiamata «Numerazione delle Releases», e i dettagli sulle procedure di standardizzazione della costruzione e dell'installazione sono contemplate in sezione chiamata «Impacchettamento» , e anche in Capitolo 7, Confezione, Rilascio, e Sviluppo Quotidiano .
Lo scaricamento dei pacchetti sorgente è piacevole per coloro che vogliono giusto installare e usare il programma, ma non è abbastanza per coloro che vogliono correggerne i bug e aggiungere nuove qualità. Istantanee notturne del sorgente possono aiutare, ma non c'è ancora una struttura sufficientemente a grani piccoli per una comunità che sta crescendo. La gente vuole un accesso in tempo reale agli ultimi codici sorgente e il modo per darglielo è usare un sistema di controllo versione. La presenza di versione dei sorgenti anonimamente controllate di è un segno a utilizzatori e sviluppatori—cioè questo progetto sta facendo uno sforzo per dare alla gente quello di cui ha bisogno per partecipare. Se voi non potete dare un controllo di versione subito, allora date un segno che intendete darlo presto. Della infrastruttura del controllo di versione si parla in dettaglio in sezione chiamata «Controllo di versione» in Capitolo 3, L'Infrastruttura Tecnica .
La stessa cosa per il tracciamento bug del progetto. L'importanza di un sistema di tracciamento bug sta non solo nella sua utilità per gli sviluppatori ma in quello che significa per chi osserva il progetto. Per molta gente una database accessibile dei bug è un fortissimo segnale che il progetto dovrebbe essere preso seriamente. Inoltre, più alto è il numero di bugs nel database, più il progetto sembra migliore. Ciò potrebbe sembrare contrario alla logica, ma ricordate che il numero dei bugs registrati in realtà dipende da tre cose: il numero in assoluto presente nel software, il numero di utilizzatori che usano quel software, e la comodità con cui questi utilizzatori possono registrare nuovi bugs. Di questi tre fattori gli ultimi due sono più significativi del primo. Un software di sufficiente complessità e grandezza ha essenzialmente un numero arbitrario di bugs che devono essere scoperti. La vera domanda è, quanto il progetto fa per registrare e elencare in ordine di priorità questi bugs? Un progetto con un grosso e ben mantenuto database dei bugs (i bugs significativi ricevono una risposta prontamente, i bugs duplicati vengono unificati, ecc..) quindi dà una impressione migliore di un progetto senza una database dei bugs o di un database quasi vuoto.
Certo, se il vostro progetto sta giusto partendo, il database dei bugs conterrà assai pochi bugs, e non c'è molto che voi possiate fare su questo. Ma se la pagina dello stato mette in evidenza la giovinezza del progetto e se la gente guardando il database può vedere che molte archiviazioni sono avvenute di recente, può dedurre da ciò che il progetto ha ancora una salutare velocità di archiviazioni, e non sarà ingiustamente allarmata dal basso numero di bugs registrati.
Notare che i tracciatori di bug sono spesso usati per tracciare non solo i bug di software, ma anche richieste di crescita, cambiamenti di documentazione di, operazioni pendenti, e altro. I dettagli di un tracciatore di bugs in funzione sono visibili in sezione chiamata «Tracciamento dei bug» in Capitolo 3, L'Infrastruttura Tecnica , così io non entrerò in essi qui. La cosa importante dal punto di vista di una presentazione è giusto avere un tracciamento dei bugs e assicurarsi del fatto che sia visibile nella pagina principale.
I visitatori di solito vogliono sapere come raggiungere le persone coinvolte nel progetto. Fornite gli indirizzi delle mailing lists, delle chat, dei canali IRC e dei forums dove le altre persone interessate al software possano essere raggiunte. Rendete chiaro che voi e gli altri autori del progetto siete iscritti a queste mailing lists cosicchè la gente possa vedere che c'è un modo per far sapere che raggiungeranno gli sviluppatori. La vostra presenza nelle liste non implica un impegno a rispondere a tutte le domande o a implementare tutte le funzionalità future. Alla fine molti utilizzatori probabilmente non si uniranno mai ai forum comunque, ma saranno confortati dal fatto di sapere che potrebbero unirsi se caso mai ne avessero bisogno.
Nei primi stadi del progetto non c'è bisogno di avere forums separati per utilizzatori e sviluppatori. E' molto meglio che tutti siano spinti a parlare del software fra loro in un'unica “stanza”. Fra i primi arrivati la distinzione fra utilizzatori e sviluppatori è spesso sfocata. Nell'ambito in cui la distinzione può essere fatta il rapporto sviluppatori/utilizzatori è di solito molto più alto nei primi giorni del progetto che non in seguito. Mentre si può supporre che ognuno dei primi che aderiscono sia un programmatore che vuole cimentarsi col software, allo stesso tempo si può supporre che egli sia almeno interessato alle successive discussioni sullo sviluppo e a cogliere il senso degli indirizzi del progetto.
Sebbene questo capitolo parli solo della partenza di un progetto, è solo sufficiente dire che c'è bisogno questi forums di comunicazione esistano. Più in là, in sezione chiamata «Gestire la Crescita» in Capitolo 6, Comunicazione , esamineremo come e dove metter su tali forums i modi in cui essi potrebbero aver bisogno di moderazione o di altra amministrazione e come separare i forums per utilizzatori dai forums per sviluppatori, quando viene il momento, senza creare un abisso insuperabile.
Se qualcuno sta pensando di contribuire al progetto egli cercherà le linee guida per gli sviluppatori. Le linee non sono tanto tecniche quanto sociali: esse spiegano come gli sviluppatori interagiscono fra di loro e con gli utilizzatori e infine come si portano a termine le cose.
Questo argomento è trattato in dettaglio in sezione chiamata «Metter Giù Tutto Per Iscritto» in Capitolo 4, L'Infrastruttura Sociale e Politica , ma gli elemento base delle linee guida sono:
gli indici dei forums per l'interazione con gli altri sviluppatori
istruzioni su come riportare i bugs e inviare la patches
alcune istruzioni su come lo sviluppo viene generalmente fatto—il progetto è una benevola dittatura, una democrazia o qualcos'altro
Il termine “dittatura” non è inteso in senso peggiorativo, per inciso. E' un perfetto okay al realizzarsi di una tirannia dove un particolare sviluppatore ha il potere di veto su tutti i cambiamenti. Molti progetti di successo funzionano in questo modo. L'importante è che il progetto venga fuori e si fa per dire così. Una tirannia che pretenda di essere una democrazia disgusterà la gente. Una tirannia che dice di essere una tirannia andrà bene finchè il tiranno è competente e fidato.
Vedere http://subversion.apache.org/docs/community-guide/ per un esempio completo di linee guida, o http://www.openoffice.org/dev_docs/guidelines.html per linee guida che mettono a fuoco più l'amministrazione e lo spirito di partecipazione e meno le questioni tecniche.
Il problema separato di fornire al programmatore una introduzione al software è trattato in sezione chiamata «La documentazione sviluppatore» più in là in questo capitolo .
La documentazione è fondamentale. Bisogna che la gente abbia qualcosa da leggere, anche se questo qualcosa è rudimentale è incompleto. Ciò cade in pieno nella categoria “sgobbata” cui si è fatto riferimento prima ed è spesso la prima zona dove un nuovo progetto open source fallisce. Venir fuori con una dichiarazione di intenti, e con un elenco delle caratteristiche, scegliere una licenza, fare il punto sullo stato dello sviluppo—questi sono compiti relativamente piccoli che possono essere completati definitivamente e in genere non c'è bisogno di ritornarci su. La documentazione, invece, non è mai realmente finita, il che può essere un motivo per cui la gente a volte tarda proprio a iniziarla.
La cosa più insidiosa è che l'utilità della documentazione per quelli che la scrivono è inversamente proporzionale a quella di coloro che la leggeranno. La più importante documentazione per gli utilizzatori iniziali sono le basi: come installare velocemente il software, una panoramica su come funziona, magari qualche guida per eseguire alcune operazioni. Queste sono esattamente le cose che coloro che scrivono la documentazione conoscono troppo bene— così bene che può essere difficile per loro vedere le cose dal punto di vista del lettore e parlare con impegno dei passi che (a coloro che la scrivono) sembrano ovvi e non meritevoli di menzione.
Non esiste una soluzione magica a questo problema. Qualcuno giusto ha bisogno di sedersi e scrivere la materia, e poi farla funzionare da parte degli utilizzatori tipici per verificare la sua qualità. Usate un formato facile per le modifiche come l'html, il testo semplice, il Textinfo o qualche variante dell'XML—qualcosa che sia adatto per facilità, veloci miglioramenti a botta calda. Questo solo per rimuovere una qualsiasi cosa all'inizio che potrebbe impedire a coloro che originariamente hanno scritto la documentazione di apportare successivi miglioramenti, ma anche a coloro che si aggregano dopo al progetto e che vogliono lavorare alla documentazione.
Una maniera per assicurarsi che una documentazione di base iniziale sia portata a termine è limitare la sua portata in precedenza. In quel modo lo scriverla almeno non sembrerà come un compito indeterminato. Una buona regola pratica è quella che soddisferà i seguenti criteri:
Dire al lettore quanta esperienza tecnica ci si aspetta da lui.
Dire chiaramente e in modo esauriente come configurare il software e, in qualche posto vicino all'inizio della documentazione dire all'utilizzatore come attuare una sorta di test diagnostico o un semplice comando che confermi che ha configurato correttamente le cose. Una documentazione sulla configurazione è in una certa maniera più importante della documentazione sul vero e proprio utilizzo. Quanto maggiore sarà lo sforzo che uno avrà investito nell'installare e far partire il software, tanto maggiore sarà la sua tenacia nello scoprire funzionalità avanzate che non sono ben documentate. Quando la gente abbandona, abbandona all'inizio; perciò sono i primissimi stadi, come l'installazione, che hanno bisogno del maggior supporto.
Date un esempio stile tutorial di come svolgere una operazione comune. Ovviamente molti esempi per molte operazioni sarebbero sempre la cosa migliore ma se il tempo è limitato, prendete una sola operazione e spiegatela fino in fondo. Una volta che uno vede che il software può essere usato per una cosa partirà ad esplorare cos'altro può fare per sé stesso—e, se siete fortunati incomincerà a coinvolgersi nella documentazione. La qual cosa ci porta al prossimo punto...
Segnatevi le aree in cui è noto che la documentazione è incompleta. Mostrando ai lettori che siete al corrente delle sue manchevolezze vi allineerete al loro punto di vista. La vostra capacità di comprenderli li rassicura che essi non sono di fronte al grande sforzo di convincere il progetto di quello che è importante. Non c'è bisogno che questi appunti rappresentino promesse di riempire i vuoti a partire da una data particolare—è ugualmente legittimo trattarli come aperte richieste di un aiuto di tipo volontario.
L'ultimo punto è di grande importanza, davvero, è può essere applicato all'intero progetto, non esattamente alla documentazione. Un accurato rendere conto delle manchevolezze note è la norma nel mondo dell'open source. Non dovete amplificare le manchevolezze del progetto, giusto identificatele scrupolosamente e spassionatamente quando il contesto lo richiede (nella documentazione, nel database del tracciamento dei bugs, o nelle discussioni nelle mailing lists). Nessuno prenderà ciò per disfattismo sulla parte di progetto, nè come un ordine di risolvere i problemi entro una determinata data, a meno che il progetto dia questo ordine esplicitamente. Siccome chiunque usa il software scoprirà le manchevolezze da sé, è molto meglio che sia psicologicamente preparato—allora sembrerà come se il progetto abbia una solida consapevolezza di come sta andando.
La documentazione dovrebbe essere disponibile in due posti: online (direttamente dal sito), e e nella distribuzione scaricabile del software (vedere sezione chiamata «Impacchettamento» in Capitolo 7, Confezione, Rilascio, e Sviluppo Quotidiano ). C'è bisogno che sia online accessibile, via browser, perchè spesso la gente legge la documentazione prima di scaricare il software per la prima volta, come aiuto a decidere se scaricare punto. Ma essa dovrebbe accompagnare il software, sulla base del principio che il download dovrebbe fornire (cioè, rendere accessibile localmente) ogni cosa di cui uno ha bisogno per usare il pacchetto.
Per la documentazione online assicuratevi che ci sia un link che porti all' intera documentazione in una pagina html (mettete una nota tipo “monolitica” o “tutto in uno” o “singola grande pagina” vicino al link affinchè la gente sappia che potrebbe impiegare un periodo di tempo a caricarsi). Ciò è utile perchè spesso la gente vuol cercare una parola specifica o una frase nell'intera documentazione. In genere sanno già ciò che stanno cercando; essi non sanno solo in quale sezione è. Per tali persone niente è più frustrante dell'imbattersi in una pagina html per la tavola dei contenuti, poi in una pagina differente per l'istruzione, poi un'altra pagina per le istruzioni di installazione, ecc.. Quando le pagine sono spezzate così la funzione cerca del browser è inutile. Lo stile a pagine separate è utile per quelli che già sanno di quale sezione hanno bisogno, o che vogliono leggere la documentazione dall'inizio alla fine in sequenza. Ma questo non è il modo più comune di accedere alla documentazione. Molto più spesso chi è fondamentalmente familiare col software ritorna a cercare una specifica parola o frase. Fallire nel venire in aiuto ad essi con un unico documento ove si possa fare una ricerca renderebbe loro solo la vita più difficile.
La documentazione sviluppatore viene scritta per aiutare gli sviluppatori a capire il codice, cosicchè essi possano correggerlo ed estenderlo. Questa è in qualche modo differente dalle linee guida sviluppatore discusse prima, che sono più sociali che tecniche. Le linee guida sviluppatore dicono loro come andare d'accordo con il codice vero e proprio. Le due cose sono spesso impacchettate in un unico documento per convenienza (come con l' http://subversion.apache.org/docs/community-guide/ esempio dato prima), ma non hanno bisogno di esserlo.
Sebbene la documentazione sviluppatore possa essere molto utile non c'è motivo di tardare a rilasciare un permesso di farla. Finchè gli autori originari sono disponibili (e vogliono) rispondere alle domande sul codice, questo è sufficiente per partire. Infatti il dover rispondere alle stesse domande più e più volte è un motivo comune per scrivere la documentazione. Ma anche prima che essa sia scritta determinati collaboratori si daranno da fare per trovare una loro via per quanto riguarda il codice. La forza che guida la gente a spender tempo a imparare il codice base è che il codice è talvolta utile per se stessi. Se la gente ha fiducia in esso, si prenderà il tempo per capire le cose; se non ha questa fiducia nessuna quantità di documentazione li attirerà o li manterrà.
Così se avete tempo per scrivere la documentazione per un solo uditorio, scrivetela per gli utilizzatori. Tutta la documentazione utilizzatore è, in effetti, anche una documentazione sviluppatore; un programmatore che si sta accingendo a lavorare su una parte di software avrà bisogno di familiarizzare con il suo utilizzo. Più in là, quando vedrete programmatori che chiedono più e più volte le stesse cose, prendetevi il tempo per scrivere documenti separati giusto per loro.
Alcuni progetti usano un sito web, (o comunque una collezione di documenti ipertestuali) che può essere modificato dai suoi utilizzatori e i cui contenuti sono sviluppati in collaborazione da tutti coloro che ne hanno accesso, come in un forum (wiki). Nella mia esperienza ciò funziona se è attivamente aggiornato da poche persone che convengono su come la documentazione deve essere organizzata e che “voce” deve avere. Vedere in sezione chiamata «Wiki» in Capitolo 3, L'Infrastruttura Tecnica per maggiori ragguagli.
Se il progetto comporta una interfaccia utente grafica, o se produce uscite grafiche o diversamente risultati particolari, mettetene qualche esempio sul sito. Nel caso dell'interfaccia, ciò significa screenshoots; nel caso di un risultato potrebbero essere screenshoots oppure veri e propri files. Ambedue le soluzioni fornirebbero alla gente una gratificazione istantanea: un singolo screenshoot può essere più convincente che paragrafi di testo descrittivo e di chiacchiere in mailing lists, perchè uno screenshot è una prova inconfutabile che il software funzionaPuò essere pazzo, può essere difficile da montare, può essere documentato in modo incompleto, ma questo screenshot è tuttavia una prova che se uno ci mette impegno, può ottenere che il software funzioni.
Ci sono molte altre cose che potete mettere sul vostro sito, se ne avete il tempo, o se per una ragione o per l'altra esse sono specialmente adatte: una pagina di notizie, una pagina della storia del progetto, una pagina di links correlati, un sistema di ricerca nel sito, un link per le donazioni, ecc.. Nessuna di queste cose è una necessità all'avvio, ma tenetele in mente per il futuro.
Ci sono pochi siti che offrono un hosting gratis e una infrastruttura per i progetti open source: un'area web, il controllo di versione, un tracciatore di bugs, un'area di download, un foro di dibattito, backups regolari, ecc. I dettagli variano da sito a sito, ma vengono forniti gli stessi servizi base da tutti questi. Se usate uno di questi siti, avete molto gratis; ciò che cedete, ovviamente, è un controllo raffinato sull'esperienza degli utilizzatori. Il sevizio di hosting decide il software che gira sul sito, è può controllare o almeno influenzare l'aspetto e la percezione delle pagine web.
Vedere sezione chiamata «Canned Hosting» in Capitolo 3, L'Infrastruttura Tecnica per una più dettagliata discussione e per i vantaggi e svantaggi degli hosting in scatola e per un elenco di siti che lo offrono.