Comunità Open Source, istruzioni per l’uso
Spesso le persone domandano che cosa serva per far nascere una comunità open source. Se vi siete posti questa domanda almeno una volta, questo articolo è per voi.
Un pò di storia
Per fornire una prospettiva storica sull’argomento si raccomanda innanzi tutto la lettura di un articolo di Brian Behlendorf intitolato “Open Source as a Business Strategy“. In particolare il paragrafo sul bootstrapping costituisce una buona base di partenza per capire quanto impegno sia necessario per avviare e mantenere una strategia open source per la produzione del proprio codice.
Svendere i gioielli di famiglia
Dando per scontato che il lettore conosca la importanza delle caratteristiche differenzianti (Bruce Perens), e che quindi non ci sia alcun rischio concreto di ‘svendere i gioielli di famiglia’, approfondiamo in quali casi valga la pena considerare di condividere il proprio codice. La ragione principale per volerlo condividere riguardano i risparmi che ne possono derivare nella manutenzione del codice e l’open innovation. Per semplicità ignoreremo motivazioni di natura tattica, quale ad esempio l’effetto promozionale associato alla distribuzione in open source.
Prestito o condivisione
Esistono due tipi di approcci: prendere a “prestito” codice open source esistente e realizzato da terzi, oppure realizzarne di nuovo e condividerlo. Sebbene prenderlo a prestito possa sembrare una cosa estremamente semplice, occorre investire risorse nella valuatazione e selezione di software open source, ma effettivamente non è necessario investire tempo nella costruzione di una comunità open source. Tali comunità infatti già esistono, e tutto ciò che occorre fare è semplicemente parteciparvi. Interagire con una comunità è semplice se tutto ciò che volete è chiedere un consiglio o aprire un ticket, è sufficiente rispettare la classica netiquette.
Più complesso è invece fare in modoche la propria patch venga accettata. Alcuni progetti open source, specialmente quelli sviluppati sotto l’egida di una fondazione, forniscono documentazione dettagliata su come funzioni la loro architettura di partecipazione. In generale non è così facile capire come funzioni una comunità open source finché non si inizia a collaborarvi attivamente. Ciò detto esistono una serie di errori che è possibile evitare, tra cui:
– Rilasciare il proprio contributo senza che sia stato preceduto da precedenti comunicazioni, per cui si consiglia sempre di rilasciare codice in maniera progressiva;
– Essere troppo pressanti nel richiedere che il proprio contributo venga considerato per l’inclusione;
– Avere qualcuno all’interno della propria organizzazione che si occupi di sviluppare una relazione con la comunità di interesse;
– Non “forkare” a tutti i costi, la manutenzione diverrebbe inutilmente onerosa.
Condividere il proprio codice è senz’altro più complicato, e può costituire una delle vostre “Key Activities”, ovvero un elemento del vostro business model. Si rammenta che volutamente non stiamo considerando motivazioni tattiche per il rilascio in open source, come ad esempio una scelta marketing.
Sebbene molto open source nasca per “scratching your itch” – si legga in proposito “The Cathedral and the Bazaar” di Eric Raymond – questo proprio bisogno può non essere interessante per altri e quindi non costituire un buon motivo per unirsi alla vostra neonata community. Prima di voler condividere il vostro codice vorrete aver risposto alle seguenti domande:
– Esiste già del codice che risolve lo stesso problema? E se esiste, in che modo il vostro risulta “diverso”?
– Come avete intenzione di gestire la proprietà intellettuale? Quale licenza, e cosa richiederete a chi vuole contribuire alla vostra community?
– Definirete la vostra architettura di partecipazione partendo da zero, oppure prenderete ispirazione da altre community?
– Volete sottoporre il vostro progetto a qualche fondazione? Oppure volete crearne una nuova?
Colonizzare la “noosfera” non è facile, e se volete avvicinare altri sviluppatori al vostro progetto dovete sapere come avvicinare sviluppatori con i vostri stessi interessi. Essere dei first-mover può facilitare, ma non è garanzia di successo. Di contro se volete essere appetibili nonostante esistano soluzioni open alternative dovete capire e comunicare bene quale sia il plus offerto dalla vostra soluzione.
La gestione della “proprietà intellettuale”è fondamentale per realizzare una comunità sostenibile, e non potete aspettarvi che terzi si uniscano a voi se non è chiaro a quali condizioni rendete disponibile il vostro codice e cosa occorre fare per divenire un membro della vostra comunità. Non è questa la sede per descrivere tutte le possibili licenze open source, si consiglia la lettura di alcuni ottimi articoli, come anche l’uso di strumenti per comparare le licenze ed altro ancora. Riteniamo che esistano numerose risorse liberamente disponibili affinché possiate farvi una idea precisa a riguardo. Ultimo ma non ultimo potreste sempre lasciarvi la porta aperta per scegliere la licenza in un momento successivo, sempre che abbiate adottato una politica di Contribution Agreement che vi lasci tale libertà.
Diritto d’autore. Quando si tratta di stabilire come il copyright venga gestito ci sono due possibilità: richiedere ai contributori di adottare la licenza da voi scelta e conseguentemente di rilasciare i loro contributi con tale licenza, oppure attribuire il loro diritto d’autore al progetto. Al di là di quale sia l’approccio da voi scelto, vale la pena sottolineare che chiedere o non chiedere ad un contributore di firmare un contratto fa differenza. Sia chiaro, se volete riservarvi il diritto di cambiare licenza non avete altra strada, ma è bene essere consapevoli di quanto questo costituisca un disincentivo alla partecipazione. Sull’argomento una lettura che vi consiglio è la guida ai Contributor agreements, e come scegliere il vostro contributor agreement. Laddove i vendor tendono ad essere estremamente conservativi nella tutela della proprietà intellettuale, numerosi sono i progetti di comunità che non richiedono alcuna formalità per la partecipazione.
