Open Source: non è così spaventoso!

Quanto segue è stato pubblicato prima del lancio di Toptal Scholarships for Female Developers.

Come sviluppatore, è entusiasmante e stimolante rimanere al passo con le ultime tendenze tecnologiche. Ogni giorno, nuovi linguaggi, framework e dispositivi catturano la nostra attenzione e stimolano le conversazioni in meetup, forum e chat. Tuttavia, la nostra community di sviluppatori è fatta di persone, non di strumenti, ed è affascinante esplorarne gli aspetti sociopolitici (per mancanza di una parola migliore; "social" tende ad essere associato ai social network, di questi tempi).

In Toptal, abbiamo recentemente avuto alcune conversazioni interessanti su quanto le donne contribuiscono all'open source e cosa potrebbe impedire loro di contribuire di più, quindi abbiamo studiato la questione. Avendo preso parte a quella conversazione con Breanden Beneschott e Bozhidar Batsov, mi sono chiesto: Bozhidar è uno dei principali contributori open source su GitHub. Dove sono? Se controlli il mio account GitHub pubblico ad oggi, sono principalmente piccoli progetti di test che ho usato in classe per i miei studenti. Sono a metà cottura e sicuramente non rappresentano le mie capacità o competenze. (Dovrai credermi sulla parola.) Se qualcuno prendesse in considerazione l'idea di assumermi in base a ciò che possono trovare in quell'account, suppongo che avrei difficoltà a guadagnarmi da vivere. Tuttavia, sono uno sviluppatore professionista da più di 20 anni e nel mio lavoro quotidiano utilizzo più software open source di quanto mi tenga a ricordare. Nel corso del tempo, ho violato il kernel Linux per piegarlo a qualche esigenza specifica, modificato tutti i router e i NAS che ho acquistato, ho aspettato pazientemente per mesi nella lista d'attesa di Raspberry Pi per metterci le mani sopra e ottenere la mia domotica fatta in casa come Mi piace. Tuttavia, nessuna di queste modifiche e test è mai arrivata sul mio GitHub per diventare open source. Inoltre, oltre a correggere un bug in una delle prime versioni di Tomcat, non ho mai contribuito a un progetto open source. Curioso, vero?

Potresti pensare che sia solo mancanza di tempo o di interesse, ma so che non lo è. Per quanto riguarda i miei progetti personali, forse ho pensato che a nessuno potesse interessare davvero quello che ho fatto, ma soprattutto è solo che l'idea stessa di pubblicare il mio lavoro lì, affinché tutti lo vedano e per i posteri, mi spaventa molto. E mentre puoi sempre smontare un progetto personale da GitHub, il giorno in cui provi a contribuire a un progetto open source ampiamente disponibile, non puoi tornare indietro. E se il mio codice non è abbastanza buono? E se non avessi compreso correttamente il problema? Cosa succede se la mia richiesta pull viene rifiutata? E se le persone mi trollassero?

Un veloce giro di chiamate con colleghi sviluppatori amici, per lo più donne, mi ha presto convinto che non sono l'unico ad avere questo problema, ma per un ingegnere non ci sono problemi, solo soluzioni, giusto?

Questo è un problema importante da risolvere, perché contribuire a un progetto open source può fare una differenza drammatica:

• Durante la tua carriera : molti clienti guarderanno tutto ai tuoi social prima di decidere di assumerti; il tuo account GitHub e il tuo curriculum LinkedIn sono in cima alla lista, insieme ai tuoi profili Facebook e Twitter. Dovresti usarli con saggezza.
• Per le tue capacità tecniche : esaminare una base di codice scritta da altri sviluppatori, e spesso molto bravi, ti insegna molto. La capacità di districare il significato da una base di codice scritta male ti sfiderà e ti insegnerà altrettanto.
• Per le tue competenze trasversali : il software open source è un processo collaborativo e quasi tutti i progetti interessanti là fuori sono costruiti da team. Imparare a lavorare con altri sviluppatori attraverso gli strumenti che tutti usano, a integrarsi con il team, a comunicare in modo efficiente, è ciò che ti renderà un grande sviluppatore, non solo un abile.
• Per la comunità : ogni singolo bit che contribuisci a un progetto open source conta. Più contribuisci meglio è, ma anche correggere un piccolo errore di battitura in una traduzione migliorerà il prodotto finale.
• Per la tua rete : puoi inviare centinaia di curricula alle aziende, ma niente funziona come avere colleghi con connessioni personali. Essere coinvolti attivamente in un progetto open source ti assicurerà di incontrare persone e ottenere il loro rispetto, e la tua reputazione crescerà, il che è prezioso per qualsiasi professionista.

