Partenza 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 )
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 (), 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. Ma Prima, Guardiamoci Intorno 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 (un sito di notizie sui progetti open source di cui si parlerà molto, più in là), su , nella Free Software Foundation's directory a . 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. Partire Da Ciò Che Si Ha 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. Scegliere Un Buon Nome. 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 Sono utili a scoprire se progetto ha lo stesso nome a cui state pensando voi. Libere ricerche di marchi liberi sono disponibili a e . 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 ), 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. Avere una chiara dichiarazione di intenti 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 :
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. Specificare che il Progetto è Libero 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 più in là in questo capitolo , e le questioni sulle licenze sono discusse in dettaglio in . 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. Elenco dell Caratteristiche e dei Requisiti 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. Lo Stato dello Sviluppo 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. Alpha e Beta Il termine alfa usualmente vuol dire una prima release con la quale gli utilizzatori possono accedere al lavoro reale fatto, e che ha tutte le funzionalità progettate, ma che ha anche bugs conosciuti. Il proposito principale del software alfa è quello di generare una reazione cosicchè gli sviluppatori conoscano ciò su cui lavorare. Il successivo stadio, beta, è quello in cui in cui tutti i bugs seri sono stati corretti ma non è stato testato abbastanza per certificarsi come release. Il proposito di un software beta è quello di diventare una release, nell'ipotesi che nessun bug sia stato trovato, ma anche quello di dare una risposta dettagliata agli sviluppatori in modo che essi possano giungere velocemente alla release. La differenza fra alfa e beta e molto una questione di giudizio. Downloads 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 , e i dettagli sulle procedure di standardizzazione della costruzione e dell'installazione sono contemplate in , e anche in . Controllo Versione e Accesso al Tracciamento Bug 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 in . 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 in , 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 Canali di Comunicazione 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 in , 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. Linee Guida per lo Sviluppatore 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 in , 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 per un esempio completo di linee guida, o 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 più in là in questo capitolo . La documentazione 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. Manutenzione di una sezione FAQ Una FAQ (Un documento“Domande fatte di frequente”) può essere uno dei migliori investimenti che il progetto fa in termini di ritorno didattico. Le FAQs sono molto in sintonia con le domande che gli utilizzatori e gli sviluppatori in realtà fanno—invece delle domande che voi avreste potuto attendervi da loro—e quindi una sezione di FAQs ben mantenuta tende a dare a coloro che la consultano esattamente quello che essi stanno cercando. La sezione FAQ è la prima cosa che guardano quando incontrano un problema, spasso anche preferendola al manuale ufficiale ed è probabilmente il documento nel vostro progetto che viene linkato dagli altri siti. Sfortunatamente non potete fare le FAQ alla partenza del progetto. Della buone FAQs non sono scritte, esse vengono cresciute. Per definizione sono documenti di reazione, che si evolvono nel tempo in riposta all'uso che la gente fa del software giorno dopo giorno. Siccome è impossibile anticipare con successo le domande che la gente fa, è impossibile sedersi e scrivere delle utili FAQs dall'inizio. Quindi non perdete tempo nel cercare di scriverle. Potete comunque trovare utile metter su un modello generalmente vuoto, di modo che quello sarà un posto dove la gente potrà contribuire con domande e risposte una volta che il progetto ha preso avvio. A questo punto la più importante qualità non è la completezza, ma la convenienza: se la sezione FAQ è facile da crescere, la gente la farà crescere. (Una corretta manutenzione delle FAQ è una questione non banale e avvincente ed è discussa ulteriormente in in .) Disponibilità della documentazione La documentazione dovrebbe essere disponibile in due posti: online (direttamente dal sito), e e nella distribuzione scaricabile del software (vedere in ). 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 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' 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 in per maggiori ragguagli. Emissione di dati e screenshoots di esempio 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. Screenshots Dal momento che gli screenshoots possono scoraggiare finchè voi avete fatto in realtà poco, qui ci sono delle istruzioni di base per farli. Usando The Gimp (), aprire File->Acquisisci->Screenshot, scegliere Finestra singola o Schermo  intero, poi cliccate OK. Ora il vostro prossimo click di mouse catturerà la finestra o lo schermo clicckato in una immagine in The Gimp. Tagliate e ridimensionate l'immagine se necessario usando le istruzioni in . 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. L' Hosting In Scatola 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 in per una più dettagliata discussione e per i vantaggi e svantaggi degli hosting in scatola e per un elenco di siti che lo offrono. Scegliere una Licenza e Applicarla Questa sezione vuol essere guida molto una veloce, molto scarna alla scelta di una licenza. Leggete per capire le implicazioni dettagliate di differenti licenze e come la licenza che scegliete possa avere ripercussioni sulla possibilità per la gente di mescolare il vostro software con altri software liberi. C'è un gran numero di licenze fra cui scegliere. Non avete da prendere in considerazione molte di esse ora, dal momento che esse sono state scritte per soddisfare le esigenze legali di qualche grossa impresa o persona, e non sarebbe adatta per il vostro progetto. Restringeremo il campo solo alle più comuni licenze; nella maggior parte dei casi, voi vorrete scegliere una di esse. Le Licenze “Fai Tutto” Se vi fa comodo che il vostro progetto possa essere potenzialmente usato in programmi proprietari allora usate una licenza MIT/X-style. E' la più semplice delle licenze minimali che fanno poco più che affermare un diritto di copyright (senza nei fatti limitare la copia) e specifica che il codice arriva senza garanzia. Vedere per i dettagli. La GPL Se non volete che il vostro codice sia usato in software proprietari usate la GNU General Public License (). La GPL è probabilmente la più largamente apprezzata licenza nel modo oggi. Questo è già in se stesso un grosso vantaggio, perchè molti utilizzatori e collaboratori saranno già familiari con essa e quindi non avranno a spendere un tempo extra per comprendere la vostra licenza. Vedere in per i dettagli. Se gli utilizzatori interagiscono col vostro codice principalmente su un network—cioè, se il software è usualmente parte di un servizio su hosting—allora considerate la possibilità di usare invece la GNU Affero GPL. Vedere in per maggiori dettagli. Come Applicare Una Licenza Al Vostro Software Dopo aver scelto una licenza dovreste dichiararla nel pagina principale del progetto. Non c'è bisogno che includiate il vero testo della licenza lì; date solo il nome della licenza e create un link che porti al testo intero della licenza in un'altra pagina. Questo dice al pubblico sotto quale licenza volete che il software sia rilasciato, ma non è sufficiente ai fini legali. Per questo il software stesso deve contenere la licenza. Il classico modo di fare ciò è quello di mettere la intera licenza in un file chiamato COPYING (o LICENSE), e poi mettere una piccola nota in testa ad ogni file sorgente indicante la data del copyright, il proprietario, e la licenza e indicante dove trovare il testo intero della licenza. Ci sono molte varianti a questo percorso, sicchè voi vedrete giusto un esempio qui. La GNU GPL dice di mettere una nota come questa in testa ad ogni file sorgente: Copyright (C) <anno> <nome dell'autore> Il programma è un software libero; potete redistribuirlo e/o secondo i termini della come pubblicato dalla Free Software Foundation; sia la versione 2, sia (a vostra scelta) ogni versione successiva. Questo programma è distribuito nella speranza che sia utile ma SENZA ALCUNA GARANZIA; senza anche l'implicita garanzia di POTER ESSERE VENDUTO o di IDONEITA' A UN PROPOSITO PARTICOLARE. Vedere la GNU General Public License per ulteriori dettagli. Dovreste aver ricevuto una copia della GNU General Public License in questo programma; se non l'avete ricevuta, scrivete alla Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Non si dice specificatamente che la copia della licenza che avete ricevuto col programma è nel file COPYING ma che è messa usualmente lì. (Potete cambiare la nota precedente per stabilire ciò completamente.) Questo modello dà anche un indirizzo geografico dal quale richiedere una copia della licenza Un altro sistema comune è quello di dare il link alla pagina in cui si trova la licenza. Usate il vostro giudizio e puntate dove voi credete sia aggiornata la copia più stabile della licenza. Che potrebbe essere semplicemente da qualche parte del sito del progetto. In generale la nota che mettete in ogni file sorgente non deve apparire esattamente come quella di sopra, a condizione che inizi con la nota del detentore del copyright e della data, stabilisca il nome della licenza, e chiarisca dove poter vedere l'intera licenza. Dare il Tono Fin qui abbiamo esaminato il compiti che non ripetuti che voi assolvete durante l'organizzazione di un progetto: scegliere una licenza, mettere e posto il sito iniziale, ecc.. Ma gli aspetti più importanti dell'avvio di un nuovo progetto sono dinamici. Scegliere l'indirizzo della mailing list è facile; assicurarsi che le conversazioni nelle lista rimangano in argomento e siano produttive è completamente un'altra cosa. Se il progetto sta per essere aperto dopo anni di chiusura, di sviluppo in casa, il suo processo di sviluppo cambierà e voi dovrete preparare gli sviluppatori per questo cambiamento. I primi passi sono i più difficili perchè i diritti comuni e le aspettative per una condotta futura non sono stati ancora stabiliti. La stabilità per un progetto non viene da linee di condotta formali, ma da una saggezza condivisa difficile-da-definire che si sviluppa nel corso del tempo. Ci sono spesso regole scritte, ma esse tendono ad essere essenzialmente un distillato degli intangibile sempre evolventisi accordi che veramente guidano il progetto. Le linee di condotta scritte non definiscono la cultura del progetto finchè lo descrivono, e anche allora lo fanno solo approssimativamente. Ci sono poche ragioni per le quali le cose trovano una soluzione in questo modo. La crescita e il grande cambiamento non sono così dannosi per l'accumulazione di norme sociali come uno potrebbe pensare. Finchè i cambiamenti non avvengono troppo rapidamente, c'è tempo per in nuovi arrivati di imparare come vanno fatte le cose, e dopo che hanno imparato, contribuiranno a rafforzare quei modi stessi. Considerate come le canzoni dei bambini sopravvivono nei secoli. Ci sono bambini oggi che cantano le stesse rime che i bambini cantavano centinaia di anni fa, anche se ora non ci sono bambini vivi che erano vivi allora. I bambini più giovani sentono le canzoni dai più vecchi e quando sono più vecchi, a loro volta le canteranno davanti ai più giovani. I bambini non si impegnano in un consapevole programma di trasmissione, certamente, ma il motivo per cui le canzoni sopravvivono è tuttavia il fatto che esse vengono trasmesse regolarmente e ripetutamente. La scala di tempo dei progetti di software libero non può essere misurata in secoli (non lo sappiamo ancora), ma le dinamiche della trasmissione sono le stesse. La velocità del cambiamento è molto alta, comunque, e può essere compensata da uno impegno nella trasmissione più attivo e intenzionale. Questo impegno è favorito dal fatto che la gente generalmente evidenzia aspettativa e ricerca di norme sociali. Ed e proprio così che la gente è fatta. In un gruppo unificato dall'impegno comune, la gente che si unisce istintivamente ricerca comportamenti che li segnalerà come parte del gruppo. L'obiettivo di stabilire diritti comuni prima è quello di fare in modo che questi comportamenti “in gruppo” siano gli unici utili al progetto. Una volta stabiliti essi si auto- perpetueranno in gran parte. Seguono alcuni esempi di cose specifiche che voi potete fare per stabilire buoni diritti comuni. Essi non sono interpretati come un elenco esaustivo, giusto come illustrazioni dell'idea che stabilire un modo collaborativo in principio favorisce un progetto moltissimo. Fisicamente ogni sviluppatore può essere al lavoro da solo in una stanza, ma voi potete fare molto perchè egli si senta come se stesse lavorando insieme agli altri in una sola stanza. Più essi avvertiranno ciò più vorranno spendere tempo per il progetto. Scelgo questi particolari esempi perchè essi si presentarono nel progetto di Subversion(), al quale io partecipai e osservai in esso all'inizio. Ma essi non sono singolari della Subversion; situazioni come queste si presentano in molti progetti open source, e dovrebbero essere viste come opportunità per iniziare a fare le cose col piede giusto. Evitare discussioni private Anche dopo che avrete reso pubblico il progetto voi e gli altri fondatori vi troverete spesso desiderosi di sistemare difficili questioni con comunicazioni private in un ambiente più ristretto. Ciò è specialmente vero nei primi giorni del progetto quando ci sono tante decisioni da prendere, e, usualmente, pochi volontari qualificati per prenderle. Tutti gli ovvi svantaggi delle discussioni in liste pubbliche appariranno palpabili davanti a voi. Il ritardo connesso con le conversazioni per email, il bisogno di avere sufficiente tempo perchè si formi il consenso, il fastidio della negoziazione con volontari sprovveduti che ritengono di capire tutti i problemi, ma in realtà non lo fanno (ogni progetto li ha; a volte essi sono collaboratori protagonisti dell'anno prossimo, a volte restano sprovveduti per sempre), le persone che non riescono a capire che voi volete solo risolvere il problema X anche se questo è ovviamente un aspetto del problema più generale. E così via. La tentazione di prendere decisioni a porte chiuse e di presentarle a loro come a fatti compiuti, o almeno come i fermi consigli di un blocco votante unito e influente, sarà grande indubbiamente. Non fatelo. Per quanto lente e scomode possano essere le discussioni pubbliche, esse sono quasi sempre preferibili a lungo andare. Rendere private importanti discussioni è come dipingere il collaboratore come repellente per il vostro progetto. Nessun serio volontario resterebbe a lungo nei paraggi di un ambiente in cui tutte le grosse decisioni vengono prese in un consiglio segreto. Inoltre le discussioni pubbliche hanno il benefico effetto secondario che sopravviveranno per quanto effimera fosse la la questione tecnica in discussione: La discussione favorirà l'addestramento e l'educazione dei nuovi sviluppatori. Voi non sapete mai quanti occhi sono attenti alla conversazione; anche se la maggioranza della gente non parteciperà, molti seguiranno in silenzio racimolando informazioni sul software. nell'arte di spiegare le questioni a persone che non hanno familiarità con le questioni tecniche come l'avete voi. Questa è una capacità che richiede pratica, e voi non potete acquisire questa pratica parlando a gente che già sa quello che sapete voi. La discussione e le sue conclusioni saranno disponibili nel pubblico archivio per sempre dopo, dando la possibilità alle future discussioni di evitare di rifare gli stessi passi. Vedere in . Infine, c'è la possibilità che qualcuno nella lista possa dare un reale contributo alla conversazione col far sorgere un'idea che voi non vi sareste mai aspettati. E' difficile dire quanto questo sia possibile. Dipende dalla difficoltà del codice e dal grado specializzazione richiesta. Ma se è permessa una evidenza annedotica, io azzarderei che questo è più probabile di quanto uno si aspetterebbe intuitivamente. Nel progetto di Subversion, noi (i fondatori) eravamo di fronte a una profonda e complessa serie di problemi ai quali stavamo pensando con difficoltà per molti mesi e francamente dubitavamo che ognuno sulla mailing list da poco creata potesse dare un contributo effettivo alla discussione. Così prendemmo pigramente la via e incominciammo a battere su idee tecniche avanti e indietro in emails private finchè uno che osservava il progetto Non siamo ancora arrivati alla sezione dei crediti, ma giusto alla pratica che io sosterrò più tardi: il nome dell'osservatore era Brian Behlendorf, e fu lui che richiamò l'attenzione sull'importanza di mantenere le discussioni pubbliche, amenochè non ci fosse uno specifico bisogno di privatezza. ebbe il sentore di quello che stava avvenendo e chiese che la discussione fosse spostata su una mailing list pubblica. Roteando un poco gli occhi, lo facemmo e fummo stupiti dai commenti perspicaci e dai suggerimenti che presto ne vennero. In molti casi le persone fornirono idee che non ci erano mai venute in mente. Ciò dimostrò che c'erano persone molto acute nella mailing list. Esse stavano solo aspettando si essere correttamente allettate. E' vero che le discussioni che ne vennero fuori furono più lunghe di quanto lo sarebbero state se la conversazione fosse stata tenuta privata, ma esse furono talmente molto più costruttive che fu un valore il tempo in più. Senza scendere in generalizzazioni tipo “il gruppo è sempre più acuto dell'individuo” agitando le mani (noi tutti abbiamo incontrato abbastanza i gruppi per saperlo piuttosto bene), deve darsi per acquisito che ci sono certe attività in cui il gruppo eccelle. La valutazione professionale del lavoro dei colleghi è una di queste; la produzione veloce di un gran numero di idee è un'altra. La qualità delle idee dipende dalla quantità del pensare che è entrato in esse, certo, ma voi non saprete che genere di pensatori è sbocciato lì finchè non li stimolerete con un problema impegnativo. Naturalmente ci sono discussioni che devono avvenire in privato. In questo libro ne vedrete esempi. Ma la guida dovrebbe essere sempre: Se non c'è ragione perchè esse siano essere private, dovrebbero essere pubbliche. Far si che questo accada richiede un'azione. Non c'è solo da assicurarsi che i vostri posts vadano nella lista pubblica. Dovete anche richiamare l'attenzione della altre persone sul fatto che inutili conversazione private vadano anche sulla lista. Se qualcuno tenta di avviare una conversazione privata, e non c'è ragione perchè essa sia privata, allora il vostro compito è quello di aprire immediatamente la relativa discussione pubblica appropriata. E anche non commentate sull'argomento originale finchè o avete condotto la conversazione in un alveo pubblico, o avete accertato che la privacy era necessaria. Se fate ciò con coerenza, le persone afferreranno abbastanza velocemente e incominceranno ad usare i forums per abitudine. Stroncate sul Nascere la Scortesia Stroncate sul nascere la scortesia. Dall'inizio dell'esistenza del vostro progetto dovreste mantenere una politica di tolleranza-zero verso comportamenti scortesi o offensivi nei suoi forums. Tolleranza-zero non significa forzatura tecnica di per se. Non dovete rimuovere le persone dalla mailing list quando offendono un altro iscritto o impedire loro la possibilità di inserire messaggi perchè hanno fatto commenti sprezzanti. (In teoria potreste alla fine far ricorso a tale azione, ma solo dopo che le altre vie hanno fallito—cosa che, per definizione non è il caso dell'avvio del progetto.) Tolleranza-zero semplicemente significa non permettere che cattivi comportamenti passino inosservati. Per esempio quando qualcuno posta un commento tecnico insieme ad un attacco personale a qualche altro sviluppatore nel progetto, è imperativo che voi rispondiate a questo attacco personale prima, come problema separato in se stesso, e solo dopo passiate al contenuto tecnico. Sfortunatamente è molto facile e troppo tipico, che discussioni costruttive scadano in distruttive guerre offensive. Le persone diranno cose per email che non avrebbero mai detto faccia-a-faccia. L'argomento della discussione però amplifica questo effetto: nei problemi tecnici, le persone spesso pensano che ci sia una sola risposta giusta a molte domande, e che il disaccordo con quella risposta possa essere spiegato come ignoranza o stupidità. Il tratto è breve fra il chiamare la proposta di qualcuno stupida e il chiamare la persona stessa stupida. Infatti, spesso è difficile dire dove si lascia il dibattito e incomincia l'attacco al carattere, che è una ragione per cui reazioni drastiche o punizioni non sono una buona idea. Invece, quando pensate di vedere che questo sta succedendo inserite un post che metta l'accento sull'importanza di mantenere la discussione amichevole, senza accusare nessuno di essere deliberatamente velenoso. Tali posts di ”Politica Simpatica” hanno una sfortunata tendenza a suonare come una ramanzina a una classe di bambini sul buon comportamento:
Prima prego limitiamoci ai (potenziali) commenti sulla persona; per esempio, il definire il progetto di J sul livello di sicurezza “ingenuo e ignorante dei principi base della sicurezza del computer.” Ciò può essere vero o no, ma in ogni caso non è un modo con il quale si ha la discussione. J ha fatto la sua proposta in buona fede. Se questa ha delle manchevolezze facciamole notare, e noi le correggeremo o troveremo un altro abbozzo. Io sono sicuro che M non volesse insultare personalmente J, ma il modo di parlare non ha avuto fortuna, e cerchiamo di mantenere le cose costruttive qui da noi. Ora sulla proposta. Penso che M avesse ragione quando diceva...
Per quanto artificiose suonino queste reazioni, esse hanno un notevole effetto. Se voi costantemente gridate i cattivi comportamenti, ma non chiedete le scuse o una ammissione da parte di chi offende, allora voi lasciate le persone libere di raffreddarsi e di mostrare il lato migliore col comportarsi meglio la volta successiva—ed essi lo faranno. Uno dei segreti per fare ciò con successo è non trasformare la pseudo discussione nell'argomento principale. Ci dovrebbe essere sempre una breve prefazione a parte, alla parte principale della vostra risposta. Fate notare, incidentalmente, che “non facciamo le cose in questo modo qui da noi”, ma poi andate al reale contenuto in modo tale da dare alle persone qualcosa in argomento su cui rispondere. Se qualcuno obbietta che non merita il vostro rimprovero, rifiutatevi semplicemente di essere condotti sull'argomento. O non rispondete (se pensate che essi si stiano giusto sfogando e non richiedono una risposta), oppure dite che vi dispiace se avete reagito in modo esagerato e che è difficile distinguere le sfumature per email, quindi ritornate all'argomento principale. Mai, mai insistere su una ammissione, pubblica o privata, da parte di qualcuno che si è comportato in modo scorretto. Se essi da sé scelgono di postare delle scuse, ciò è una gran cosa, ma pretendere che lo facciano causerà solo risentimento. L'obiettivo primario è far si che la buona etichetta sia visto come l'unico comportamento “in-gruppo”. Ciò aiuta il progetto, perchè gli sviluppatori possono essere allontanati (anche da progetti che essi amano e vogliono sostenere) da guerre di offese. Voi potete anche non sapere che essi si sono allontanati; qualcuno potrebbe anche nascondersi nella mailing list, vedere che si fa la pelle dura a partecipare al progetto, e decidere invece di essere coinvolto del tutto. Mantenere il forum confidenziale è una strategia di sopravvivenza, ed è più facile da attuarsi quando il progetto è ancora giovane. Una volta che ciò è parte della cultura, voi non dovrete essere la sola persona a a promuoverlo. Sarà mantenuto da ciascuno. Praticare una Visibile Revisione del Codice Uno dei migliori modi di allevare una comunità di sviluppo è il fatto di ottenere che le persone guardino il codice uno dell'altro. E' richiesta una qualche infrastruttura per consentire ciò effettivamente—in particolare, devono essere abilitate email di invio; vedere per maggiori dettagli. L'effetto delle email di invio è che ogni volta che uno invia un cambiamento al codice sorgente viene emessa una email che mostra una messaggio di log e le differenze per il cambiamento (vedere , in ). La revisione del codice è la pratica di revisionare le emails di invio così come arrivano, cercando per bugs e possibili miglioramenti. Questo è il modo in cui vene realizzata la revisione del codice nei progetti open source, in ogni caso. In progetti più centralizzati “revisione del codice” può anche significare più persone che si siedono insieme per esaminare accuratamente una stampa del codice, per cercare specifici problemi e modelli. La revisione del codice serve a diversi scopi simultaneamente. E' il più chiaro esempio di revisione condivisa nel mondo dell'open source, e favorisce direttamente il mantenimento della qualità del software. Ogni bug che si imbarca in un pezzo di software è preso lì per essere stato inviato e non individuato; quindi più sono gli occhi e meno bugs si imbarcheranno. Ma la revisione del codice serve anche ad uno scopo indiretto: esso conferma alle persone che ciò che essi fanno è importante, perchè uno non impiegherebbe il tempo a revisionare un invio amenochè non gli interessasse il suo effetto. Le persone fanno il loro migliore lavoro quando sanno che gli altri impiegheranno del tempo per analizzarlo. Le revisioni dovrebbero essere pubbliche. Anche in occasioni in cui sono stato a sedere in una stanza fisica con sviluppatori, e uno di noi aveva fatto un invio, facevamo attenzione a non fare la revisione verbalmente nella stanza, ma invece la mandavamo alla mailing list dello sviluppo. Le persone seguono i commenti trovano difetti in essi, ed anche se non li trovano, ciò ricorda loro che la revisione è una attività prevista, regolare, come lavare i piatti, o tosare il prato. Nel progetto di Subversion noi all'inizio non avevamo la buona pratica della revisione del codice. Non c'era la garanzia che ogni invio sarebbe stato revisionato sebbene uno potesse dare un'occhiata a un cambiamento se era interessato a una particolare area di codice. I bugs in essa potevano e dovevano essere trovati. Uno sviluppatore chiamato Greg Stein che conosceva il valore della revisione del codice per passati lavori decise di andare a fare un esempio revisionando ogni linea di ogni singolo invio che andava nel deposito degli invii. Ogni invio che ognuno faceva veniva immediatamente seguito da un'email alla lista degli sviluppatori da Greg, che parlava dell'invio, analizzava i possibili problemi, e occasionalmente esprimeva lode su un pezzo intelligente di codice. Subito, egli trovava bugs o pratiche non ottimali di scrivere il codice che diversamente sarebbero passate inosservate. Apparentemente egli non si lamentava di essere l'unica persona che revisionava ogni invio, anche se impiegò una gran parte del suo tempo, ma cantò le lodi delle revisione del codice ogni volta che ne ebbe l'occasione. Molto presto, altre persone, me incluso, incominciarono a revisionare gli invii con regolarità. Quale era la nostra motivazione? Non era che Greg consapevolmente ci avesse rimproverati per farlo. Ma egli aveva provato che la revisione del codice era un modo prezioso di spendere il tempo, e che uno avrebbe contribuito tanto al progetto sia revisionando i cambiamenti degli altri, sia scrivendo nuovo codice. Dopo che egli dimostrò ciò, questo diventò il comportamento scontato, al punto che ogni invio che non riceveva una reazione faceva preoccupare chi lo aveva effettuato, e lo induceva anche a chiedere alla lista se qualcuno tuttavia avesse avuto l'occasione di revisionarlo. Più tardi Greg prese un lavoro che non gli lasciò tanto tempo per Subversion, e dovette finire di fare revisioni con regolarità. Ma, da allora, l'abito si radicò a tal punto per il resto di noi che sembrò che continuasse da tempo immemorabile. Incominciate a fare revisioni sin dal primo invio. Il tipo di problemi più facili da incontrare nella revisione delle differenze sono le vulnerabilità nella sicurezza, falle nella memoria, i commenti insufficienti o l'insufficiente documentazione, gli errori logici in una iterazione, la discordanza di disciplina chiamante/chiamato, e altri problemi che richiedono un minimo di contesto intorno da vedere. Comunque anche problemi su larga scala come i fallimenti nell'estrarre procedure ripetute in una locazione diventano osservabili dopo che una ha fatto la revisione regolarmente, perchè la memoria di passate differenze avverte sulle differenze presenti. Non vi spaventate se non trovate niente da commentare, o se non conoscete ogni area di codice. Usualmente ci sarà qualcosa da dire su quasi ognuno degli invii; anche dove non trovate niente da chiedere, potete trovare qualcosa da apprezzare. L'importante è che sia chiaro a ogni persona che fa un invio che ogni cosa che fa è visto e capito. Certo, la revisione del codice non libera i programmatori dalla responsabilità di rivedere il proprio codice prima di inviarlo. Nessuno dovrebbe dipendere dalla revisione del codice per individuare cose che dovrebbe individuare da sé. Quando Aprite un Progetto che era Chiuso in Passato Fate Attenzione alla Grandezza del Cambiamento Se state aprendo un progetto esistente, un progetto che ha già sviluppatori attivi abituati a lavorare in un ambiente closed-source, assicuratevi che ognuno capisca che sta venendo un grosso cambiamento, e assicuratevi di capire come ciò sta venendo percepito dal loro punto di vista. Cercate di capire come la situazione appare loro: in passato, tutte le decisioni riguardanti il codice e la progettazione venivano prese in un gruppo di programmatori che conoscevano il software più o meno bene in modo uguale, in cui tutti ricevevano le stesse pressioni dalla stessa organizzazione, e in cui tutti conoscevano la forza e le debolezze degli altri. Adesso voi state chiedendo loro di esporre il loro codice allo sguardo indagatore di casuali estranei, che si formeranno un giudizio solo sul codice, con nessuna consapevolezza di quante pressioni mercantili possono aver forzato certe decisioni. Questi estranei faranno un sacco di domande, domande che turberanno gli sviluppatori preesistenti fino al punto che essi si renderanno conto che la documentazione sulla quale hanno sgobbato è tuttavia inadeguata (questo è inevitabile). E per giunta, i nuovi arrivati sono sconosciuti, entità anonime. Se uno dei vostri sviluppatori non si sente sicuro riguardo alle sue capacità, immaginate come questa cosa si inasprirà quando i nuovi arrivati faranno notare gli errori nel codice che ha scritto, e peggio, lo faranno davanti ai suoi colleghi. Amenoché voi non abbiate un team di perfetti svilippatori, questo è inevitabile—infatti ciò accadrà probabilmente a tutti loro all'inizio. Ciò non avviene perchè essi siano dei cattivi programmatori; avviene giusto che ogni programma al di sopra di una certa grandezza ha bugs, ed ogni revisione alla pari evidenzierà alcuni di questi bugs (vedere prima in questo capitolo ). Allo stesso tempo, il nuovo arrivato stesso non sarà soggetto a molte revisioni alla pari all'inizio, perchè non può contribuire al codice finchè non familiarizza col progetto. Ai vostri sviluppatori potrà sembrare che tutto il criticismo sta arrivando e non andando via. Così c'è il pericolo che una mentalità di assedio assuma il controllo fra i vecchi sviluppatori. Il miglior modo per prevenire ciò è mettere in guardia ciascuno su ciò che sta venendo, spiegarlo, dire loro che lo sconforto iniziale è perfettamente normale, e rassicurarli che sta per andare meglio. Alcuni di questi preavvisi dovrebbe aver luogo in privato, prima che il progetto venga aperto. Ma potete anche trovare utile ricordare alle persone sulle liste pubbliche che questo è un nuovo modo di sviluppare nel progetto, e che ci vorrà un pò di tempo per adattarsi. La miglior cosa che voi possiate fare è guidare con l'esempio. Se vedete che i vostri sviluppatori non rispondono a sufficienza alle domande dei novizi, allora il dire loro di rispondere meglio, non è utile. Può darsi che essi non abbiano ancora una buona idea di ciò che garantisce una reazione e di ciò che non lo fa, o potrebbe darsi che essi non abbiano idea di quanto privilegiare il codice nei confronti del nuovo carico della comunicazione esterna. Il miglior modo di farli partecipare è partecipare voi stessi. Essere sulle mailing lists e accertarsi di rispondere ad alcune domande lì. Quando non avete l'esperienza per rispondere abilmente a una domanda, allora passate in maniera visibile la palla a uno sviluppatore che lo faccia, e assicuratevi che egli dia una risposta, o almeno che abbia una reazione. Ci sarà naturalmente la tentazione per lungo tempo di abbandonarsi a discussioni private, poiché quello era ciò a cui erano abituati. Assicuratevi di essere iscritti alle mailing lists interne in cui ciò può avvenire, dimodochè possiate chiedere che tali discussioni siano spostate sulle liste pubbliche immediatamente. Ci sono altre attività a lungo termine relative all'apertura di un progetto precedentemente chiuso. esamina tecniche per mettere insieme con successo sviluppatori pagati e non pagati, e tratta della necessità di una osservanza del termini legali quando si apre un codice base privato che può essere stato scritto o “posseduto” da altre parti. L'Annuncio Una volta che il progetto è presentabile— non perfetto, giusto presentabile— siete proti per annunciarlo al mondo. Questo è in realtà un procedimento molto semplice: andate a , cliccate su Invio in cima alla barra di navigazione e riempite un form che annuncia il vostro nuovo progetto. Freshmeat è il posto in cui chiunque guarda per annunci di nuovi progetti. Dovete solo prendere alcune opinioni lì sul vostro progetto da diffondere a voce. Se conoscete mailing lists o newsgroups dove un annuncio del vostro progetto sarebbe in argomento e di interesse, allora postate lì, ma con l'attenzione di inserire esattamente un solo post per forum, e di indirizzare le persone ai forums del vostro progetto come seguito della discussione (impostando l'intestazione Risposta-a). I post dovranno esse brevi e andare giusto al punto: A: discuss@lists.example.org Soggetto: [ANN] Progetto Scanley di indicizzatore full-text Risposta-a: dev@scanley.org Questo è il post di una volta che annunciava la creazione del progetto Scanley, un progetto di indicizzazione full-text e di strumento di ricerca con una ricca API, ad uso dei programmatori nel fornire dei servizi di ricerca per un grande insieme di files di testo. Scanley attualmente è un codice che gira, è sotto sviluppo attivo, ed è alla ricerca sia di sviluppatori, sia di collaudatori. Home page: http://www.scanley.org/ Funzionalità: - Ricerche testo normale, HTML, e XML - Ricerca di parole o frasi - (pianificato) Ricerca diffusa - (pianificato) Aggionamento incrementale degli indici - (pianificato) Indicizzazione di siti remoti Requisiti: - Python 2.2 o superiore - Spazio su disco sufficiente a supportare gli indici (approssimativamente 2x la grandezza originale dei dati) Per maggiori informazioni venire su scanley.org. Grazie, -J. Random (Vedere in per avvisi o per annunci di ulteriori releases o di altri eventi del progetto.) C'è in corso un dibattito nel mondo del software libero se incominciare col far girare il codice, o se il progetto può beneficiare dall'essere aperto anche durante la fase di progettazione/discussione. Io ero abituato a pensare che partire con il codice che gira fosse il fattore più importante, che esso fosse ciò che separa i progetti di successo dai giochi, e che gli sviluppatori seri sarebbero stati attratti da software che facesse già qualcosa di concreto. Questo si dimostrò non essere il caso. Nel progetto di Subversion, noi partimmo con un documento di progetto, un cuore di sviluppatori interessati e ben collegati, un sacco di fanfara, e un codice che non girava affatto. Con mia totale sorpresa, il progetto acquisì principianti attivi giusto dall'inizio, e col tempo avemmo qualcosa che girava, c'erano parecchi sviluppatori profondamente coinvolti. Subversion non è il solo esempio; il progetto Mozilla fu lanciato senza codice che girava, ed è ora un browser popolare e di successo. Di fronte a una tale evidenza, dovetti fare marcia indietro sull'affermazione che far girare il codice fosse assolutamente necessario per lanciare un progetto. Far girare il codice è ancora la migliore premessa per il successo, e una buona regola empirica approssimativa sarebbe aspettare di farlo girare prima di annunciare il vostro progetto. Comunque ci sono circostanze in cui fare l'annuncio presto ha un senso. Penso che almeno un documento di progetto ben sviluppato, o diversamente una sorta di struttura di codice sia necessaria—certamente può essere rivista basandosi su una pubblica risposta, ma ci deve essere qualcosa di concreto, qualcosa di più tangibile oltre a delle sole buone intenzioni, affinchè le persone possano affondarvi i denti. In qualsiasi momento facciate l'annuncio, non aspettatevi che un'orda di volontari si aggiungano al progetto. Usualmente, il risultato dell'annuncio è che voi ricevete poche domande casuali, e inoltre poche persone si aggiungono alle vostre mailing lists, e a parte questo, ogni cosa continua ad andare abbastanza come prima. Ma col tempo, noterete un graduale aumento nella partecipazione sia di collaboratori al nuovo codice sia di utilizzatori. L'annuncio è solo un piantare il seme. Ci può essere bisogno di molto tempo perchè la notizia si diffonda. Se il progetto coerentemente ricompensa coloro che sono coinvolti, le notizie si diffonderanno, comunque, perchè le persone vogliono condividere quando hanno trovato qualcosa di buono. Se tutto va bene, le dinamiche di reti di comunicazione esponenziali trasformeranno lentamente il progetto in una complessa comunità, in cui non dovete conoscere necessariamente il nome di ciascuno, e non potete seguire ogni singola conversazione. I prossimi capitoli parlano del lavoro in questo ambiente.