Chi non segue da vicino questo “mondo” può avere la sensazione che i progetti open comunitari spuntino semplicemente fuori dal nulla, come conigli dal cilindro magico di abili (o meno) sviluppatori. In realtà le cose vanno in maniera molto diversa. Il percorso che porta al successo di progetti di questo tipo è solitamente molto lungo e attraversato da diverse fasi cruciali, punti di snodo che possono decretarne l’ascesa o il rapido declino.
Uno schema ricorrente che si trova spesso ad osservare è quello di uno sviluppatore o di un gruppo molto ristretto di sviluppatori che iniziano a forgiare uno strumento per risolvere un problema comune.
Il primo punto di snodo è l’interesse generato dal progetto. L’interesse per un progetto può essere spinto da motivi diversi che svariano dalla bontà tecnica alla missione filosofico politica. Quasi tutti i progetti nascono da una commistione di queste due forze con apporti differenziati in base al progetto. Per esempio il progetto GNU è nato principalmente sotto una forte spinta filosofica e politica ma nel tempo ha saputo fornire strumenti tecnologicamente avanzati. Un altro progetto più attuale spinto da necessità non strettamente tecniche è DIASPORA* finanziato attraverso la piattaforma kickstarter. Senza nemmeno una riga di codice mostrata, con un semplice video in cui dichiarano di voler liberare il concetto di social network da quello di hub centralizzato (alla Facebook),sono riusciti a garantirsi 200’000$ e un enorme eco mediatico.
Dall’altra parte della barricata ci sono i progetti nati dalla voglia di proporre qualcosa di nuovo, tecnicamente eccellente e all’avanguardia. Ne è l’esempio lampante il progetto Gentoo iniziato da Daniel Robbins con l’idea di produrre una distribuzione completamente incentrata sulle prestazioni(qui potete leggere la storia della nascita di Gentoo).
Il secondo punto cruciale riguarda l’organizzazione. Il successo di un progetto open va gestito. Successo in questo ambito, almeno inizialmente, significa principalmente massa di sviluppatori; sviluppatori che spesso sono uniti dalla volontà di contribuire ma separati da migliaia di chilometri. Per questo motivo la comunicazione richiede l’utilizzo di strumenti collaborativi che in qualche modo attenuino le distanze. Solitamente per la parte di comunicazione gli strumenti più utilizzati sono due: una mailing list per le discussioni a medio lungo termine e IRC per le discussioni in tempo reale. IRC oltre ad essere utile come strumento di comunicazione per il progetto permette ai membri del team di conoscersi meglio. Chiunque abbia frequentato un qualsiasi canale IRC per un periodo di tempo sa di cosa sto parlando. A questo punto siamo arrivati a quello che proprio non può mancare a nessun progetto software: il codice. Far lavorare più persone, sparse per il mondo, su una base di codice comune non è un compito semplice. Come al solito però la tecnologia viene in aiuto. Se siete programmatori avrete sicuramente usato o sentito parlare dei vari subversion, mercurial, git e simili. Si tratta di strumenti di versioning del codice centralizzati o distribuiti che permettono con una discreta agilità di gestire situazioni di questo tipo.
La terza sfida di un progetto open è quella di mantenersi realmente aperti. Se questa frase vi ha spiazzato non vi preoccupate… era nelle mie intenzioni farlo. Troppo spesso si vedono progetti sviluppati con licenze OSI senza che però se ne sfruttino a pieno le potenzialità. Un progetto open deve saper accettare (non necessariamente includere) i contributi esterni e deve rendere la partecipazione un processo piacevole. Una buona documentazione del progetto in questo senso è molto utile. Per la documentazione nell’ambito dello sviluppo collaborativo vengono spesso utilizzate piattaforme per wiki come MediaWiki o dokuwiki. Altro strumento utile in questo campo sono i bug tracker di cui ho parlato in un precedente articolo qui su AD.
A questo punto il progetto è pronto ad evolvere. Ma in quale direzione?
Questa domanda ci porta diretti al quarto punto cruciale: la guida del progetto. La guida del progetto è forse l’unico punto in cui si possono trovare tantissime sfumature. Ci si muove in un campo che va dai Benevoli dittatori a vita, ad organi democratici con vere e proprie elezioni come nel caso di Debian. Nel mezzo ci sono tutte le situazioni intermedie, come quelle dei progetti guidati da importanti aziende.
Se volete iniziare un progetto open ed avete iniziato a mettere su una struttura organizzativa degna di un comitato olimpico fermatevi subito. Tutti i punti che ho citato in precedenza vanno considerati nel momento in cui serviranno. È bene conoscerli e tenerli a mente ma è assolutamente controproducente seguirli tutti prima di aver scritto una linea di codice. In questo, come in qualsiasi altro ambito, il buon senso è la regola numero 0, quella che nessuno scrive perché scontata ma che secondo me vale sempre la pena ricordare.
Per concludere l’articolo vi lascio con un video che rappresenta l’evoluzione temporale di un progetto importante come python. Il video da l’idea di quanto tempo serva prima che un progetto open raggiunga la massa critica per fare la differenza. Buona Visione.