Questo è il mio piccolo viaggio personale per combattere questa paura. La pubblicazione di questo articolo fa parte del viaggio stesso. Lo scrivo nella speranza che chiunque sia bloccato a scrivere un post sul blog, o abbia paura di dare anche un piccolo contributo, veda che alla fine non è stato così spaventoso. Inoltre, ha lo scopo di aiutare chiunque vorrebbe contribuire all'open source, ma non sa davvero da dove cominciare, quindi inizierò con le basi.

Che cos'è un software open source e dove lo trovo?

Il software open source, o OSS in breve, è qualsiasi software rilasciato con il suo codice sorgente e include una licenza che consente di modificarlo e ridistribuirlo. Può essere consegnato ovunque: su un sito web, tramite una mailing list o con un gufo. Lo scenario più comune, e quello che ci interessa, è quando la codebase viene mantenuta su un repository collaborativo. Qui ci stiamo concentrando su GitHub, ma ci sono altre opzioni, come SourceForge e Bitbucket. GitHub è molto amichevole, ha un'enorme base di utenti, può essere utilizzato per qualsiasi tipo di codice e con qualsiasi ambiente di sviluppo che utilizzi. È importante sottolineare che è anche ampiamente utilizzato per progetti non open source. È probabile che il tuo prossimo progetto cliente sarà ospitato lì, quindi sapere come lavorarci è di per sé un'abilità utile.

E se non so codificare?

Se stai leggendo questo, è probabile che tu voglia imparare a programmare. Puoi trovare fantastici corsi su diversi siti Web gratuiti ea pagamento. Dovresti scegliere una lingua da imparare; se non hai una preferenza, vai con JavaScript. Hai già tutto ciò di cui hai bisogno per iniziare sul tuo browser web ed è una delle competenze più utilizzate e commerciabili. Il mio preferito è Python, che viene utilizzato sia nello sviluppo web che nelle applicazioni scientifiche. Inoltre, ho un corso per principianti preferito, "Intro to Computer Science" su Udacity. Mi piace perché è un corso pratico, in cui lavori su un progetto mentre impari. Puoi anche trovare molti altri corsi su Coursera, Khan Academy e PluralSight.

E se non conosco Git?

Come accennato in precedenza, conoscere Git è importante, quindi prendi un corso di Git. Fallo anche se lavori con Git da un po'; non sai quanto non sai di Git finché non lo studi davvero. Fallo se non riesci a spiegare con sicurezza cosa fa il comando rebase . Fallo anche se un rebase sbagliato non ti spaventa. Ho seguito il percorso completo di Git su Code School, ma ancora una volta puoi esplorare altri siti per ulteriori opzioni.

Come faccio a scegliere un progetto su GitHub?

È probabile che tu usi alcuni OSS nel tuo sviluppo quotidiano. La scelta di un framework familiare è un buon punto di partenza; hai già familiarità con le funzionalità e come funziona il framework. Quando ti immergi nel codice sorgente, imparerai di più e ne capirai la logica ancora più chiaramente. Se c'è una tecnologia o uno strumento che ti piace particolarmente, cerca i progetti che ne fanno menzione o il progetto dello strumento stesso. Come ultima risorsa, puoi controllare i progetti su GitHub Showcases e iniziare scegliendo una categoria che ti interessa.

Ad esempio, una rapida ricerca di "Raspberry" nella ricerca di GitHub mostra più di 17mila repository. È facile perdersi, quindi cerca un progetto con una buona community e un buon monitoraggio dei problemi. Quando scegli un progetto, controlla il numero di:

