Apache CouchDB – come mi è successo di diventare committer in un progetto Apache

Mentre me ne sto qui a respirare e rilassarmi in un comodo terrazzo vista mare a Punta Ala, che non posto per non farvi rodere troppo (heheh), ripenso a come sono andate le cose finora nell’ultimo anno e a uno degli eventi che mi hanno segnato nel profondo e che è passato, tutto sommato, troppo sotto silenzio. Sono infatti diventato committer presso la Apache Software Foundation, nello specifico sul progetto CouchDB che ormai è una delle mie fucine preferite in termini di buon codice e soprattutto buone idee.

È stato veramente un onore e soprattutto un privilegio inaspettato per me ricevere l’email di Joan Touzet, PMC member di CouchDB, che mi invitava a diventare committer del progetto dati i miei sforzi – soprattutto continui nel tempo – per quanto riguarda la suite di test d’integrazione. Non me l’aspettavo! Ed è veramente indice, almeno secondo la mia prospettiva, di quanto sia sana la fondazione Apache nel riconoscere il valore di contributi di qualsiasi tipo.

Ma che cosa fa un committer di preciso?

Il lavoro di un committer non è diverso da quello di un contributor individuale, l’unica differenza sta nel fatto che con i suoi contributi continuati nel tempo si è guadagnato il diritto di scrivere direttamente sulla codebase del progetto senza passare da meccaniche come i fork per aprire pull request o mandare patch agli autori del software stesso. Inoltre, può declinare, richiedere cambiamenti o approvare le patch degli altri contributor e votare quando vengono indette le votazioni, quindi aumenta esponenzialmente l’area di impatto che l’individuo ha con i suoi contributi sul progetto, a tutto tondo.

Join Apache, ovvero se ti interessa uscire fuori dalla comfort zone eccoti servito

La mia prima patch per un progetto Apache l’ho letteralmente scritta sul letto di una stanza d’albergo. La seconda mentre ero su un volo di linea. L’importante è trovare qualcosa per cui si ha un punto debole (che al tempo per me era Elixir) e scegliersi un progetto che supporti quella determinata pratica o quella determinata tecnologia. Io volevo approfondire Elixir usato in un contesto di produzione, e volevo farlo su un progetto:

• Che avesse valore;
• Che mi permettesse di uscire fuori dal seminato;

Direi che l’investimento mi ha ripagato, ho contribuito a un database e ho avuto l’opportunità grazie al mio coinvolgimento di farmi svariate chiacchiere col team di sviluppo, cosa che per una persona che normalmente fa web, API e cose del genere non è per niente da buttare.

Oltre questo, durante l’ultimo Microsoft Build ho avuto l’opportunità di parlare insieme a Piergiorgio di quanto sia emozionante lavorare per un’istituzione che rompe gli schemi della produzione tradizionale del software da così tanto tempo e in modo così dirompente :-)))

Iniziare è molto semplice: i passi di base sono descritti nel “Getting Started”, anche se per me si riduce tutto al trovare il giusto spazio attraverso la directory dei progetti, che è filtrabile per linguaggio. Ci troverete senza dubbio qualcosa di superfico, altrimenti potete scrivermi a [email protected] per avere indizi su qualcosa di semplice da pescare su CouchDB, o servirvi per conto vostro sui miei repository preferiti, quello di CouchDB e quello di Fauxton, la UI web :-D