Il prezzo della crescita è pesante nel mondo dell'open source. Come il vostro software diventa più popolare, il numero di persone che compaiono alla ricerca di informazioni cresce in modo sensazionale, mentre il numero delle persone in grado di dare le informazioni cresce molto meno lentamente. Inoltre, anche se il rapporto fosse uniformemente bilanciato, ci sarebbe tuttavia un problema fondamentale di scalabilità col modo in cui la maggior parte dei progetti open source gestiscono le comunicazioni. Considerate le mailing list, per esempio. La maggior parte dei progetti hanno una mailing list per le domande degli utilizzatori generici—a volte il nome delle mailing list è “utilizzatori”, “discutere”, “aiuto”, o qualcos'altro. Qualunque sia il nome, il proposito della mailing list è sempre lo stesso: fornire un posto dove la gente possa ricevere risposta alle sue domande, dove gli altri osservano e (presumibilmente) assorbono conoscenze dall'osservazione di questi scambi.
Queste mailing list funzionano molto bene fino a poche migliaia di utilizzatori e/o fino a un paio di centinaia di post al giorno. Ma circa dopo di ciò il sistema incomincia a collassare, perché ogni iscritto vede ogni post. Se il numero dei post alla mailing list incomincia a superare quello che ogni singolo lettore può elaborare in un giorno, la mailing list diventa un carico per i suoi membri. Immaginate, per esempio, che Microsoft abbia una tale mailing list per Windows XP. Windows XP ha centinaia di milioni di utenti; se anche un decimo dell'1% ha domande in un periodo di ventiquattrore, allora questa ipotetica mailing list riceverebbe centinaia di migliaia di post al giorno! Una tale mailing list non potrebbe mai esistere, perché nessuno vorrebbe rimanere iscritto ad essa. Questo problema non è limitato alle mailing list; la stessa logica si applica ai canali IRC, ai forum di discussioni online, indubbiamente ad ogni sistema in cui un gruppo ascolta domande dagli individui. Le implicazione sono sinistre: l'usuale modello open source di supporto in parallelo di massa non si adegua ai livelli necessari per la dominazione del mondo.
Non ci sarà nessuna esplosione quando il forum raggiungerà il punto di rottura. Ci sarà solo un silenzioso effetto di reazione negativa: la gente si cancella l'iscrizione dalle mailing lists, o lascia il canale IRC, o in ogni caso smette di infastidire facendo domande, perché possono vedere che non saranno ascoltati in tutto il rumore. Nella misura in cui sempre più la gente fa questa scelta altamente razionale, l'attività dei forum sembra restare in un livello manovrabile. Ma esso rimane in un livello manovrabile precisamente perché la gente razionale (o almeno con esperienza) ha incominciato a guardare altrove per le informazioni—mentre la gente inesperta rimane dentro e posta continuamente. In altre parole, l'effetto a senso unico di continuare a usare modelli di comunicazioni non ampliabili quando il progetto cresce è quello che la qualità delle domande e delle risposte tende a scendere, il che fa sembrare che i nuovi utilizzatori sono più muti di quanto erano soliti essere, mentre nei fatti probabilmente non lo sono. E' solo che il rapporto beneficio/costo dell'usare questi forums ad alta popolazione scende, così naturalmente quelli con esperienza incominciano per primi a guardare altrove per le risposte. Adattare il meccanismo delle comunicazioni in modo che faccia fronte alla crescita del progetto quindi comporta due strategie:
Riconoscere quando parti particolari di un forum non stanno soffrendo la crescita illimitata, anche se il forum nella sua interezza la sta soffrendo, e separare quelle parti per creare dei nuove forum specializzati (cioè non permettete che il buono sia trascinato in basso dal cattivo).
Assicurarsi che ci siano fonti di informazione automatizzate disponibili, e che siano mantenute organizzate, aggiornate, e facili da trovare.
La strategia (1) non è difficile di solito. La maggior parte dei progetti partono con un solo forum principale: una mailing list di discussioni generali, nella quale possono essere discussi idee di funzionalità, questioni di progettazione, e problemi di codice. Chiunque sia coinvolto nel progetto è nella mailing list. Dopo un po', di solito diventa chiaro che la mailing list si è evoluta in varie sotto mailing list distinte basate sull'argomento. Per esempio, alcune discussioni sono chiaramente sulla progettazione e sullo sviluppo; altre sono domande degli utilizzatori della varietà “Come faccio X”; può darsi che ci sia una terza famiglia di argomenti centrati sull'elaborazione dei report di bug e su richieste di accrescimento; e così via. Un dato individuo, certo, potrebbe partecipare a molti differenti tipi di discussioni, ma la cosa importante è che non ci sia una grande quantità di sovrapposizioni fra i tipi stessi. Essi potrebbero essere suddivisi in mailing list separate senza causare una pericolosa balcanizzazione, perché le discussioni raramente attraversano i limiti dell'argomento.
In realtà fare queste divisioni è un processo in due tempi. Voi create la nuova mailing list (o il canale IRC, o qualunque altra cosa sia) e poi spendete quanto tempo sia necessario nel rimproverare e nel ricordare alla gente di usare appropriatamente i nuovi forum. Il secondo passo può durare settimane, ma alla fine la gente si farà l'idea. Voi dovete semplicemente considerare importante dirlo a chi invia che il post è stato inviato alla destinazione sbagliata, e farlo in modo visibile, in modo che gli altri siano incoraggiati ad essere di aiuto nell'instradamento. E' anche utile avere una pagina web che fornisca una guida a tutte le mailing list disponibili; la vostra risposta può far riferimento a quella pagina web e, come premio, il destinatario può imparare qualcosa sul cercare nelle linee guida prima di postare.
La strategia (2) è un processo continuo che dura il tempo di vita del progetto e coinvolge molti partecipanti. Certo è in parte questione di avere la documentazione aggiornata (vedere sezione chiamata «La documentazione» in Capitolo 2, Partenza) e assicurarsi di indirizzare la gente lì. Ma è anche molto più di questo; le sezioni che seguono discuteranno questa strategia in dettaglio.
Tipicamente tutte le comunicazioni in un progetto open source (eccetto talvolta le conversazioni IRC) vengono archiviate. Gli archivi sono pubblici e vi si possono fare ricerche, e hanno una stabilità informativa: cioè, una volta che un dato pezzo di informazione è registrato in un particolare indirizzo, rimane in quell'indirizzo per sempre.
Usate questi archivi quanto più è possibile, e quanto più in modo visibile possibile. Anche quando sapete la risposta spontanea a qualche domanda, se pensate che c'è un riferimento nell'archivio che contiene la risposta, spendete tempo a riportarla alla luce e fornitela. Ogni volta che fate ciò in modo visibile, qualche persona imparerà che ci sono gli archivi lì, e che cercare in essi può produrre risposte. Anche, riferendovi agli archivi invece di riscrivere il consiglio, rafforzate una norma sociale contro la duplicazione delle informazioni. Perché avere la stessa risposta in due posti differenti? Quando il numero di posti in cui essa può essere trovata è tenuto al minimo, le persone che le hanno trovate prima è molto probabile che ricordino cosa cercare per trovale di nuovo. Riferimenti ben collocati, possono anche contribuire alla qualità dei risultati della ricerca in generale, perchè essi rafforzano il ranking della risorsa obiettivo nei motori di ricerca di Internet.
Ci sono volte in cui la duplicazione delle informazioni ha senso, comunque. Per esempio, supponete che ci sia già una risposta negli archivi, non vostra, che dice:
Pare che in vostri indici di Scanley si siano imbrogliati. Per ripararli fate questi passi: 1. Spegnete il server di Scanley. 2. Fate girare il programma 'sbroglia' che si carica con Scanley. 3. Avviate il server.
Allora, mesi dopo, vedete un altro post che indica che gli indici di qualcuno si sono imbrogliati. Cercate negli archivi e vien fuori la vecchia risposta di sopra, ma vi rendete conto che sono mancanti alcuni passi (forse per errore, o perché il software è cambiato da quando quel post fu scritto). Il modo classico di gestire ciò è postare un nuovo, più completo set di istruzioni, e rendere obsoleto il vecchio post menzionandolo:
Pare che in vostri indici di Scanley si siano imbrogliati. Vedemmo questo problema nel lontano Luglio, e J. Casuale postò una soluzione a http://blahblahblah/blah. Sotto c'è una completa descrizione di come sbrogliare i vostri indici, basata sulle istruzioni di J. Casuale ma che le estende un poco: 1. Spegnete il server di Scanley. 2. Diventate l'utilizzatore col quale il server di Scanley gira. 3. Come tale utilizzatore fate girare il programma 'sbroglia' per gli indici. 4. Fate girare Scanley a mano per vedere se gli indici funzionano ora. 5. Riavviate il server.
(In un mondo ideale, sarebbe possibile attaccare una nota al vecchio post, che dica che c'è una informazione più fresca e che punti al nuovo post. Comunque non so di un nuovo software per l'archiviazione che offra una funzionalità “obsoleto per”, forse perchè sarebbe leggermente complessa da implementarsi in un modo che non violi l'integrità dell'archivio in quanto registrazione parola per parola. Questa è un'altra ragione perché creare pagine dedicate con risposte alle domande comuni è una buona idea).
Negli archivi probabilmente si ricerca di più per risposte a domande tecniche, ma la loro importanza per i progetto va ben al di là di questo. Se le linee guida formali di un progetto sono la sua legge statutaria, gli archivi sono la sua legge comune: una registrazione di tutte le decisioni prese e di come sono arrivate là. In ogni discussione ricorrente è quasi obbligatorio oggigiorno partire con una ricerca nell'archivio. Questo ti permette di incominciare una discussione con un sommario dello stato corrente delle cose, di anticipare obiezioni, di preparare i rifiuti, e possibilmente di scoprire degli angoli a cui non avevate pensato. Anche, gli altri partecipanti si aspetteranno che abbiate fatto una ricerca nell'archivio. Anche se le discussioni precedenti non andarono da nessuna parte, voi dovreste includere dei puntatori ad esse quando balza si di nuovo l'argomento (così la gente può guardare da sé) che non a) andarono da nessuna parte e probabilmente diranno ora ciò che non è stato detto prima b) che voi avete fatto i vostri compiti, e quindi state probabilmente dicendo cose che non sono state dette prima.
Tutti i precedenti consigli si applicano a più che ai soli archivi delle mailing lists. L'avere particolari pezzi di informazione in stabili indirizzi che si possono trovare convenientemente dovrebbe essere un principio organizzativo di tutte le informazioni del progetto. Lasciatemi portare le FAQ del progetto come caso di studio.
Come la gente usa le FAQ?
Essi vogliono cercare in esse per parola e frase.
Essi vogliono guardarle per assorbire informazioni senza necessariamente guardare per risposte a domande specifiche.
Essi si aspettano dei motori di ricerca come Google per conoscere il contenuto delle FAQ, così le ricerche possono dar luogo a nuove voci nelle FAQ.
Essi vogliono essere in grado condurre altre persone direttamente a specifiche voci nelle FAQ.
Essi vogliono essere capaci di aggiungere materiale nuovo alle FAQ, ma notate che questo avviene molto meno spesso di quanto siano cercate le risposte—Le FAQ sono molto spesso più lette che scritte.
Il punto 1 implica che le FAQ dovrebbero essere disponibili in una sorta di formato testuale. I punti 2 e 3 implicano che le FAQ dovrebbero essere disponibili in una pagina Html, con il punto 2 che indica addizionalmente che l'Html dovrebbe essere creato per la leggibilità (cioè, vorrete qualche controllo sul loro aspetto e percezione), e dovrebbero avere una tavola dei contenuti. Il punto 4 significa che ad ogni nuova voce delle FAQ dovrebbe essere assegnata una ancora con nome, un tag che permette alla gente di raggiungere una particolare locazione nella pagina. Il punto 5 significa che i file sorgenti delle FAQ dovrebbero essere disponibili in un modo adatto (vedere sezione chiamata «Tenere tutto sotto controllo di versione» in Capitolo 3, L'Infrastruttura Tecnica ), in un formato che sia facile da editare.
Formattare così le FAQ è solo un esempio di come rendere presentabile una risorsa. La stesse qualità la ricerca diretta, la disponibilità nei principali motori di ricerca di Internet, la facilità di consultazione, la stabilità referenziale, a e (dove applicabile) l'editabilità—si applicano si applicano ad altre pagine web, all'albero del codice sorgente, al tracciatore di bug, ecc.. Appunto avviene che la maggior parte delle mailing list che archiviavano il software molto tempo fa si resero conto dell'importanza di queste qualità, che il motivo per cui le mailing list tendono ad avere queste funzionalità alla nascita, mentre altri formati possono richiedere qualche sforzo extra da parte di quelli che hanno la manutenzione (Capitolo 8, Gestire i Volontari discute come suddividere il carico della manutenzione fra molti volontari).
Nella misura in cui un progetto acquista anzianità e complessità, la quantità di dati che ogni partecipante che arriva deve assorbire cresce. Coloro che sono stati col progetto per lungo tempo saranno in grado di imparare, e inventare, le convenzioni del progetto nella misura in cui andarono avanti. Essi spesso non saranno consapevolmente al corrente di quale enorme corpo di tradizione hanno accumulato, e possono essere sorpresi di fronte a quanti passi falsi sembrano fare i nuovi arrivati. Certo, il fatto non è che i nuovi arrivati siano di qualche qualità inferiore di prima; è che essi sono di fronte a un più grande carico di acculturazione rispetto ai nuovi arrivati del passato.
L'anzianità che il progetto accumula è tanta nel comunicare e nel preservare le informazioni quanta essi ne hanno negli standard del codice e altre minuterie tecniche. Noi abbiamo dato un'occhiata a tutti e due i tipi di standard in sezione chiamata «La documentazione sviluppatore» in Capitolo 2, Partenza e sezione chiamata «Metter Giù Tutto Per Iscritto» in Capitolo 4, L'Infrastruttura Sociale e Politica rispettivamente e gli esempi sono dati lì. Ciò di cui tratta questa sezione è come mantenere le linee guida aggiornate nella misura in cui il progetto si evolve, specialmente le linee guida su come sono trattate le comunicazioni, perché queste sono le uniche che cambiano al massimo grado nella misura in cui il progetto cresce in grandezza e complessità.
Primo, prestate attenzione ai motivi per i quali la gente si confonde. Se vedete la stessa situazione presentarsi ancora e ancora, specialmente con i nuovi partecipanti. La possibilità che c'è è è una linea guida che necessita di di essere documentata e non lo è. Secondo, non vi stancate di dire la stessa cosa ancora e ancora, e non suonate come se siete stanchi di dirle. Voi e i veterani di altri progetti dovete ripeterlo a voi stessi; questo è un effetto inevitabile dell'arrivo di nuovi arrivati.
Ogni pagina web, ogni messaggio della mailing list, ed ogni canale IRC dovrebbe essere considerato uno spazio per i consigli, non per pubblicità, eccetto che per pubblicità delle risorse del vostro progetto. Ciò che mettete in quello spazio dipende dalla demografia di quelli che lo leggono. Un canale IRC per le domande degli utilizzatori, è, per esempio, adatto a portare gente che che non ha mai interagito col progetto prima—spesso qualcuno che ha appena installato il software e ha una domanda a cui vorrebbe venga risposto immediatamente (dopotutto, se potesse aspettare, l'avrebbe mandata alla mailing list, che probabilmente meno meno del suo tempo totale, sebbene ci vorrebbe di più perché ne venga indietrouna risposta). La gente di solito non fa un investimento permanente nel canale IRC; essi si presentano, fanno la loro domanda, e vanno via.
Quindi l'argomento del canale dovrebbe essere diretto a persone che cercano risposte tecniche sul software adesso, piuttosto che a, diciamo, a persone che potrebbero essere coinvolte nel progetto nel lungo termine e per i quali le linee guida di interazione della comunità potrebbero essere più appropriate. Qui è come un canale occupato gestisce ciò (comparate questo col precedente esempio in sezione chiamata «IRC / Sistemi di Chat in tempo reale» in Capitolo 3, L'Infrastruttura Tecnica ):
State parlando su #linuxhelp L'argomento per #linuxhelp è Prego LEGGERE http://www.catb.org/~esr/faqs/smart-questions.html && http://www.tldp.org/docs.html#howto PRIMA di fare domande | Le regole del canale si trovano a http://www.nerdfest.org/lh_rules.html | Prego consultare http://kerneltrap.org/node/view/799 prima di chiedere di aggiornare al kernel 2.6.x | lettura di memoria possibile: http://tinyurl.com/4s6mc -> aggiornare a 2.6.8.1 o 2.4.27 | in certa misura disastro hash: http://tinyurl.com/6w8rf | reiser4 fuori
Con le mailing list lo “spazio pubblicitario” è una piccola è un piccolo spazio in basso attaccato ad ogni messaggio. La maggior parte dei progetti vi mettono lì le istruzioni iscrizione/deiscrizione, e magari un puntatore alla homepage oppure alla pagina delle FAQ. Voi potreste pensare che chi si è iscritto alla mailing list saprebbe dove trovare queste cose ed essi probabilmente lo sanno—ma molta più gente di quelli che si sono iscritti vedono questi messaggi della mailing list. Un post archiviato può essere linkato da molti posti, alcuni post diventano cosi largamente noti che alla fine hanno molti più lettori al di fuori della mailing list che dentro.
La formattazione può fare molta differenza. Per esempio, nel progetto di Subversion, noi stavamo avendo un limitato esito favorevole nell'usare il filtro dei bug descritto in sezione chiamata «Pre-Filtraggio del Bug Tracker» in Capitolo 3, L'Infrastruttura Tecnica . Molti rapporti di bug fasulli stavano venendo archiviati da gente inesperta, e ogni volta che ciò avveniva, l'archiviatore doveva essere educato esattamente nello stesso modo di 500 persone prima di lui. Un giorno, dopo che uno dei nostri sviluppatori era finalmente arrivato alla fine della sua cordata e aveva inveito contro qualche utilizzatore deficitario che non leggeva le linee guida del tracciatore di problemi abbastanza con cura, un altro sviluppatore decise che questo comportamento era andato avanti a lungo abbastanza. Egli suggerì che noi formattassimo la pagina frontale del tracciatore di bug in modo che la parte più importante, la ingiunzione a discutere il bug sulla mailing list o sul canale IRC prima di archiviarlo, si distinguesse per l'enormità, lettere in grassetto rosso, su uno sfondo giallo brillante, centrato in prominenza sopra ogni altra cosa nella pagina. Noi facemmo così (potete vederne i risultati a http://subversion.tigris.org/project_issues.html), e il risultato fu un salto notevole nella velocità dei problemi fasulli archiviati. Ancora li prendiamo, certo, noi li prenderemo sempre ma la velocità è diminuita considerevolmente, anche se il numero degli utilizzatori cresce. La conclusione è non solo che il database contiene meno spazzatura, ma che quelli che rispondono alla archiviazione dei problemi rimangono di umore migliore e sono più propensi a restare amichevoli quando rispondono ad una archiviazione di una delle adesso rare archiviazioni fasulle. Questo migliora sia l'immagine del progetto, sia la salute mentale dei suoi volontari.
La lezione per noi fu che scrivere solamente le linee guida non era abbastanza. Noi dovevamo metterle dove sarebbero state viste da coloro che più di tutti avevano bisogno di esse, e formattarle in modo tale che il loro stato come materiale di introduzione sarebbe stato immediatamente chiaro alle persone non familiari col progetto.
Le pagine statiche non sono il solo luogo per far pubblicità ai clienti del progetto. E' anche richiesta una certa quantità di politica interattiva (nel senso di “ricordare amichevolmente” non nel senso di ammanettare e mettere in prigione). Tutta la revisione paritaria, anche le revisioni degli invii descritte in sezione chiamata «Praticare una Visibile Revisione del Codice» in Capitolo 2, Partenza, dovrebbe includere la revisione della conformità o non conformità della gente alle norme del progetto, specialmente riguardo alle convenzioni delle comunicazioni.
Un altro esempio dal progetto di Subversion: noi stabilimmo che “r12908" significasse "revisione 12908” nel deposito del controllo di versione. Il prefisso minuscolo “r” è facile da battere, e poiché è la metà dell'altezza delle cifre, esso rende un blocco di testo facilmente riconoscibile quando combinato con le cifre. Certo, quando una email di invio arriva con un messaggio di log come questo:
------------------------------------------------------------------------ r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Mer, 02 Feb 2005) | 4 righe Patch dal collaboratore J. Casuale <jrcontrib@gmail.com> * trunk/contrib/client-side/psvn/psvn.el: Corretti alcuni errori di stampa dalla revisione 12828. ------------------------------------------------------------------------
...parte della revisione di questo invio è per dire “Strada facendo prego usate 'r12828', non 'revisione 12828' quando vi riferite al cambiamento passato”. Questa non è pedanteria; è altrettanto importante per l'analisi sintattica automatica quanto per i lettori umani.
Seguendo il principio generale che ci dovrebbero essere dei metodi di riferimento canonico e che questi metodi di riferimento dovrebbero essere usati coerentemente ovunque, il progetto in effetti esporta certi standards. Questi standards mettono la gente in grado di scrivere strumenti che presentino le comunicazioni del progetto in modi più usabili—per esempio un revisione formattata come "r12828" potrebbe essere trasformata in un link vivo al sistema di osservazione del deposito. Ciò sarebbe piuttosto difficile se la revisione fosse scritta "revisione 12828", sia perché quella forma potrebbe essere divisa da una interruzione di linea, sia perché è meno distinta (la parola “revisione” apparirà spesso da sola, e il gruppo dei numeri apparirà spesso da solo, mentre la combinazione "r12828" può significare solo un numeri di revisione. Simili preoccupazioni si applicano ai numeri di problema, voci di FAQ (suggerimento: usate un URL con un'ancora con nome, come descritto in Ancore con nome e attributi ID), ecc.
Anche per le entità dove non c'è una ovvia breve, forma canonica, la gente tuttavia dovrebbe essere incoraggiata a fornire pezzi chiave di informazione coerentemente. Per esempio, quando ci si riferisce ad un messaggio della mailing list, non date solo il mittente e i soggetto; date anche l'URL dell'archivio e e la testata Message ID. L'ultimo permette alla gente che ha la sua copia della mailing list (le gente a volte tiene copie offline, per esempio da usare su un laptop in viaggio) per identificare senza ambiguità i messaggio giusto anche se non ha l'accesso agli archivi. Il mittente e il soggetto non sarebbero sufficienti, per che la stessa persona potrebbe fare parecchi post nello stesso trhead, anche nello stesso giorno.
Più il progetto cresce, più importante diventa questo tipo di coerenza. Coerenza significa che qualunque persona guardi, essa vede seguiti gli stessi comportamenti, così essi sanno seguire i comportamenti stessi. Questo, successivamente, riduce il numero di domande che essi hanno bisogno di di fare. Il carico di avere milioni di lettori non è più grande di quello di averne uno; i problemi di scalabilità cominciano a sorgere quando un a certe percentuale di di quei lettori fa domande. Nella misura in cui il progetto cresce, esso deve ridurre quella percentuale aumentando la densità e l'accessibilità dell'informazione, in modo che la persona in grado di trovare ciò di cui ha bisogno senza dover chiedere.