• Contributori : scegli come target qualcosa di più di dieci contributori. Ciò dovrebbe garantire che il progetto abbia abbastanza interesse e non sia semplicemente un piccolo sforzo di squadra. Se sei nuovo in OSS, o non troppo esperto, limita la tua ricerca a progetti con al massimo cinquanta contributori; comunità più grandi implicano basi di codice più grandi e progetti più complicati.
• Impegni : scegli progetti che hanno almeno mille impegni e in cui l'attività più recente non ha più di una settimana. Un progetto che è stato inattivo per un mese o più è vecchio e stantio in termini di OSS e probabilmente non riceverai risposte rapidamente. L'attività quotidiana è il segno di un progetto sano.
• Problemi : i problemi sono problemi aperti, bug che sono stati segnalati o funzionalità richieste per l'implementazione. Ti daranno un punto di partenza e sono una buona metrica dell'interesse per il progetto.

Inoltre, scopri qual è la lingua principale del progetto; puoi vedere le statistiche della lingua nella barra in alto della pagina principale del progetto. Prenditi del tempo per leggere il tono della discussione, vedere quanto sono amichevoli e istruiti i commenti. Alcuni progetti sono famigerati per le loro comunità aggressive, quindi potrebbero non essere il punto di partenza giusto.

Ho scelto ScyllaDB, un progetto di archiviazione dati a colonne, dal momento che ho un fascino per i dati, tutto ciò che è correlato alle prestazioni. Non ci ho mai lavorato, ma mi aspetto di essere in grado di immergermi nella sua base di codice. Può essere più semplice lavorare con gli strumenti che conosco, ma la sto prendendo come una sfida e un'occasione per imparare qualcosa di nuovo. Per il resto, si adatta perfettamente al conto; ha 18 contributori, 6.5k commit (il più recente è stato 23 ore fa al momento della scrittura), 178 problemi aperti e sembra attivo.

Cosa faccio ora?

Innanzitutto, clona il repository e installa il software sulla tua macchina per avere un'idea delle sue parti mobili. Quindi, inizia a leggere i problemi. Una volta che ti senti pronto, verifica se riesci a riprodurre il problema sulla tua macchina e quindi inizia ad analizzare ciò che causa il comportamento anomalo del software.

Un altro approccio sarebbe trovare qualcosa che puoi migliorare o modificare da solo. Forse hai notato un errore di battitura o un carattere disallineato, per esempio. Ho scelto di correggere un piccolo bug, in particolare un nome di variabile errato utilizzato nella documentazione di uno script.

Sembra minuscolo, ma una documentazione errata è molto peggio di nessuna documentazione. Gli utenti installeranno ScyllaDB e seguiranno i passaggi di installazione, faranno affidamento ciecamente su ciò che è scritto in quello script e finiranno in un mucchio di frustrazione. Questo era perfetto per le mie capacità e risolverlo mi richiederà di seguire l'intero processo e acquisire un po' di familiarità con la base di codice. La correzione dei bug è noiosa, ma è un ottimo inizio per orientarsi in un progetto.

Creazione di una forchetta

Questo può essere banale, ma al momento, per il progetto ScyllaDB, io sono la signora Nessuno; sarebbe rischioso permettermi di apportare modifiche al loro codice senza supervisione. Quello che devo fare è creare un "fork" nel mio account GitHub. Ecco il mio fork ScyllaDB. È il mio parco giochi dove ho accesso a tutto il codice e posso modificare i file come desidero. Se volessi creare la mia versione di ScyllaDB e modificarla per fare qualcosa di completamente diverso dal suo scopo originale, potrei farlo qui. Creare un fork è semplice; vai alla pagina principale del progetto e fai clic sul pulsante "fork". Non è affatto spaventoso.

È ora di correggere il bug

Ora è il momento di testare il codice sul tuo computer e apportare le modifiche necessarie. Prima di tutto, assicurati di aver installato il client Git sul tuo computer. Quindi, aggiungi la tua chiave pubblica SSH a GitHub e assicurati che sia caricata dal tuo agente ssh. Ottenere il codice localmente è semplice; usa semplicemente il comando git clone che punta al tuo fork, invece del ramo principale:

 git clone [email protected]:acbellini/scylla.git

A questo punto, dovresti aver testato il progetto sul ramo principale, quindi creerai il tuo codice localmente e lo testerai allo stesso modo. Tieni presente che dovrai eseguire il fork di qualsiasi altro progetto GitHub su cui si basa il tuo progetto, poiché i riferimenti sono relativi. Nel mio caso, ho dovuto biforcare seastar, scylla-ami e scylla-swagger-ui.

