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.