I Soldi
Questo capitolo esamina come dare i finanziamenti a una ambiente di software libero. E' rivolto non solo agli sviluppatori che sono pagati per lavorare a progetti di software libero, ma anche ai loro managers, che hanno bisogno di capire le dinamiche sociali dell'ambiente di sviluppo. Nelle sezioni che seguono il destinatario (“tu”) si presume che sia sia lo sviluppatore pagato, sia chi lo dirige. Il consiglio sarà spesso lo stesso per ambedue; quando non lo è, il pubblico a cui si dirige sarà reso chiaro dal contesto.
Che le compagnie finanzino uno sviluppo di software libero non è un fenomeno nuovo. Una grande quantità di sviluppo è stato spesso sovvenzionato informalmente. Quando un amministratore di sistema scrive uno strumento di analisi del network per aiutare gli sviluppatori a fare il loro lavoro, allora lo posta on line, e raccoglie le correzioni dei bugs e i contributi alle funzionalità dagli altri amministratori, ciò che è avvenuto è che si è formato un consorzio non ufficiale. Il finanziamento del consorzio proviene dai salari dei sysadmins, e lo spazio per gli uffici e la banda per il network sono donati, sebbene in modo inconsapevole, dalle organizzazioni per le quali essi lavorano. Queste organizzazione traggono beneficio dall'investimento, ovviamente, anche non ne sono al corrente inizialmente.
La differenza oggi è che molti di questi sforzi stanno venendo formalizzati. Le compagnie sono divenute consapevoli dei benefici del software open source, e hanno incominciato a coinvolgersi di prima persona nello sviluppo. Anche gli sviluppatori hanno incominciato ad aspettarsi che i progetti veramente importanti attrarranno almeno donazioni, e possibilmente anche sponsors a lungo termine. Mentre la presenza dei soldi non ha cambiato le dinamiche base dello sviluppo di software libero, ha largamente cambiato la scala in cui ciò avviene, sia in termini di numero degli sviluppatori che in termini di tempo-per-sviluppatore. Ciò ha anche avuto effetto su quanti progetti sono organizzati, e su come le parti coinvolte interagiscono. I problemi non sono solamente quanti soldi si spendono o come viene valutato il ritorno dell'investimento. Essi riguardano anche l'amministrazione e il processo: come possono la struttura gerarchica di comando delle compagnie e le semi decentralizzate comunità di volontari dei progetti di software libero lavorare produttivamente insieme? Saranno sempre d'accordo su ciò che significa “produttivamente”?
Il sostegno finanziario è generalmente ben accetto dalle comunità open source. Esso può diminuire la vulnerabilità di un progetto alla Forza del Caso, la quale può spazzar via tanti progetti prima che decollino, quindi può rendere la gente più desiderosa di dare al software una chance—essi avvertono di star investendo il proprio tempo in qualcosa che sarà ancora in vita sei mesi da ora. Dopotutto la credibilità è contagiosa, a un certo punto. Quando, per esempio, L'IBM sostiene un progetto open source, la gente, in un certa misura sente che al progetto non sarà permesso di fallire, e la loro risultante buona volontà a impegnarsi devotamente ad esso può rendere ciò una profezia auto appagante.
In ogni caso il finanziamento porta anche una percezione di controllo. Se non gestiti con cura, i soldi possono dividere gli sviluppatori in gruppi ristretti e un gruppi non ristretti. Se i volontari non pagati si fanno l'idea che le decisioni della progettazione o l'aggiunta di funzionalità sono solo una prerogativa del miglior offerente, allora essi volteranno le spalle a un progetto che sembra più simile a una meritocrazia e meno simile a un lavoro non pagato a beneficio di qualcun altro. Essi non possono mai lagnarsi apertamente nella mailing list. Invece ci sarà sempre meno e meno rumore da parte di fonti esterne, quando i volontari smetteranno di cercare di essere presi seriamente. Il mormorio dell'attività di piccola scala continuerà, nella forma di rapporti di bugs e di piccole correzioni. Ma non ci sarà un largo contributo o una partecipazione esterna alle discussioni sul progetto. La gente sente ciò che ci si aspetta da loro e sta al di sopra o al di sotto di queste aspettative.
Anche se i soldi bisogna usarli con cura, ciò non significa che non possano acquistare influenza. Nella maggior parte dei casi certamente lo possono. Il trucco è che non possono acquistarla direttamente. In una diretta transazione commerciale, voi cambiate moneta per ciò che volete. Se avete il bisogno che una funzionalità venga aggiunta, sottoscrivete una contratto, pagate per esso, e ciò viene fatto. In un progetto open source, non è così facile. Voi potete sottoscrivere un contratto con alcuni sviluppatori, ma essi avranno ingannato se stessi —e voi—se essi hanno garantito che il lavoro per cui avete pagato sarebbe accettato dalla comunità di sviluppo perché avete pagato per esso. Il lavoro può essere accettato solo per i suoi meriti e per come si inserisce nella visione della comunità in relazione al software. Potete avere qualche voce in quella visione, ma non sarete l'unica voce.
Così i soldi non può comprare l'influenza, ma possono comprare cose che portano all'influenza. L'esempio più ovvio sono i programmatori. Se i programmatori sono noleggiati, e restano intorno al progetto abbastanza per acquisire esperienza e credibilità nella comunità, allora possono influenzare il progetto con gli stessi mezzi degli altri membri. Essi avranno un voto, o, se ce ne sono molti di essi, avranno un blocco votante. Se esso sono rispettati nel progetto, avranno influenza oltre il loro stesso voto. Non c'è bisogno per gli sviluppatori pagati disquisire sulle loro ragioni, nemmeno. Dopotutto chiunque vuole che in cambiamento sia apportato al software, lo vuole per una ragione. Ed è giusto che il peso dato agli obiettivi della vostra compagnia sia determinato dallo stato delle sue rappresentanze nel progetto, non dalla grandezza della compagnia, dal suo budget, o dal piano di affari.
Tipi di Coinvolgimento
Ci sono molte ragioni per cui un progetto open source viene finanziato. Le voci di questa lista non sono mutuamente esclusive; spesso il ritorno finanziario di un progetto risulterà da molte, o anche tutti questi motivi:
Suddividere il Carico
Separate organizzazioni con software imparentato si trovano a dover duplicare gli sforzi, sia per il fatto di scrivere codice ridondante in casa, sia per il fatto di comprare prodotti simili dai venditori proprietari. Quando si accorgono di quello che sta avvenendo, le organizzazioni possono unire le loro risorse e creare (o unire) un progetto tagliato sulle loro necessità. I vantaggi sono ovvi: i costi dello sviluppo si dividono, ma i benefici si accumulano. Anche se lo scenario sembra intuitivo per i nonprofit, esso può dare un senso di strategico anche per i concorrenti for profit.
Esempi: ,
Aumentare i Servizi
Quando una compagnia mette in vendita i servizi dai quali dipende, o per i quali diviene più attrattiva, particolari programmi open source, è naturale l' interesse di quella compagnia ad assicurare che siano attivamente conservati.
Esempio: CollabNet's supporto di
(esclusioni di garanzia: cioè il lavoro della mia giornata ma è anche un perfetto esempio di questo modello).
Supportare la vendita di hardware
Il valore dei computers e dei componenti è direttamente correlato al software disponibile per essi. I venditori di hardware, non solo i venditori dell'intera macchina, ma anche i costruttori di periferiche e di microchips hanno trovato che l'avere software libero da far girare sul loro hardware è importante per i clienti.
Scalzare un concorrente
A volte le compagnie sostengono un progetto open source come mezzo per scalzare un prodotto concorrente, che a sua volta potrebbe o non potrebbe essere open source. Distruggere poco a poco una quota del mercato concorrente, usualmente non è la sola ragione per coinvolgersi in un progetto open source, ma può essere un fattore.
Esempio: (no questa non è la sola ragione per cui esiste Openoffice, ma il software è almeno in parte una risposta a Microsoft Office).
Il marketing
Avere la vostra compagnia associata a un progetto open source può essere un affare di buon marchio.
Doppia licenza
Doppia licenza è la pratica di offrire software sotto una tradizionale licenza proprietaria a clienti che lo vogliono come parte di una applicazione proprietaria per se stessi, e simultaneamente sotto una licenza libera per coloro che vogliono usarlo sotto i termini della licenza open source (vedere
in
).
Se la comunità di sviluppatori open source è attiva, il software gode di una larga area di debugging e di sviluppo, e la compagnia pure ricava un flusso di denaro per sostenere sviluppatori a tempo pieno.
Due ben noti esempi sono MySQL, costruttori di software per database dello stesso nome, e Sleepycat, che offre distribuzione e supporto per. Non è una coincidenza che esse siano entrambe compagnie di database. Il database tende ad essere integrato nelle applicazioni, piuttosto che essere venduto direttamente agli utenti, cosicché è molto più adatto al modello di doppia licenza.
Le donazioni
Un progetto largamente usato può ricevere a volte significativi contributi, da individui e organizzazioni, giusto per il fatto di avere un pulsante di donazioni on line, o per vendere merce col marchio come tazze di caffè, T-shirts, cuscinetti per il mouse, ecc... Una parola di attenzione: se il vostro progetto accetta donazioni, pianificate come verrà usato il danaro
prima che arrivi e pubblicate il piano sul sito web. Le discussioni su come destinare il danaro tendono ad andare molto meno regolarmente si tengono prima che ci sia reale danaro da spendere; e, in ogni modo, se ci sono dei rilevanti disaccordi, è meglio scoprire che esso (il danaro) è fuori fintanto che è ancora accademico.
Un modello di fondazione per affari non è il solo fattore su come si mette in relazione alla comunità di sviluppatori. Interessa anche la relazione storica fra i due: la compagnia avviò il progetto, o si sta associando a uno sforzo esistente? In ambedue i casi, il fondatore deve guadagnarsi credibilità, ma, non in modo sorprendente, c'è tanto in più guadagno da fare nel secondo caso. L'organizzazione deve avere chiari obiettivi rispetto al progetto. La compagnia sta cercando di avere una posizione di leadership, o soltanto di essere una voce nella comunità, per guidare e non necessariamente governare le direzione del progetto? O vuole giusto avere a disposizione una coppia di persone raccomandate, capaci di correggere i bugs dei clienti e introdurre i cambiamenti nella distribuzione pubblica, senza affanni?
Tenete queste questioni in mente quando leggete le linee guida che seguono. Si intende che esse siano applicate a una sorta di coinvolgimento organizzativo in un progetto di software libero, ma ogni progetto è un ambiente umano, e quindi non ve ne sono due esattamente simili. In qualche grado, voi avrete da giocare ad orecchio, ma seguendo questi principi accrescerete la probabilità che le cose vadano per il verso che volete.
Pagate Per il Lungo Termine
Se state dirigendo programmatori in un progetto open source, teneteli abbastanza affinché essi acquisiscano esperienza tecnica e politica—un paio di anni come minimo. Certamente nessuno progetto nè open né closed source trae beneficio dall'uscita e dall'ingresso troppo frequente. Il bisogno di un nuovo arrivato di imparare le cordate dovrebbe essere un deterrente in ogni ambiente. Ma la penalizzazione è anche più forte nei progetti open source, perché i programmatori che escono portano con sé non solo la loro conoscenza del codice, ma anche il loro status nella comunità e le relazioni umane che hanno stabilito lì.
La credibilità che uno sviluppatore ha accumulato non può essere trasferita. Per fare il più ovvio esempio, uno sviluppatore che arriva non può ereditare l'accesso all'invio da uno che se ne va (vedere
più avanti in questo capitolo), così se il nuovo sviluppatore non ha già l'accesso all'invio, avrà da inviare correzioni fin quando lo avrà. Ma l'accesso all'invio è solo la più misurabile manifestazione di perduta influenza. Uno sviluppatore di lungo termine conosce anche tutti i vecchi argomenti che sono stati triti e ritriti nelle liste di discussione.
Un nuovo sviluppatore, non avendo memoria di quelle discussioni, può cercare di riportare a galla gli argomenti, portando a una perdita di credibilità per la vostra organizzazione. Gli altri potrebbero meravigliarsi “Non possono ricordarsi di ogni cosa? Un nuovo sviluppatore non avrà nemmeno un senso politico delle personalità del progetto, e non saranno capaci di influenzare gli orientamenti del progetto così rapidamente o così regolarmente come lo fa uno che vi è rimasto per lungo tempo.
Preparate i nuovi arrivati con un programma di ingaggio controllato. Il nuovo sviluppatore deve essere in contatto la comunità di pubblico sviluppo sin dal primo giorno, partendo con la correzione di bugs e le operazioni di ripulita, in modo che possano imparare il codice base e acquistare una reputazione nella comunità, e non accendere lunghe e complesse discussioni di progetto. In tutto questo tempo, uno o più sviluppatori dovrebbero essere a disposizione per domande e risposte, e dovrebbero leggere ogni post che i nuovi arrivati facciano nella mailing list degli sviluppatori, anche se in essa ci sono threads a cui gli sviluppatori non rivolgerebbero l'attenzione. Ciò aiuterebbe il gruppo a scorgere le potenziali rocce prima che i nuovi arrivati vi rimangano incagliati. Incoraggiamenti privati, dietro le scene e consigli possono anche aiutare molto, specialmente se il nuovo arrivato non è abituato ad una massiccia parallela revisione fra pari del suo codice.
Quando CollabNet ingaggia un nuovo sviluppatore per lavorare a Subversion, noi ci sediamo intorno a un tavolo e scegliamo qualche bug aperto per la nuova persona perché lui ci affondi i denti. Noi discuteremo le linee bozza delle soluzioni, e poi assegneremo almeno uno sviluppatore esperto per (pubblicamente) revisionare le correzioni che il nuovo arrivato posterà. Tipicamente non guarderemo la correzione prima che la lista degli sviluppatori la veda, sebbene lo potremmo se vi fosse qualche ragione. La cosa importante è che il nuovo sviluppatore passi attraverso il processo della pubblica revisione, imparando il codice base e simultaneamente e abituandosi a ricevere critiche da parte di perfetti sconosciuti. Ma noi cerchiamo di coordinare i tempi in modo che la nostra revisione venga immediatamente dopo che la patch è stata postata. Così la prima revisione che la lista vede è la nostra, cosa che può essere utile e impostare il tono delle altre revisioni. Ciò contribuisce anche all'idea che la nuova persona deve essere presa seriamente: se gli altri vedono che noi stiamo impiegando il tempo a fare dettagliate revisioni con esaurienti spiegazioni e riferimenti negli archivi dove è appropriato, apprezzeranno ciò come una forma di training che sta andando avanti, e ciò probabilmente significa investimento a lungo termine. Questo li renderà più ben disposti verso lo sviluppatore, almeno nella misura di spendere un tempo extra nel rispondere alle domande e nel revisionare le correzioni.
Apparite Come Molti, Non Come Uno Solo
I vostri sviluppatori dovrebbero adoperarsi per apparire nei forums pubblici del progetto come partecipanti individuali, piuttosto che come una presenza monolitica collettiva. Ciò non perché ci sia un connotato negativo inerente a una presenza monolitica collettiva (bene, forse c'è, ma ciò non è il motivo per cui esiste questo libro). Piuttosto è perché gli individui sono una sorta di identità per cui i progetti open source sono equipaggiati per fare affari. Un collaboratore individuale può avere discussioni, inviare correzioni, acquistare credibilità, votare, e così via. Una compagnia no.
Inoltre, con l'avere un modo decentralizzato, voi evitate di stimolare una opposizione centralizzata. Lasciate che i vostri sviluppatori non siano d'accordo fra di loro nelle mailing lists. Incoraggiateli a revisionare il codice l'uno dell'altro tanto spesso, quanto pubblicamente, quanto farebbero ciascuno dell'altro. Scoraggiateli dal votare sempre in blocco, perché se lo facessero, altri potrebbero percepire che ciò, giusto in linea generale, sarebbe un sforzo organizzato per tenerli frenati.
C'è una differenza fra l'essere realmente centralizzati e semplicemente adoperarsi di apparire tali. In certe circostanze l'avere che i vostri sviluppatori si comportino in concerto può essere molto utile, ed essi dovrebbero essere preparati a coordinarsi dietro le quinte quando necessario. Per esempio, nel fare una proposta, avere molte persone che siano d'accordo in anticipo, può essere utile ad essa nel percorso, dando l'impressione di un consenso crescente. Gli altri avranno l'impressione che la proposta abbia forza, e che se facessero obiezione, fermerebbero quella slancio. Così la gente obietterà solo se avrà una buona ragione per farlo. Non c'è niente di sbagliato nell'orchestrare un accordo come questo, fin quando le obiezioni sono prese seriamente. Le manifestazioni pubbliche di un accordo privato non sono meno genuine per essere state coordinate in anticipo, e non sono dannose finché non son usate pregiudizialmente per spegnere gli argomenti dell'opposizione. Il loro scopo è unicamente quello di ostacolare quel tipo di persone che amano obiettare giusto per stare nella scia; vedere
in per maggiori ragguagli su di essi.
Siate Aperti Verso Le Vostre Motivazioni
Siate aperti verso gli obiettivi della vostra organizzazione quanto potete senza compromettere i segreti del business. Se volete che il vostro progetto acquisisca una certa funzionalità perchè, per esempio, i vostri clienti la hanno chiesta a gran voce, ditelo apertamente sulla maliling list. Se i clienti vogliono restare anonimi, come a volte è il caso, allora chiedete loro se vogliono essere usati come esempi non nominati. Quanto più pubblicamente la comunità di sviluppo conoscerà sul perchè volete ciò che volete, tanto più essa sarà accomodante su qualunque cosa stiate proponendo.
Ciò va contro l'istinto—così facile ad acquisire così facile a scrollarsi di dosso—che la conoscenza è potere e quanto più gli altri conoscono dei vostri obiettivi, tanto più controllo hanno su di voi. Sostenendo pubblicamente la funzionalità (una correzione di un bug, o qualcos'altro) voi avete
già gettato la carte sul tavolo. La sola questione ora è se avrete successo nel guidare la vostra comunità nel condividere il vostro obiettivo. Se voi semplicemente stabilite ciò che volete, ma non fornite esempi concreti sul perché, il vostro argomento è fiacco, e la gente comincerà a sospettare una agenda nascosta. Ma se voi fornite uno scenario di poche parole che mostri perché la nuova funzionalità è importante, allora potete avere un sensazionale effetto sul dibattito.
Per vedere perché la cosa sta così, considerate l'alternativa. Troppo frequentemente il dibattito sulle nuove funzionalità è lungo e noioso. Gli argomenti che le persone avanzano spesso si riducono a “Io personalmente voglio X” o il sempre popolare “Nei miei anni di esperienza come progettista di software X è estremamente importate per gli utenti / un inutile fronzolo che non piacerà a nessuno”. Prevedibilmente l'assenza di informazione nelle parole reali né accorciano né moderano tali dibattiti, ma invece permettono che essi vadano ala deriva lontano lontano da ogni ormeggio nella reale esperienza dell'utente. Senza una forza controbilanciante, il risultato finale molto verosimilmente non viene determinato da una persona che era la più chiara, o la più tenace, o la più anziana.
Come organizzazione con abbondanti dati disponibili sui clienti, avete la opportunità di fornire giusto questa forza bilanciante. Voi potete essere come una condotta per le informazione che potrebbero avere diversamente nessun mezzo per raggiungere la comunità di sviluppo. Il fatto che quella informazione può supportare i vostri desideri non costituisce nulla di imbarazzante. La maggior parte degli sviluppatori individualmente non ha una larga esperienza su come il codice che essi hanno scritto viene usato. Ogni sviluppatore usa il suo software nel suo modo caratteristico. Fin dove i modelli degli altri vanno, lui fa affidamento sull'intuizione e sulle ipotesi, e nel profondo del suo cuore, lui sa questo.
Ma, fornendo dati credibili su un gran numero di utenti, voi date alla comunità di sviluppo pubblico qualcosa di simile all'ossigeno. Finché presenterete ciò nel modo giusto, essi gradiranno ciò entusiasticamente, e muoveranno le cose nella direzione che voi volete.
La chiave, certamente, è presentare la cosa ne modo giusto. Non lo fate mai insistendo che semplicemente per il fatto che avete a che fare con un gran numero di utenti e poiché essi hanno bisogno di una data funzionalità (o così voi credete), allora la vostra soluzione dovrebbe essere implementata. Invece voi dovreste focalizzare i vostri post iniziali sul problema, piuttosto che su una particolare soluzione. Descrivete in gran dettaglio l'esperienza che i vostri clienti stanno facendo, offrite quanta più analisi vi è possibile, e quante soluzioni voi potete pensare. Quando la gente incomincia a far congetture sull'efficacia delle varie soluzioni, voi potete continuare ad utilizzare i vostri dati per sostenere o rifiutare quello che dicono. Voi potete avere una soluzione in mente per tutto il tempo, ma non sceglietela per speciali considerazioni all'inizio. Questo non è inganno, questo è il comportamento standard dell'onesto mediatore. Dopotutto il vostro vero obiettivo è risolvere il problema; una soluzione è solo un mezzo per quel fine. Se la soluzione che voi preferite è veramente la migliore, gli altri sviluppatori lo riconosceranno dal loro canto alla fine—e allora vi andranno dietro di loro spontanea volontà, che è molto meglio che se voi li minacciaste a implementarla. (C'è anche la possibilità che essi abbiano in mente un soluzione migliore)
Con questo non si vuole dire che non potete mai dichiararvi a favore di una specifica soluzione. Ma dovete avere la pazienza di vedere l'analisi che avete già fatto internamente ripetuta nella mailing list dello sviluppo pubblico. Non postate “Noi abbiamo discusso ogni aspetto di questo problema , ma non funziona per il motivo A, B e C. Una volta che pensate realmente al problema, l'unico modo per risolverlo è...” Il problema non è tanto che ciò suona arrogante tanto da dare l'impressione che avete
già edicato alcune sconosciute (me, la gente presumerà, grandi) quantità di risorse analitiche al problema, a porte chiuse. Esso fa sembrare ciò come se comunque gli sforzi sono stati fatti, forse le decisioni sono state prese, che il pubblico non è informato, e che è una ricetta per il risentimento.
Naturalmente, voi sapete quanto sforzo avete internamente dedicato al problema, e quella consapevolezza è, in un cero modo, uno svantaggio. Ciò mette i vostri sviluppatori un uno spazio un pochino differente rispetto ad ogni altro nella mailing list, riducendo la loro abilità a vedere le cose dal punto di vista che non hanno ancora tanto pensato al problema.
Prima potete indurre ogni altro a pensare alle cose negli stesi termini in cui lo fate voi, più piccolo sarà l'effetto di questa distanza. Questa logica non si applica solo a individuali situazioni tecniche, ma al più largo mandato di rendere i vostri obiettivi più chiari che potete. L'ignoto è sempre più destabilizzante del noto. E la gente capisce perché volete ciò che volete, essi si sentiranno a loro agio parlandovi anche quando sono in disaccordo. Se essi non possono capire ciò che vi fa fare tic, presupporranno il peggio, almeno alcune volte.
Non sarete capaci di pubblicare ogni cosa, e la gente non si aspetterà ciò. Tutte le organizzazioni hanno segreti, forse quelle con fini di profitto ne hanno di più, ma quelle noprofit ne hanno pure. Se dovete difendere un certo corso, ma non rivelate nulla sul perché, allora semplicemente offrite i migliori argomenti che potete impediti da quello svantaggio e accettate il fatto che non potete avere l'influenza che volete in quella discussione. Questo è uno dei compromessi che dovete fare per non avere la comunità di sviluppo sul vostro libro paga.
Il Danaro Non Può Comprare Ciò Che Amate
Se avete uno sviluppatore pagato nel progetto, allora stabilite delle linee guida su ciò che il denaro può comprare e ciò che non può comprare. Ciò non significa che dovete postare due volte al giorno nella mailing list ripetendo la vostra nobile e incorruttibile natura. Significa solo che dovreste essere in guardia nel caso doveste disinnescare le tensioni che
potrebbero crearsi per i soldi. Non è il caso di di partire assumendo che le tensioni sono lì; dovete dimostrare una consapevolezza che esse hanno la potenzialità di nascere.
Un perfetto esempio di questo ci viene dal progetto Subversion. Subversion fu avviato nel 2000 da CollabNet, che era stata la principale finanziatrice sin dal suo inizio, pagando i salari di molti sviluppatori (esclusioni di garanzia: io sono uno di essi). Poco dopo che il progetto incominciò, noi ingaggiammo un altro sviluppatore, Mike Pilato, per congiungere gli sforzi. Ma allora la codifica era già partita. Anche se Subversion era ancora molto ai primi stadi, era già una comunità di sviluppo con una serie di regole base.
L'arrivo di Mike sollevò una interessante questione. Subversione aveva già una politica su come un nuovo sviluppatore consegue l'accesso all'invio. Primo, egli invia alla mailing list alcune correzioni. Dopo che un numero sufficiente di correzioni sono arrivate da parte di altri che hanno l'accesso all'invio, per vedere se il nuovo collaboratore sa quello che sta facendo, qualcuno propone che egli giusto invii direttamente (questa proposta è privata ed è descritta in ). Dato per acquisito l'accordo di quelli che avevano l'accesso all'invio uno di essi invia una email al nuovo sviluppatore e gli propone l'accesso diretto all'invio al deposito del progetto.
CollabNet aveva ingaggiato Mike per lavorare specificatamente a Subversion. Fra quelli che già lo conoscevano, non c'era dubbio sulle sue capacità nello scrivere codice e sulla sua sollecitudine nel lavorare al progetto. Inoltre gli sviluppatori volontari avevano molto buone relazioni con gli impiegati di CollabNet, e molto probabilmente non avrebbero obiettato se noi avessimo dato l'acceso all'invio a Mike il giorno che fu ingaggiato. Ma noi sapevano che avremmo creato un precedente. Se noi avessimo concesso a Mike l'accesso all'invio per decreto avremmo detto che CollabNet aveva il diritto di ignorare le linee guida del progetto, semplicemente perché era il finanziatore principale. Mentre il danno di ciò non era necessariamente immediatamente evidente, avrebbe avuto il risultato che i non salariati si sarebbero sentiti privati del diritto di voto. Altre persone hanno da guadagnarsi il loro accesso all'invio —CollabNet giusto lo compra.
Così Mike accettò di di iniziare il suo impiego a CollabNet come qualsiasi altro volontario, senza l'accesso all'invio. Egli mandava correzioni alla mailing list, dove esse potevano essere revisionate, e lo erano, da chiunque. Noi anche dicemmo che stavamo facendo così deliberatamente nella mailing list, in modo che non si sarebbe potuta perdere la puntualizzazione. Dopo un paio di giorni di concreta attività di Mike, qualcuno (non ricordo se era un collaboratore di CollabNet, o no) lo propose per l'accesso all'invio, e lui fu accettato, come sapevamo che sarebbe stato.
Questo tipo di coerenza vi dà una credibilità che il denaro non può mai comprare. E la credibilità è una moneta da avere nelle discussioni tecniche: è una immunizzazione contro il fatto di avere i propri motivi messi in discussione in un secondo momento. A caldo sembrerà che la gente vinca la battaglia con argomenti non tecnici. Il finanziatore principale del progetto, a causa del suo profondo coinvolgimento e dell'ovvio interesse alle direzioni che i progetto prende, presenta un obiettivo più grande degli altri. Essendo scrupolosi nell'osservare le linee guida del progetto sin dalla partenza, il finanziatore si fa grande quanto gli altri.
(Vedere anche il blog di Denise Cooper a
per una storia simile sull'accesso all'invio. Cooper era allora una “Diva Open Source”—ricordo che era il suo titolo ufficiale—e all'entrata del blog lei racconta come la comunità di sviluppo di Tomcat spinse Sun a mantenere i propri sviluppatori allo stesso standard di accesso all'invio degli sviluppatori non Sun.)
Il bisogno che i fondatori stiano alle stesse regole di chiunque altro significa anche che il modello di amministrazione della Benevola Dittatura (vedere
in ) è leggermente più difficile da far cadere in presenza di un finanziamento, specialmente se il dittatore lavora per il finanziatore principale. Siccome una dittatura ha poche regole, è difficile per il finanziatore provare che essa sta venendo governata secondo gli standard della comunità, anche quando lo è. E' certamente non impossibile; essa richiede appunto un leader del progetto che sia capace di vedere le cose dal punto di vista degli sviluppatori esterni, allo stesso modo di quelli del finanziatore, e agisca in accordo con essi. Anche allora, è probabilmente una buona idea avere propositi non dittatoriali sedendo al vostro posto, pronti a essere messi in evidenza nel momento di di qualche indicazione di diffuso malcontento nella comunità.
La Contrattazione
Il lavoro a contratto necessita di essere trattato con cura nei progetti di software libero. Idealmente voi volete che un lavoro di imprenditore sia accettato dalla comunità di sviluppo e impacchettato nella distribuzione pubblica. In teoria, non interesserebbe chi sia l'imprenditore, finché il suo lavoro è buono ed è fatto secondo le linee guida. Teoria e pratica possono a volte coincidere, anche: Un perfetto sconosciuto che si metta in evidenza con una buona patch,
sarà generalmente capace di metterla nel software. Il problema è, è molto difficile produrre una buona patch per una crescita non banale o una nuova funzionalità quando si è veramente un perfetto sconosciuto; uno deve prima discutere quella con il resto del progetto. La durata della discussione non può essere predetta con precisione. Se il lavoratore a contratto è pagato ad ore, voi potete concludere pagando più di quanto aveste previsto; se lui è pagato con una somma secca, può concludere facendo più lavoro di quanto possa produrre.
Ci sono due modi per aggirare questo. Quello preferito è quello di fare una erudita congettura sulla lunghezza della durata del processo di discussione, basata su passate a esperienze, aggiungere qualche riempitivo per errori, e basare il contratto su quello. Ciò aiuta anche a suddividere il problema in due pezzi quanto più piccoli possibile, per aumentare la possibilità di predire ogni pezzo. L'altro modo è contrattare solamente per il rilascio di una patch, e trattare l'accettazione delle patches nel pubblico progetto, come una questione separata. Allora diventa molto più facile scrivere un contratto, ma siete inceppati con il il carico di mantenere una patch privata tanto a lungo quanto dipendete dal software, o almeno tanto a lungo quanto ci vuole a inserire la patch o l'equivalente funzionalità nella linea principale. Certamente, anche con il modo preferito, il contratto stesso non può esigere che la patch sia accettata nel codice, perché ciò comporterebbe vendere qualcosa che non è in vendita. (Cosa accadrebbe se il resto del progetto decidesse di non supportare quella funzionalità?). Comunque il contratto può richiedere un sforzo bona
fide a far si che il cambiamento sia accettato dalla comunità, e che esso sia inviato al deposito se la comunità lo accetta. Per esempio, se il progetto aveva scritto standards riguardo ai cambiamenti al software, il contratto può far riferimento a quegli standards e specificare che il lavoro deve adattarsi ad essi. In pratica ciò si risolve nella maniera in cui uno spera.
La migliore tattica per contrattare con successo è ingaggiare uno degli sviluppatori del progetto preferibilmente uno con l'accesso all'invio come contraente. Ciò potrà sembrare una modo di comprare influenza, ebbene, lo è. Ma non è una forma corrotta come potrebbe sembrare. Una influenza di uno sviluppatore nel progetto e dovuta principalmente alla qualità del suo codice e alla sua interazione con gli altri sviluppatori. Il fatto che egli abbia il contratto per fare certe cose non eleva il suo stato in alcun modo, sebbene ciò possa far si che la gente lo osservi con più attenzione. La maggior parte degli sviluppatori non rischiano la loro posizione a lungo termine sostenendo una funzionalità fuori luogo o che non piace a molti. Infatti, ciò che conseguite, o dovreste conseguire quando assumete tale persona a contratto è il parere su quale sorta di cambiamento è verosimilmente accettato dalla comunità. Voi anche pervenite a un leggero cambiamento nelle priorità del progetto. Poiché l'elenco delle priorità è giusto una materia di chi ha tempo di lavorare a qualcosa, quando pagate per il tempo di qualcuno, voi fate sì che il suo lavoro salga un poco nella coda delle priorità. Questo è un ben compreso fatto di vita fra gli sviluppatori esperti open source, e almeno qualcuno di essi dedicherà attenzione al lavoro del lavoratore a contratto semplicemente perché sembra che ciò debba essere fatto, in modo tale che che essi si adoperano a che sia fatto bene. Forse essi non scriveranno nulla del codice, ma tuttavia discuteranno del progetto e della revisione del codice, ambedue delle quali cose possono essere molto utili. Per tutte queste ragioni, il lavoratore a contratto è dipinto al meglio dai ranghi di quelli già coinvolti nel progetto.
Ciò solleva immediatamente due questioni: i lavoratori a contratto devono essere sempre privati? E quando no lo sono, dovete preoccuparvi per il fatto che potreste creare delle tensioni nella comunità per il fatto che avete fatto contratti con alcuni e non con altri?
La cosa migliore è essere aperti sui contratti, quando potete. Diversamente il comportamento del lavoratore a contratto può sembrare strano agli altri nella comunità può darsi il suo dare improvvisamente e inspiegabilmente priorità a funzionalità per le quali non aveva mai avuto interesse in passato. Quando le persone gli chiedono perché le vuole ora, come può egli rispondere in modo convincente se non può parlare del fatto che è stato assunto per scriverle?
Allo stesso tempo nè voi né il lavoratore a contratto dovreste agire come se gli altri dovrebbero considerare il vostro aggiustamento come un buon affare. Troppo spesso io ho visto lavoratori a contratto ballare il valzer nella mailig list dello sviluppo con l'atteggiamento che i loro posts dovrebbero essere presi più seriamente solamente perché pagati. Questo tipo di atteggiamento dà il segnale al resto del progetto che il lavoratore a contratto guarda al fatto del contratto come opposto al codice risultato del contratto—essere la cosa più importante. Ma dal punto di vista degli altri sviluppatori, solo il codice conta. Sempre, il fuoco dell'attenzione dovrebbe essere mantenuto sugli aspetti tecnici, non sui dettagli di chi ha pagato chi. Per esempio, uno degli sviluppatori nella comunità di Subversion tratta il contratto in una particolare graziosa maniera. Mentre discute i suoi cambiamenti in IRC egli vuol far menzione a parte (spesso in una privata osservazione, un privmsg, su IRC ad uno degli altri con accesso all'invio) che lui è stato pagato per il suo lavoro su questo particolare bug o funzionalità. Ma egli da anche tangibilmente l'impressione che avrebbe accettato di lavorare a quel cambiamento comunque, e che è felice che il denaro stia rendendogli possibile fare ciò. Egli può o non può rivelare la sua identità individuale, ma in ogni caso non si sofferma sul contratto. Le sue osservazioni su questo sono giusto un ornamento per una discussione diversamente tecnica su come fare qualcosa.
Questo esempio mostra un'altra ragione per cui è bene essere aperti sui contratti. Ci possono essere molte organizzazioni che sponsorizzano i contratti su un progetto open source, e se una conosce ciò che le altre stanno cercando di fare, esse possono essere in grado di mettere insieme le loro risorse. Nel caso sopra, il più grande finanziatore (CollabNet) non è coinvolto in ogni modo con questi contratti di lavoro a cottimo, ma la conoscenza che qualche altro sta sponsorizzando alcune correzioni di bugs permette a CollabNet di reindirizzare le sue risorse verso altri bugs, col risultato di una maggiore efficienza per il progetto nella sua interezza.
Si offenderanno alcuni sviluppatori perché altri sono pagati per lavorare al progetto? In generale, no, specialmente quando quelli che sono pagati sono stabilizzati, rispettati membri della comunità comunque. Nessuno si aspetta che il lavoro a contratto sia distribuito in modo uniforme fra tutti coloro che fanno gli invii. La gente capisce l'importanza di una relazione a lungo termine: le incertezze connesse col contratto, sono tali che una volta che hai trovato uno con cui poter può lavorare affidabilmente, sareste riluttanti a passare ad un'altra persona giusto a scopo di egualitarismo. Pensate a ciò così: la prima volta che ingaggiate, non ci saranno lamentele, perché chiaramente dovete scegliere
qualcuno—non è una vostra mancanza il fatto che non potete prendere tutti. Più tardi, quando ingaggiate qualcuno per la seconda volta, questo è giusto il sentire comune: già lo conoscete, l'ultima volta con successo, così perché correre rischi non necessari. Così, è perfettamente naturale avere una o due persone cui rivolgersi nel progetto, invece di distribuire il lavoro uniformemente.
Finanziare Attività di Non Programmazione
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.
La Garanzia Della Qualità (cioè, Eseguire Prove Professionali)
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.
La Consulenza Legale e la Difesa
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 . 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à
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.
Procurare l'Hosting/Banda
Per un progetto che non stia usando un hosting confezionato gratuito (vedere
in
), 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.
Il Marketing
Sebbene la maggior parte degli sviluppatori non gradirebbero ammetterlo, il marketing funziona. Una buona campagna di marketing
può creare un ronzio intorno a un prodotto open source, anche al punto che avveduti codificatori si trovano che essi stessi ad avere pensieri vagamente positivi sul software anche per ragioni sulle quali non possono assolutamente mettervi le dita. Non spetta a me dissertare la dinamica della corsa agli armamenti del marketing in generale. Ogni compagnia coinvolta in software libero si troverà alla fine a considerare come mettere in commercio se stessa, il software e le sue relazioni col software: Il consiglio di sotto riguarda come evitare trabocchetti in tale impegno; vedere anche
in
.
Ricordate Che Siete Osservati
Nell'intento di mantenere dalla vostra parte la comunità degli sviluppatori volontari èmolto importante non dire ciò non sia in modo dimostrabile vero. Verificate tutte le affermazioni con cura, prima di farle e date al pubblico i mezzi per verificare le vostre affermazioni da se. La verifica indipendente dei fatti è una parte importante dell'open source e si applica a molto più che al solo codice.
Naturalmente nessuno consiglierebbe alle compagnie di fare affermazioni non verificabili comunque. Ma con le attività open source, c'è una insolita gran quantità di gente con l'esperienza per verificare le affermazioni le persone che trovano conveniente anche avere un accesso a internet a larga banda e i giusti contatti sociali per pubblicizzare le sue conclusioni in un modo da danneggiare, dovrebbero sceglierlo loro. Quando la Global Megacorp Chemical Industries inquina un corso d'acqua, questo è verificabile, ma solo da parte di scienziati esperti, lanciando alla gente di grattarsi la testa e di chiedersi cosa pensare. Invece il vostro comportamento nel mondo dell'open source non è solo visibile e registrato; è anche possibile per molta gente verificarlo indipendentemente, pervenire alle proprie conclusioni e propagare quelle conclusioni per via orale. Queste reti di comunicazioni sono già in piedi; esse sono l'essenza di come l'open source opera, e possono essere usate per trasmettere ogni sorta di informazione. La confutazione è usualmente difficile, se non impossibile, specialmente quando ciò che la gente sta dicendo è la verità.
Per esempio è giusto riferire alla vostra organizzazione di aver “fondato il progetto X” se realmente lo avete fatto. Ma non fate riferimento a voi stessi come i “costruttori di X” se la maggior parte del codice è stato scritto da estranei.
Al contrario, non proclamate di aver profondamente coinvolto una comunità di sviluppatori volontari se chiunque può vedere nel vostro deposito e constatare che ci sono pochi o nessun cambiamento al codice provenienti dal di fuori della vostra organizzazione.
Non molto tempo fa, vidi un annuncio da parte di una ben nota compagnia, che affermava che la compagnia stava rilasciando un importante confezione di un software sotto una licenza open source. Quando l'annuncio iniziale uscì, diedi un'occhiata al deposito del controllo della ora pubblica versione e vidi che conteneva solo tre revisioni. In altre parole quelli avevano fatto una importazione iniziale del codice sorgente, ma difficilmente qualcosa era avvenuta da allora. Cosa che in se stessa non era —quelli avevano fatto solo un annuncio dopotutto. Non c'era motivo di aspettarsi una grande attività di sviluppo immediatamente.
Qualche tempo più tardi, quelli fecero un altro annuncio. Questo è quello che diceva, con il nome e il numero di versione sostituiti da pseudonimi:
Abbiamo il piacere di annunciare che in seguito a rigorosi tests da parte della Singer Community, Singer 5 per Linux e Windows sono pronti per scopi di produzione.
Curioso di sapere cosa la comunità avesse scoperto “nei rigorosi tests” ritornai al deposito a vedere la storia dei loro cambiamenti recenti. Il progetto era ancora alla revisione 3.
Apparentemente non avevano trovato una sola correzione di bug di pregio prima della release. Pensando che il risultato dei tests della comunità potessero essere stati registrati altrove, esaminai il tracciatore di bugs. Li c'erano esattamente aperti 6 problemi, 4 dei quali erano stati aperti ormai per diversi mesi.
Questo è incredibile, certamente. Quando i collaudatori controllano su un grande e complesso pezzo di software per un certo tempo, troveranno bugs. Anche se le correzioni di questi bugs non lo trasformano nella prossima release, uno tuttavia si aspetterebbe qualche attività di controllo della versione come risultato del processo di prova, o almeno qualche nuovo problema. Eppure a tutta apparenza, niente era avvenuto tra l'annuncio della licenza open source e le prima release open source.
Il punto non è che la compagnia stava mentendo sull'attività di prova della comunità. Non ho idea se lo stesse facendo o no. Ma essi erano ignari di quanto sembrava verosimile che essi stavano mentendo. Siccome né il controllo di versione né il deposito di controllo né il tracciatore di problemi davano indicazione che le asserite prove erano avvenute non avrebbero dovuto fare l'affermazione in primo luogo, o avrebbero dovuto fornire un link a qualche tangibile risultato di quelle prove (“Abbiamo trovato 287 bugs; cliccare qui per i dettagli”). La seconda cosa avrebbe permesso a chiunque di capire il livello dell'attività della comunità molto velocemente. Così com'era mi ci vollero pochi minuti per determinare che qualunque cosa fosse questa comunità di prova, non aveva lasciato tracce in nessuno dei posti usuali. Quello non fu un grande sforzo, e sono sicuro che non sono il solo che si prese il disturbo.
La trasparenza e la possibilità di verifica sono anche una parte importante della credibilità, certo. Vedere
in
per maggiori informazioni su questo.
Non Colpite Il Prodotto Open Source Concorrente
Astenetevi dal dare cattive opinioni sul software open source concorrente. E' perfettamente giusto fornire
fatti —negativi cioè affermazioni facilmente confermabili del tipo spesso visto in buoni quadri comparativi. Ma caratterizzazioni di natura meno rigorosa è meglio evitarle, per due ragioni. Primo, esse possono portare a guerre di ingiurie che distolgono da discussioni produttive. Secondo, e più importante, alcuni dei vostri sviluppatori volontari nel vostro progetto possono anche allontanarsi per lavorare al progetto concorrente. Ciò è più probabile di quando potrebbe sembrare in un primo momento: i progetti sono già nello stesso dominio (che è il motivo per cuoi sono in competizione), e sviluppatori con esperienza in quel dominio possono dare contributi dovunque la loro esperienza è applicabile. Anche quando non c'è una diretta sovrapposizione di sviluppatori è probabile che gli sviluppatori del vostro progetto abbiano familiarizzato con gli sviluppatori del progetto affine. La loro capacità di mantenere rapporti costruttivi personali potrebbe essere intralciata da messaggi negativi di marketing.
Primo, esse possono portare a guerre di ingiurie che distolgono da discussioni produttive. Secondo, e più importante, alcuni dei vostri sviluppatori volontari nel vostro progetto possono anche allontanarsi per lavorare al progetto concorrente. Ciò è più probabile di quando potrebbe sembrare in un primo momento: i progetti sono già nello stesso dominio (che è il motivo per cuoi sono in competizione), e sviluppatori con esperienza in quel dominio possono dare contributi dovunque la loro esperienza è applicabile. Anche quando non c'è una diretta sovrapposizione di sviluppatori è probabile che gli sviluppatori del vostro progetto abbiano familiarizzato con gli sviluppatori del progetto affine. La loro capacità di mantenere rapporti costruttivi personali potrebbe essere intralciata da messaggi negativi di marketing. Colpire prodotti closed source concorrenti sembra essere largamente accettato nel mondo open source, specialmente quando questi prodotti sono creati dalla Microsoft. Personalmente io deploro questa tendenza (sebbene d'altra parte non ci sia nulla di sbagliato nella chiara comparazione dei fatti), non solo perché è rozzo, ma anche perché è dannoso per un progetto partire credendo che ciò sia una propria pubblicità e quindi ignorare i modi in cui la competizione può essere veramente migliore. In generale guardatevi dagli effetti che le leggi del marketing possono avere sulla vostra comunità di sviluppo. La gente può venire così eccitata nell'essere sostenuta dai dollari del marketing da perdere la propria obiettività sulle vere solidità e debolezze del suo software. E' normale, e anche previsto, per una compagnia di sviluppatori esibire un certo distacco nei confronti delle leggi del marketing, anche in forum pubblici. Chiaramente essi non dovrebbero venir fuori e contraddire il messaggio di marketing direttamente (a meno che esso non sia veramente sbagliato, tuttavia uno spera che quel tipo di cosa dovrebbe essere scoperta prima). Ma possono prendersi gioco di questo, di volta in volta, come modo per riportare il resto della comunità di sviluppo sulla terra.