Capitolo 5. 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.