La programmazione è solo un parte di ciò che entra in un progetto open source. Dal punto di vista dei volontari del progetto è la parte più visibile e affascinante. Questo sfortunatamente significa che altre attività, come la documentazione, le prove formali, ecc.., possono talvolta essere ignorate, almeno in confronto alla quantità di attenzione che spesso riceve il software proprietario. Le compagnie sono spesso capaci di inventare questo, dedicando una parte della loro struttura interna di sviluppo di software a progetti open source.
La chiave per fare ciò con successo è trasferire tra i processi interni delle compagnie e quelli delle comunità di sviluppo pubblico. Tale trasferimento non è facile: spesso le due non sono una copia identica, e le differenze possono solo essere superate con l'intervento umano. Per esempio, la compagnia può usare un tracciatore di bugs differente da quello del progetto pubblico. Anche se esse usano un software di tracciamento identico, i dati immagazzinati in essi saranno molto differenti, perché un tracciamento di bugs richiesto da una compagnia è molto differente da quello di un comunità pubblica di software. Un pezzo di informazione che si mette a fare il tracciatore può aver bisogno di essere riflesso nell'altro, con porzioni riservate rimosse, o, in altra direzione, aggiunte.
Le sezioni che seguono riguardano la costituzione e il mantenimento dei ponti per superare le differenze. Il risultato finale dovrebbe essere quello che il progetto open source funziona meglio, la comunità riconosce l'investimento di risorse della compagnia, e anche non si avverte che la compagnia sta dirigendo in modo improprio le cose verso i sui obiettivi.
Nello sviluppo di software proprietario, è normale avere gente unicamente destinata alla garanzia della qualità: ricerca dei bug, tests di prestazioni e scalabilità, controllo dell'interfaccia e della documentazione. Come regola, queste attività non sono inseguite tanto vigorosamente dalla comunità di volontari nel progetto di software libero. In parte perchè è difficile trovare lavoro volontario per un lavoro non affascinante come il testing, in parte perché la gente tende a dare per scontato che l'avere una vasta comunità di utilizzatori dà al progetto una buona copertura di testing, e, nel caso del testing delle prestazioni e della scalabilità, in parte perché i volontari spesso non hanno l'accesso alle risorse hardware, in qualche modo.
La convinzione che avere molti utilizzatori è equivalente ad avere molti che testano non è completamente senza fondamento. Certamente non ha senso assegnare persone che testano funzionalità base in una ambiente comune: i bugs saranno rapidamente trovati dagli utilizzatori nel naturale corso delle cose. Ma poiché gli utilizzatori stanno giusto cercando di di finire il lavoro, inconsciamente non partono con l'intenzione di esplorare casi sconosciuti di funzionamento ai limiti nelle funzionalità dei programmi, e sono propensi a lasciare certi tipi di bugs non trovati. Inoltre, quando scoprono un bug con un facile stratagemma, spesso implementano in silenzio lo stratagemma senza darsi noia di riportare il bug. Ancora più insidiosamente, il modo d'uso dei vostri clienti (le persone che guidano il vostro interesse nel software) può differire in in modo statisticamente significativo dal modo d'uso dell'Utilizzatore Medio Della Strada.
Un gruppo professionale do testing può scoprire questo tipo di bugs, e può farlo facilmente sia con il software libero sia con il software proprietario. La sfida è di riportare al pubblico il risultati del gruppo di testing in una forma utile. I gruppi di testing in azienda usualmente hanno un loro modo di riportare questi risultati, impiegando un linguaggio specifico della compagnia o una conoscenza di particolari clienti e del loro gruppo di dati. Tali rapporti sarebbero inadatti per il tracciatore di bug pubblico, sia a causa della loro forma e a causa della confidenzialità. Anche se il software tracciatore di bugs interno della vostra compagnia fosse lo stesso di quello usato nei progetti pubblici, l'amministrazione poterebbe aver bisogno di commenti specifici della compagnia e di cambiamento dei meta dati (per esempio sollevare una priorità interna dei problemi o programmare la sua risoluzione per un particolare cliente). Usualmente tali note sono confidenziali—talvolta non sono nemmeno mostrate al cliente. Ma anche quando esse non sono confidenziali, esse non riguardano il progetto pubblico, e quindi il pubblico non dovrebbe essere distratto da essi.
Tuttavia il cuore stesso del rapporto dei bugs èimportante per il pubblico. Infatti un rapporto del vostro dipartimento di testing è più prezioso di un rapporto dagli utilizzatori in libertà, poiché il dipartimento di testing indaga su cose su cui altri non indagherebbero. Dato che è improbabile che voi otteniate quel rapporto di bugs da altra fonte, volete di sicuro preservarlo e renderlo disponibile per il progetto pubblico.
Per fare questo o un dipartimento QA può archiviare i problemi nel tracciatore di problemi pubblico, se lo trova comodo, o un intermediario (usualmente uno degli sviluppatori) può “trasportare” i rapporti del dipartimento interno di testing in nuovi problemi nel tracciatore pubblico. Trasporto significa semplicemente descrivere i bugs in un modo tale che non faccia riferimento all'informazione specifica del cliente (il sistema della ripetizione può usare dati del cliente, assumendo che egli lo approvi, certamente).
E' alquanto preferibile che il dipartimento QA archivi i problemi direttamente nel tracciatore pubblico. Ciò dà al pubblico una stima del coinvolgimento nel progetto della vostra compagnia: un utile riporto dei bugs conferisce alla vostra compagnia credibilità giusto come lo farebbe un contributo tecnico. Ciò anche dà agli sviluppatori una linea di comunicazione col gruppo di testing. Per esempio, se il gruppo interno di QA sta monitorando il tracciatore pubblico di problemi, uno sviluppatore può inviare una correzione per un bug di scalabilità (per il quale lo sviluppatore può non avere le risorse per testarlo da se), e quindi aggiungere una nota al problema chiedendo al QA di vedere se la correzione ha avuto l'effetto desiderato. Aspettatevi un po' di resistenza da parte di qualche sviluppatore; i programmatori hanno la tendenza a guardare al QA come, nel migliore dei casi, al diavolo. Il gruppo QA può rimediare a questo trovando bugs significativi e mettendo in archivio rapporti comprensibili; d'altra parte se i loro rapporti non sono almeno buoni quanto quelli provenienti dalla comunità degli utilizzatori regolari, allora è inutile averli in relazione direttamente con il team di sviluppo.
In un modo o nell'altro, una volta che esiste un pubblico problema il problema originale dovrebbe far riferimento al problema pubblico per il contenuto tecnico. L'organizzazione e gli sviluppatori pagati possono continuare ad annotare i problemi interni con commenti specifici della compagnia quanto necessario, ma usare il problema pubblico per una informazione che dovrebbe essere disponibile per tutti.
Dovreste entrare in questo processo aspettandovi spese extra. Mantenere due problemi per un bug è, naturalmente, un lavoro maggiore che mantenerne uno. Il beneficio è che molti codificatori vedranno il rapporto e saranno capaci di contribuire a una soluzione.
Le compagnie per profitto o noprofit sono quasi le uniche entità che pongono l'attenzione sui complessi aspetti legali del software libero. Gli sviluppatori individuali spesso capiscono le sottigliezze delle varie licenze open source ma non hanno il tempo o le risorse per seguire in dettaglio la legge sul copyright, sul marchi o sul brevetto. Se la vostra compagnia ha un dipartimento legale, può aiutare il progetto nel curare l'aspetto legale del codice, e aiutare gli sviluppatori a capire i potenziali problemi legali dei brevetti e del marchio. La forma che questo aiuto può prendere è discussa in Capitolo 9, Licenze, Diritti d'Autore e Brevetti. La cosa principale è essere sicuri che le comunicazioni fra il dipartimento legale e la comunità degli sviluppatori, se avviene punto, avvenga con il reciproco riconoscimento dei molto diversi universi da cui le parti provengono. Occasionalmente, questi due gruppi parlano uno dopo l'altro, ogni parte dando per scontato una comprensione dello specifico campo che l'altra non ha. Una buona strategia è avere un intermediario (usualmente, uno sviluppatore, oppure un legale con esperienza tecnica) che stia nel mezzo e medi finché sia necessario.
La documentazione e l'usabilità sono ambedue i punti delicati nei progetti open source, sebbene io penso, almeno nel caso della documentazione, che la differenza fra il software libero e quello proprietario sia frequentemente esagerata. Nondimeno è nei fatti vero che molti software open source difettano di una documentazione di prima classe e di ricerca di usabilità.
Se la vostra organizzazione vuole contribuire a riempire questi vuoti, probabilmente la cosa migliore che può fare è assumere le persone che non sono sviluppatori regolari nel progetto, ma che saranno capaci di interagire produttivamente con gli sviluppatori. Non assumere sviluppatori regolari è un bene per due ragioni: uno, in quel modo non portate via tempo dal progetto; due, quelli vicini al software sono usualmente le persone sbagliate per scrivere la documentazione o studiare l'usabilità, perché non hanno la il pensiero di vedere il software dal punto di vista di un estraneo.
Comunque sarà necessario per chiunque lavori a questi problemi comunicare con gli sviluppatori. Trovate persone che siano abbastanza tecniche per parlare col team dei codificatori, ma non così esperti nel software da non potersi ancora immedesimare nei normali utilizzatori.
Un utilizzatore di medio livello è la persona giusta per scrivere una buona documentazione. Infatti, dopo che la prima edizione di questo libro fu pubblicata, ricevetti la seguente email da uno sviluppatore open source chiamato Dirk Reiners:
Un commento sui Soldi:: La documentazione e l'Usabilità: quando avevamo qualche soldo da spendere e concludemmo che una guida per quelli che cominciavano era la parte più critica assumemmo un utilizzatore di medio livello per scriverla. Egli era andato per induzione al sistema abbastanza recentemente per ricordare i problemi, ma era passato attraverso di essi per sapere come descriverli. Ciò gli permise di scrivere qualcosa che serviva solo per le correzioni minori da parte di sviluppatori di base per le cose che non aveva capito bene, ma che tuttavia trattava le 'ovvie' cose che gli sviluppatori avrebbero tralasciato. Il suo caso era persino migliore, come se fosse stato suo compito introdurre un sacco di altra gente (studenti) nel sistema, in modo che egli unì l'esperienza di tanta gente, che è qualcosa che fu una felice avvenimento e che è probabilmente difficile da raggiungere nella maggior parte dei casi.
Per un progetto che non stia usando un hosting confezionato gratuito (vedere sezione chiamata «Canned Hosting» in Capitolo 3, L'Infrastruttura Tecnica ), procurare un server e una connessione a un netwoork e in modo molto rilevante, un sistema di aiuto all'amministrazione può essere di significativa assistenza. Anche se questo è tutto quello che la vostra organizzazione fa per il progetto, può essere moderatamente un modo efficace per ottenere una buona atmosfera di pubbliche relazioni, sebbene ciò non porterà ad una influenza sulla direzione del progetto.
a che fare con la vostra compagnia, anche se voi non contribuite per nulla allo sviluppo. Il problema è, gli sviluppatori sono al corrente di questa tendenza associativa eccessiva, e possono non essere contenti di avere il loro progetto sul vostro dominio a meno che voi non immettiate più risorse che non la sola banda. Dopotutto ci sono un sacco di posti che danno hosting di questi tempi. La comunità può eventualmente essere del parere che la relativa cattiva assegnazione del riconoscimento non equivale alla convenienza ottenuta con l'hosting e trasferire il progetto altrove. Così se volete fornire l'hosting, fatelo—ma o pianificate di essere coinvolti di più presto o state attenti a quanto coinvolgimento reclamate.