Il bug che devo correggere è relativamente semplice; la documentazione in conf/scylla.yaml menziona tre directory configurabili: una per i file di dati, una per i log di commit e una, apparentemente inutilizzata, per le cache, tutte predefinite in qualche sottodirectory di $CASSANDRA_HOME :

Immergendosi nel codice, mostra che le impostazioni predefinite sono diverse e, come menzionato nel numero 372 da cui sono partito, $CASSANDRA_HOME non dovrebbe essere utilizzato. Convalido la mia ipotesi testando il codice con un paio di impostazioni diverse, rimuovendo l'impostazione dal file di configurazione e verificando quali directory vengono utilizzate. Una volta abbastanza sicuro che tutto sia corretto, posso aggiungere, eseguire il commit e inviare il file modificato:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

Nota che ho introdotto il numero di problema preceduto da un hash nel messaggio di commit. Questo dirà a GitHub di collegare automaticamente il mio codice al problema stesso.

Un'altra cosa importante da notare è che, quando ho esaminato il codice, mi sono reso conto che la terza directory, quella per le cache, in realtà non è utilizzata. Si è tentati di fare un passo avanti e rimuovere questa impostazione stessa, o aggiungere un commento che non viene utilizzato, ma sarebbe al di fuori dell'ambito del numero 372, e sarebbe sbagliato eseguire il commit di qualsiasi cosa che non sia strettamente correlato a questo problema. È necessario mantenere le modifiche focalizzate e limitate all'attività in corso.

A questo punto il codice è corretto ed è su GitHub, nel mio fork privato. È qui che entra in gioco la parte spaventosa: chiedere alle persone di ScyllaDB di accettare il mio codice. Questa è chiamata richiesta pull.

Il passaggio finale: la richiesta pull

Mi piace creare richieste pull direttamente dall'interfaccia web su GitHub. Lo trovo più intuitivo e a prova di errore rispetto al tentativo di farlo dalla riga di comando. Tutto quello che devo fare per creare la mia richiesta pull è fare clic sul piccolo pulsante verde accanto al nome del mio ramo:

Nota che il commento è stato calcolato automaticamente da GitHub. Il mio ramo ora ha un nuovo commit, ma da quando ho creato il mio fork ci sono altri 14 commit nel repository principale, quindi farò clic sull'icona verde a sinistra.

Fortunatamente, il mio singolo commit non è in conflitto con gli altri 14, quindi GitHub mi informa che sono a posto. Non ho bisogno di aggiungere nessun altro commento o messaggio. Il messaggio di commit, pur essendo molto breve, dice tutto: cosa cambia il mio codice ea cosa è correlato. Mentre clicco sull'ultimo pulsante per confermare la mia richiesta, mi chiedo cosa sia stato che ho trovato così spaventoso solo pochi giorni fa. Non c'è nessun mostro che ruggisce contro di me in questo momento, e le fiamme dell'inferno non sembrano bruciare. Onestamente, non è stato affatto spaventoso. Nell'improbabile caso in cui ho sbagliato, la mia correzione non verrà accettata e sarà così.

Se ora controlli i dettagli del problema, puoi vedere che GitHub ha aggiunto automaticamente una nota che indica che esiste una richiesta pull che fa riferimento a questo problema. Questa è la magia di quel #372 nel messaggio di commit. Ciò consentirà di evitare che altre persone perdano tempo per riparare qualcosa che è già stato risolto.

Note finali

Ora sto aspettando che la mia richiesta pull venga accettata, riceverò una notifica quando ciò accadrà. Tieni presente che questo può richiedere alcuni giorni, anche settimane; qualcuno deve rivedere il mio codice, testarlo funziona come descritto, risolvere il problema e, in definitiva, assicurarsi che non influisca negativamente sulla funzionalità del resto del codice (leggi: crea nuovi bug). Tutto questo richiede tempo a qualcuno, quindi sii paziente. Alla fine, quando la mia richiesta pull sarà accettata, ScyllaDB avrà un contributore in più, un problema in meno e io avrò il mio primo contributo OSS. Ora è il momento di provarlo anche tu. Dopotutto, non è affatto spaventoso.