6 Lezioni che ho imparato sviluppando progetti Open Source

Il punto di vista di un data scientist

L’open source è un concetto davvero straordinario! Unendo le fonti, le competenze e le conoscenze di un’intera comunità, è possibile creare strumenti che non avremmo potuto realizzare isolatamente. Gli strumenti che nascono da queste collaborazioni sono davvero più della somma delle loro parti.

Di conseguenza, noi scienziati dei dati utilizziamo questo software disponibile gratuitamente che sta guidando così tante tecnologie pur avendo l’opportunità di essere coinvolti nel suo sviluppo.

Negli ultimi anni ho avuto la fortuna di essere coinvolto nell'open source e ho avuto l'opportunità di sviluppare e gestire diversi pacchetti!

Sviluppare open source è molto più che semplice codifica

Durante questo periodo c’erano molti ostacoli da superare e lezioni da imparare. Dalle dipendenze complicate e dalle scelte di progettazione delle API alla comunicazione con la base utenti.

Lavorare sull'open source, sia come autore, manutentore o sviluppatore, può essere piuttosto scoraggiante! Con questo articolo condivido alcune delle mie esperienze in questo campo che spero possano aiutare coloro che desiderano sviluppare open source.

Quando crei software open source, in genere non crei il pacchetto esclusivamente per te stesso. Gli utenti, provenienti da tutti i tipi di background diversi, utilizzeranno il tuo software. Una documentazione adeguata è molto utile per aiutare gli utenti a iniziare.

Tuttavia, non sottovalutare l'impatto che la documentazione può avere sull'usabilità del tuo pacchetto! Puoi usarlo per spiegare algoritmi complessi, fornire tutorial approfonditi, mostrare casi d'uso e persino consentire esempi interattivi.

Soprattutto il software relativo alla scienza dei dati può essere difficile da comprendere quando coinvolge algoritmi complessi. Affrontare queste spiegazioni come una storia mi ha spesso aiutato a renderle più intuitive.

Credimi, scrivere una buona documentazione è un'abilità in sé.

Un altro vantaggio è che scrivere una documentazione solida riduce il tempo dedicato ai problemi. Ci sono meno motivi per cui gli utenti pongono domande se riescono a trovare le risposte nella documentazione.

Tuttavia, creare documentazione è molto più che semplicemente scriverla. Visualizzare il tuo algoritmo o software contribuisce notevolmente a renderlo intuitivo. Puoi imparare molto da Jay Alamar quando vuoi visualizzare i principi algoritmici nella tua documentazione. Le sue visualizzazioni finirono addirittura nell'ufficialità numpy documentazione!

La tua base utenti, la comunità, è una componente importante del tuo software. Dato che stiamo sviluppando open source, possiamo dire con certezza che vogliamo che siano coinvolti nello sviluppo.

Interagendo con la community, li invogli a condividere problemi e bug, ma anche a presentare richieste e ottime idee per ulteriori sviluppi! Tutti questi aiutano a creare qualcosa per loro.

La comunità open source è davvero più della somma delle sue parti

Molte funzionalità principali di BERTopic, come modellazione di argomenti online, sono stati implementati poiché erano molto richiesti dai suoi utenti. Di conseguenza, la community è piuttosto attiva ed è stata di enorme aiuto nell'individuazione dei problemi e nello sviluppo di nuove funzionalità.

Sia che il tuo pacchetto verrà utilizzato milioni di volte o solo poche, crearne uno è un'eccellente opportunità per saperne di più su open source, MLOps, test unitari, progettazione API, ecc. Ho imparato di più su queste competenze nello sviluppo di open source di quanto avrei nel mio lavoro quotidiano.

C’è anche un’enorme opportunità di apprendimento dall’interazione con la comunità stessa. Sono loro che ti dicono quali design gli piacciono o no. A volte, ho visto lo stesso problema ripresentarsi più volte nel corso di alcuni mesi. Ciò indica che dovrei ripensare al design perché non era così facile da usare come avevo previsto!

Oltre a ciò, lo sviluppo di progetti open source mi ha dato l'opportunità di collaborare con altri sviluppatori.

Lavorare sui propri progetti open source al di fuori del lavoro comporta i suoi svantaggi. Per me, il più significativo è che mantenere il pacchetto, rispondere alle domande e partecipare alle discussioni può richiedere molto lavoro.

Sicuramente aiuta se sei intrinsecamente motivato, ma ci vuole ancora un po’ di tempo per assicurarsi che tutto sia tenuto insieme.

Fortunatamente, puoi rivolgerti alla tua community per aiutarti quando rispondi alle domande, mostri casi d'uso, ecc.

Nel corso degli ultimi anni ho imparato ad essere un po’ più rilassato quando si tratta di apportare modifiche. Soprattutto quando si tratta di dipendenze, a volte c'è davvero tanto che puoi fare!

Sapere quanto spesso viene utilizzato il tuo pacchetto è di enorme aiuto per capire quanto è popolare. Tuttavia, molti utilizzano ancora le stelle Github per equiparare un pacchetto a qualità e popolarità.

Come scienziati dei dati, dobbiamo prima capire cosa stiamo esattamente misurando. Le stelle di GitHub non sono altro che un utente che dà una stella a un pacchetto. Non significa nemmeno che abbiano utilizzato il software o che funzioni effettivamente!

Tecnicamente, posso pagare mille persone per rendere protagonisti i miei repository. Mi concentro invece su una serie di statistiche, come download e fork, ma anche sul numero di problemi che ricevo quotidianamente.

Ad esempio, è fantastico se i tuoi pacchetti vengono messi in evidenza Hacker News ma non ti dice se viene utilizzato in modo coerente.

Come psicologo, tendo a concentrarmi molto sul design dei miei pacchetti. Ciò include cose come documentazione e tutorial, ma si traduce anche nel modo in cui codifico.

Assicurarsi che il pacchetto sia facile da usare e installare rende l'adozione molto più semplice. Soprattutto quando ti concentri su filosofie di progettazione come modularità e trasparenza, alcuni pacchetti diventano fantastici da usare.

Assumere il punto di vista di uno psicologo durante lo sviluppo di nuove funzionalità ha reso molto più facile sapere su cosa concentrarsi. Cosa cercano gli utenti? Come posso codificare in modo da spiegare l'algoritmo? Perché gli utenti utilizzano effettivamente questo pacchetto? Quali sono i principali svantaggi del mio codice?

Prendersi il tempo necessario per comprendere l'adozione da parte dell'utente medio

Tutto quanto sopra spesso porta ad una regola basilare ma importante;
Mantienilo super semplice

Personalmente, se trovo un nuovo pacchetto difficile da installare e utilizzare, è meno probabile che lo adotti nel mio flusso di lavoro.

Se, come me, sei appassionato di intelligenza artificiale, scienza dei dati o psicologia, non esitare ad aggiungermi LinkedIn o seguimi su Twitter. Puoi anche trovare alcuni dei miei contenuti su my Sito web personale.

Tutte le immagini senza fonte sono state create dall'autore

6 lezioni che ho imparato sviluppando progetti open source Ripubblicato da Source https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 via https://towardsdatascience.com/feed

<!–

->