L'eleganza dell’Open Source Software

Ricciao Michele. Ok, adesso siamo online, vediamo man mano quando arrivano le persone. Attendiamo un attimo, nel frattempo apro un attimo tutte le cose, ti faccio anche co-host. Buonasera a tutti man mano che partecipate. Io saluto un po' tutti ogni tanto. Fatemi sapere se si sente, se si vede. Ti mischio un attimo la webcam.

Si

sente forte e chiaro, perfetto. Grazie Valerio. Adesso aspettiamo un attimo, qualche minuto, cinque o sei minuti, visto che siamo in anticipo e qualcuno potrebbe anche connettersi dopo. Ok, Michele dovresti sentirmi, vedermi anche, tutto quanto.

Sì, ti vedo e ti sento.

Ok, allora io intanto ti faccio co-host così in qualsiasi caso, qualsiasi tipo di problematica, puoi interagire.

Allora,

come dicevo, aspettiamo ancora qualche minuto nel frattempo, visto che magari qualcuno finisce a lavorare proprio alle 18, e si connetterà tra poco. Allora, nel frattempo, nel frattempo... qua vedo che hai già condiviso tutto quanto. Allora, i primi che si stanno connettendo poi... Ciao Matteo! Piacere di averti qui. Allora, i primi che si stanno connettendo intanto vi spiego due cose, due regole di interazione se non avete mai utilizzato Zoom o non avete mai partecipato in un formato, comunque, webinar che è diverso dal formato meeting. Allora, per interagire al meglio per tutte le questioni legate a domande, piuttosto che curiosità e quant'altro, o eventuali problematiche magari tecniche, potete liberamente, anzi siete invitati durante la prossima ora, a scrivere tranquillamente sia a me, ma soprattutto a Michele, che porterà appunto l'argomento dell'eleganza dell'open source software. e potrete utilizzare diverse modalità. Allora, la prima e più immediata potrete scrivere in chat per qualsiasi tipo di interazione, anche molto diretta, del tipo si sente, non si sente più, e anche qualsiasi tipo di curiosità o domanda di approfondimento potrete scriverla in chat. Il mio consiglio spassionato è quello di utilizzare la sezione Q&A, quindi il tasto Q&A che trovate nel vostro pannello di controllo di Zoom. Cliccandoci sopra potrete vedere che potete fare una domanda che leggeremo sia io sia Michele, tecnicamente io non sono uno sviluppatore perciò lascerò completamente il palcoscenico poi a Michele appunto che saprà anche dare delle risposte migliori probabilmente delle mie. ed effettivamente potrete anche farlo in formato anonimo, quindi se qualcuno di voi è un po' timido o si vergogna di, lo so, ha paura di dire qualche castroneria, potrà utilizzare il formato anonimo senza nessun tipo di problema. Altro modo per interagire, appunto, è quello di alzare la manina, quindi in questo momento, mentre aspettiamo che anche qualcun altro si connetta, potremmo fare un esperimento con qualcuno di voi che cliccando sulla manina del suo parminello di controllo, così coraggioso si mette a disposizione, perfetto. Vedo Marco, Marco ti sto per dare parola, quindi dovresti poter abilitare il tuo microfono innanzitutto. Forse Marco? No, ho cliccato Matteo. Un tale Matteo Baraldi. Scusa, Matteo, quindi sei tu che parti. Sì, sento bene.

Benissimo, grande.

Perfetto, grazie mille Matteo per esserti sacrificato per la causa, quindi scusa Marco se non era proprio una prova. Nel caso poi abbiate delle domande, ti rimuto subito Matteo. Alzando la mano, sia io sia Michele, potremmo darvi la parola, quindi potrete direttamente interagire, magari fare una domanda più approfondita o un vero e proprio scambio anche magari d'opinione che ben venga assolutamente importante che sia costitutibile. Quindi, utilizzate il tasto Q&A, manina alzata se volete interagire direttamente a voce, oppure scrivete in chat con la postilla che in chat, se ci sono molte domande, si potrebbero perdere comunque nel minestrone, nel calderone della conversazione. E Michele, ti lascio direttamente la parola a questo punto, vedo che cominciano già ad essere un po' i partecipanti, se vuoi attendere ancora qualche minuto attendiamo tranquillamente, dopodiché quando ti senti più pronto e quant'altro puoi anche partire. Vi dico, tra l'altro, che tutto ciò che stiamo facendo e stiamo dicendo adesso verrà registrato, perciò poi ritroverete questo tipo di registrazione anche in un link che vi verrà inviato nei prossimi giorni appena scaricheremo il video e potrete rivedere effettivamente il contenuto delle slide direttamente di Michele in questa registrazione. Perciò buona visione a tutti, io mi muto e rimango in background e lascio tutto quanto a te Michele.

Ok, grazie soprattutto a Startup Consulting per avermi permesso di tenere questo webinar e soprattutto di parlare di un argomento che mi sta così a cuore come l'open source software. Dico prima di iniziare due parole su di me, sono Michele Riva, lavoro come senior software engineer presso ViacomCBS, da febbraio di quest'anno ho cofondato Hackdoor.io che è una piattaforma di blogging per articoli puramente tecnici o consigli di carriera o comunque tutto ciò che è legato all'ambiente tech, non solo programmazione ma anche appunto recruitment, HR, eccetera. Sono anche un grandissimo, come ho già detto, appassionato di software open source e adesso andremo a vedere cos'è effettivamente questo software open source. Voglio partire dicendo che il mondo come lo conosciamo oggi è costruito sul software open source. È un'affermazione forte e la voglio giustificare durante la prossima mezz'ora in questo talk. Per capire il perché di questa affermazione effettivamente dobbiamo partire chiedendoci cos'è un software. Una prima definizione potrebbe essere una collezione di dati e istruzioni che dicono al computer come comportarsi, come lavorare. Per cui, per dare questa istruzione a un computer, lo dico magari perché è un po' meno tecnico, si utilizza quello che si chiama linguaggio di programmazione. Questo è un esempio in C++, un programma che ogni volta che viene eseguito mi dice Hello World. Chiaramente il computer non capisce il linguaggio di programmazione. Deve essere quest'ultimo compilato in un formato chiamato binario, che magari conoscete per essere composto da 0 e 1 solamente. Vediamo un attimo com'è un ciclo di sviluppo normalmente. C'è un cliente, che in questo caso è l'omino arancione, che chiede a un programmatore di scrivere un software. In questo caso vuole un software che scriva Hello World a schermo ogni volta che viene eseguito. lo sviluppatore scrive il software, lo compila in codice binario così che il computer possa eseguirlo, lo impacchetta per cui ci mette un'icona, ci scrive la documentazione, crea un pacchettino da consegnare al cliente e poi infine appunto lo consegna. A questo punto il cliente dice molto bello, mi piace tantissimo questo software, però voglio una modifica. Voglio che al posto di dire hello world dica hello everybody. Allora lo sviluppatore si riprende in carico questo lavoro, modifica il software utilizzando il suo linguaggio di programmazione di riferimento, ricompila in codice binario, lo reimpacchetta, quindi modifica la documentazione, cambia l'icona e tutto quanto, lo riconsegna all'utente finale. fin qua sembra essere tutto abbastanza normale ma c'è un problema il cliente non ha mai accesso al codice sorgente e per codice sorgente si intende quello scritto in un linguaggio comprensibile da un essere umano quindi ad esempio il programma C++ ma ha solamente accesso al codice binario per cui non può modificarlo può verificare che il contenuto del codice binario non possa nascondere ad esempio un virus o essere dannoso. Non può neanche andare da un'altra azienda e dire guardate adesso lo sviluppatore mi sta chiedendo troppi soldi per aggiornare il software, me lo modificate voi. Quest'ultima azienda non potrebbe fare nulla perché appunto non ha accesso al codice sorgente. Questa situazione si chiama vendor lock-in, quando si è legati ad un unico venditore, effettivamente, che è l'unico che può mettere mano al software. Dal punto di vista di un imprenditore magari è una buona posizione, ma per un cliente chiaramente non è l'ideale. Si accorse di questa situazione tra i primi Richard Stallman, Richard Stallman ancora oggi è conosciuto per essere il fondatore della Free Software Foundation, cocreatore e leader del progetto GNU, l'autore della prima licenza open source ed è anche un programmatore del laboratorio di intelligenza artificiale della MIT di Boston. Stolman si accorse per la prima volta di questo problema per colpa di un software, di una stampante. Era una Xerox 9700. Stolman in precedenza aveva già lavorato su questo tipo di stampanti e voleva fare un improvement al software di questa stampante. Voleva fare in modo che a Harvard, dove lavorava come professore, come ricercatore, Volevo fare in modo che quando da un computer si chiedeva la stampa di un file, poi la stampante inviasse una notifica di avvenuta stampa o di problemi in caso ci fossero stati problemi. Come dicevo, Stallman aveva già lavorato su questo tipo di stampanti, conosceva il software, sapeva metterci mano, ma la Xerox gli disse no, tu non puoi mettere mano al nostro software perché è nostro, è proprietario. Quando il software non è open source, nella maggior parte dei casi si dice proprietario. Chiaro, questa non è una situazione incredibile che ti fa dire, ok, crea un intero sistema operativo dove chiunque può scrivere software open source, chiunque può modificarlo, eccetera. Ma effettivamente questa situazione si presentò poco più avanti col sistema operativo Unix. Il sistema operativo Unix era un sistema operativo all'avanguardia molto popolare e aveva l'unico difetto di essere proprietario. Era della TNT, quindi scritto nei Bell Laboratories, famosi anche per aver inventato linguaggi di programmazione come C e C++. Ecco, c'era un problema con Unix che era un sistema operativo meraviglioso per fare ricerca. Funzionava alla perfezione ma non tutti potevano permetterselo perché aveva un costo e soprattutto dei ricercatori come quelli dell'MIT di Boston o di Harvard che sapevano mettere mano a un sistema operativo modificandolo a piacere, in questo caso non potevano farlo perché appunto avevano solo il codice binario, non avevano il codice sorgente e questo diventava sempre di più un problema, soprattutto in ambito accademico. Ed è qui che Stallman, insieme ad altri grandi hacker di Harvard e dell'MIT, fondarono il progetto GNU. Il progetto GNU prevedeva la creazione di un sistema operativo alternativo che doveva essere come UNIX ma composto solamente da software libero. Per software libero si intende un software il quale codice sorgente può essere letto e modificato e ridistribuito da chiunque. Nasce appunto il progetto GNU, il quale acronimo significa GNU is not UNIX e si danno come obiettivo appunto quello di rimpiazzare Unix con software gratuito, libero e utilizzabile da chiunque Nasce così Hurd Non so bene come si pronuncia, non l'ho mai sentito pronunciare, credo si pronunci Hardfjord, non lo so. Sta di fatto che comunque Urd inizia ad essere un progetto importante per la community di hacker di Harvard e dell'MIT. Il problema è che scrivere un sistema operativo non è qualcosa, come potete immaginare, di molto semplice e con le tradizionali metodologie di sviluppo di quei tempi, si parla circa degli anni 80, inizio anni 90, diventava davvero complicato. Il sistema operativo cresceva ma era pieno di malfunzionamenti, non poteva essere utilizzato praticamente per nulla, mancavano delle parti fondamentali del software e il progetto rischiava di arenarsi, finché non arrivò Linus Torvalds che era un semplice semplice tra virgolette studente dell'università di Helsinki che per la sua tesi di laurea creò Linux. Linux era un sistema operativo Unix-like, ovvero che prendeva da Unix, tanto che il nome infatti è l'unione tra Linux e Unix ed era un sistema operativo perfettamente funzionante, aveva qualche piccolo malfunzionamento ma nulla di così strano rispetto a Hurd, per cui da Harvard iniziarono a notare questo sistema operativo che si faceva a strada e insomma poteva essere una valida alternativa a Hurd. Linux Torvalds, durante una conferenza tenuta da Richard Stallman in cui promuoveva la Free Software Foundation, che era la fondazione che intanto aveva fondato per promuovere software libero, Linux si fece affascinare dalle parole di Stallman e decise di pubblicare il suo personale sistema operativo, la sua thesis di laurea, come software libero, gratuito, utilizzabile da tutti quanti E fu così che finalmente Linux iniziò a far parte del progetto GNU ed esplose letteralmente. Finalmente tutti quanti, gli sviluppatori, i ricercatori, gli scienziati, avevano accesso a un sistema operativo eccellente che funzionava davvero, frutto soprattutto dell'impegno di più persone di tutto il mondo, perché non c'era solamente il team di Harvard o il team dell'MIT, ma tutti quanti in tutto il mondo potevano collaborare liberamente a questo progetto, il progetto Linux. che venne rilasciata con la licenza GPL, ovvero GNU Public License. Iniziarono a nascere anche delle società, tra cui possiamo pensare ad esempio a Red Hat, che presero Linux e dissero che era molto bello, che gli manca qualcosa, però dato che la licenza me lo permette, io prendo Linux, lo modifico, ne creo una versione Enterprise e la vendo. E furono tante effettivamente le società che iniziarono a fare una cosa del genere, tanto che queste società diventarono enormi, guadagnarono milioni di dollari e iniziarono a ricambiare, iniziarono a fare delle donazioni a Linux rendendolo milionario, tanto che iniziava a far tremare anche Microsoft che a quei tempi invece promuoveva Windows che era un sistema invece proprietario, completamente opposto alla filosofia di Linux. Una cosa interessante del progetto Linux e che era completamente diverso rispetto ai prodotti sviluppati dalle compagnie tradizionali. Prendiamo l'esempio di Microsoft con Windows. Microsoft aveva centinaia se non migliaia di sviluppatori, Linux ne aveva migliaia, decine di migliaia, molte di più di Microsoft sicuramente, perché chiunque, ripeto, poteva partecipare al progetto. Microsoft aveva un'organizzazione gerarchica, per cui c'erano i team con un capo che decideva cosa bisognava fare, quali erano gli obiettivi da raggiungere, mentre Linux dall'altra parte era un'archia pura, chiunque poteva fare qualunque cosa. E come dicevo, appunto, c'erano delle roadmap, c'erano delle milestone, per cui si sapeva il progetto Windows, che strada poteva prendere. Ma dall'altra parte Linux invece, a parte un piccolo core che naturalmente aveva la visione del progetto, la maggior parte degli sviluppatori in realtà si muoveva liberamente all'interno del progetto stesso, per cui il vantaggio qual era? E' che Microsoft se presentava un bug, questo bug doveva rientrare all'interno di una roadmap, per cui c'è un bug, lo identifico, lo metto tra un mese e diciamo che rilasciamo una fix. Linux invece no, io sviluppatore noto un bug, dico ok fantastico, mi leggo il codice sorgente, capisco come posso fixarlo, lo fixo, lo rimando indietro ed è subito disponibile per tutti quanti. Per cui da una parte c'era Microsoft, sistema istituzionale che cresceva, dall'altra parte c'era Linux che non aveva praticamente nessun tipo di bug così importante come Microsoft e cresceva a dismisura molto più rapidamente. Questo è un po' la storia del software open source, chiaramente Linux ha influenzato molto tutto quello che è il mondo open source sostanzialmente è stato un po' il pioniere di questo mondo, pensiamo poi più avanti nel 91 nasce Internet come lo conosciamo, nasce anche Apache che è il primo web server che permette di condividere più siti web da un unico web server e viene rilasciato appunto con licenza open source e allora il web capisce che l'open source software è una risorsa di valore inestimabile e tutti quanti i sviluppatori iniziano a provare attrazione per questa nuova metodologia di sviluppo e di rilascio software Ma oggi, se dovessimo parlare di open source, di cos'è che parleremmo? Vediamo! Innanzitutto parleremo di Blogging Platform. Il 40% del traffico internet oggi è dato da WordPress. WordPress sicuramente lo conoscete tutti quanti, è una piattaforma di blogging scritta nel linguaggio PHP ed è disponibile gratuitamente per tutti quanti. Chiunque oggi può prendere il codice sorgente, leggerlo, modificarlo, chiedere delle modifiche o chiedere degli improvement, per cui dei miglioramenti del software stesso. E chiunque, soprattutto oggi, può scrivere liberamente sul web grazie a WordPress, Drupal, Typo3, Joomla, tantissimi altri sistemi di blogging. Tutti quanti completamente liberi e open source. Tantissimi database oggi sono open source, per cui i nostri dati personali oggi vengono immagazzinati in queste strutture che nella maggior parte dei casi sono open source. Pensiamo a MySQL. MySQL oltre a essere il database di riferimento di WordPress è stato anche il database di riferimento di Facebook per cui all'inizio i nostri dati erano conservati dentro questo database che chiunque può leggere com'è stato costruito e questo è un vantaggio anche per la sicurezza perché se io sviluppatore leggo il codice sorgente di MySQL e noto un problema di sicurezza posso segnalarlo, posso fixarlo, posso fare in modo che non si ripresenti più nelle versioni successive Abbiamo altri esempi, chiaramente Postgres, Cassandra, Redis, Mongo, eccetera, sono tutti quanti database open source e gratuiti all'utilizzo. Abbiamo Framework, per chi magari non è un sviluppatore, il Framework è un Il framework è un insieme di convenzioni e regole che ci permettono di sviluppare con un dato linguaggio di programmazione. Abbiamo qua l'esempio di Symfony, Rails, Spring, .NET. .NET era un framework Microsoft che è stato reso open source nel tempo proprio per la pressione della community che adorava questo framework ma voleva leggerne la sorgente. I linguaggi di programmazione o i runtime come nel caso di Node.js Se ci pensate, quello che abbiamo visto all'inizio, il codice che noi sviluppatori scriviamo non è altro che testo. Serve qualcosa, un software, che legga questo testo e produca un codice binario che possa essere invece compreso dal computer. Questo è il lavoro degli interpreti o dei compiler che prendono poi il nome chiaramente di linguaggi di programmazione a seconda delle regole semantiche che vengono introdotte nel testo che scriviamo. L'interprete di Python, ad esempio, è completamente open source. Io posso scrivere un file di testo contenente del codice Python e il software che compila questo codice, lo interpreta, rendendolo disponibile per il computer, ecco, è completamente open source. Stessa cosa per Go, Ask, LPHP, ReasonML, addirittura Java, Erlang e così via. Vi ricordate quando all'inizio ho detto che il mondo che conosciamo è costruito grazie al codice, al software open source? Ecco, vediamo qualche esempio allora nella vita reale. Il 90% del traffico Internet viene gestito da dei nodi controllati da Erlang. Erlang è un linguaggio di programmazione inventato negli anni Ottanta, creato negli anni Ottanta da Ericsson e oggi il 90% del traffico Internet viene smistato grazie a questo linguaggio di programmazione open source. Internet, come lo conosciamo oggi, con la sua resilienza, con la sua capacità di essere altamente disponibile, è dovuto anche a questo linguaggio che chiunque oggi può prendere in mano. Android è un altro esempio. Android stesso, basato su Linux, è un sistema operativo per smartphone completamente open source. Ho lasciato il link in questa slide, poi vi condividerò le slide. Potete cliccare sul link e accedere al repository e leggervi il codice del sistema operativo più diffuso al mondo. I sistemi operativi della famiglia Apple, o SX, prendono tantissimo da FreeBSD, che è una distribuzione Linux con delle differenze di licenza rispetto al Linux classico, ma comunque basato su software libero. Per fare un esempio che ci porta direttamente alle stelle, possiamo pensare a SpaceX che utilizza Linux quotidianamente per i suoi lanci. Il computer di bordo di SpaceX, ma come della NASA, dei razzi NASA, sono basati su Linux, per cui una tecnologia ancora una volta disponibile per chiunque. Se pensiamo ad esempio agli Amazon Echo, i Google Home, dispositivi IoT, tutti quanti sono scritti, quantomeno, in linguaggi di programmazione che oggi sono open source. Per cui ciò significa che con la giusta conoscenza dell'elettronica, ad esempio, chiunque di noi potrebbe riprodurre effettivamente uno di questi dispositivi perché ne ha tutte le caratteristiche. Da poco, da circa una quindicina o ventina d'anni, è nata anche la open source hardware che appunto, come per il software, descrive un'architettura hardware che possa essere libera e riutilizzata appunto per ricreare dispositivi hardware con tecnologia open source Ci tengo anche a precisare come i principali social network che oggi utilizziamo sono direttamente collegabili a tecnologie open source perché Instagram ad esempio, che è scritto in Python, quindi linguaggio di programmazione open source, ha utilizzato sin da subito uno stack tecnologico completamente open source, ha utilizzato MySQL, Redis, Python appunto e così ha fatto anche Facebook con PHP, poi più avanti ha creato Hack o comunque dei runtime che ha reso disponibili open source Twitter con Scala, Pinterest con Python ed Elixir e Whatsapp con Erlang. Quindi chi scommette sull'open source oggi? Vorrei farvi vedere prima di tutto una bruttissima frase di un CEO di un'azienda abbastanza famosa che è Microsoft che nel 2001 additava Linux come un cancro che attaccava la proprietà intellettuale di qualunque cosa venisse a contatto con esso. Bene, dal 2001 ad oggi Microsoft ha radicalmente cambiato idea riguardo al software open source. Ha comprato GitHub, che per chi non lo conoscesse è un sito sul quale gli sviluppatori possono condividere il proprio codice open source, non solo gli sviluppatori ma anche le aziende. Infatti Microsoft ha più di 1100 repository open source disponibili per chiunque e tutti noi possiamo prendere qualunque di questi repository, clonarlo, per cui prenderci il codice sorgente, metterlo sul nostro computer, modificarlo, farci assolutamente quello che vogliamo Microsoft nel tempo si è anche scusata per quella frase riguardo a Linux e oggi nel suo sistema Azure è disponibile anche a dare supporto per Linux e non solo per le macchine Microsoft. Oltre a Microsoft abbiamo Google, Airbnb, Uber, VMware e tantissime grandi aziende che condividono quotidianamente software open source scritto da loro. E proprio qui potrebbe nascere una domanda. Lo sviluppo software è comunque costoso perché richiede figure specializzate, tanto tempo e tante risorse. Perché una compagnia, una grande compagnia, dovrebbe pubblicare codice open source? Qui immaginate Microsoft scrive il suo software, arriva Apple e glielo ruba e ci fa la sua versione. Perché Microsoft dovrebbe compiere un rischio del genere? Innanzitutto, una prima risposta potrebbe essere per influenzare gli sviluppatori e le altre compagnie. Facendosi concorrenza a vicenda, è naturale che a un certo punto, ad esempio, NASC Android, un sistema operativo scritto in Java, sostanzialmente quindi un linguaggio molto più utilizzato di Objective-C, che invece è il linguaggio utilizzato da Apple per le sue applicazioni native. Al che Apple si deve correre un attimo ai ripari perché dice se gli sviluppatori scrivono tutti quanti per Android perché Java è un linguaggio più diffuso, più conosciuto, dovrò fare qualcosa anch'io. Allora pubblico Swift. Swift è un linguaggio di programmazione inventato da Apple che serve per scrivere applicazioni native per Mac oppure iPad, iPhone eccetera. Per cui diciamo che da un certo punto di vista si influenzano a vicenda. Nell'altro punto di vista pensate anche all'influenza che ha la Oracle da quando detiene i diritti di Java. Java rimane un linguaggio open source tramite OpenJDK però chiaramente la Oracle continua a dare la propria influenza al linguaggio e Java è un linguaggio così ampiamente utilizzato e così parte del mondo in cui viviamo che avere un'influenza sul linguaggio, su come si evolverà e su chi lo utilizza può avere dei risvolti interessanti anche lato business Un'altra risposta può essere l'opposto, ovvero evitare che ci siano troppe influenze dalle grandi compagnie. Se pensiamo a Unix ad esempio, influenzava il modo in cui veniva sviluppato il software negli anni 80 e Linux nasce proprio per rendere questa influenza disponibile a tutti, non voleva che solamente AT&T avesse questa proprietà. Pensiamo a Vue, per cui c'è React ad esempio che è un framework JavaScript scritto da Facebook che va per la maggiore in questo momento e chiaramente l'influenza che esercita Facebook su questo framework è importantissima e c'è una parte di community a cui non sta bene questa cosa per cui si ritrova di più a lavorare magari su Vue o Svelte o altre tecnologie alternative Tornando indietro nel tempo potremmo pensare alla battaglia tra Internet Explorer e Netscape dove Netscape ebbe l'apeggio ma sulle sue ceneri nacque la Mozilla Foundation che presentò una valida alternativa a Internet Explorer che era un browser che veniva preinstallato su qualunque PC Microsoft e che quindi gli utenti utilizzavano senza sapere che effettivamente però potevano anche dare dei dati a Microsoft, che Microsoft influenzava il modo in cui il web veniva scritto. La Mozilla Foundation è nata proprio per questa, per non lasciare il monopolio del modo in cui navighiamo internet a Microsoft solamente. Un altro motivo per cui certe aziende pubblicano il proprio codice open source è perché hanno un modello di business alternativo, un modello di business ad esempio freemium per cui facciamo l'esempio di Nest, l'ultima iconcina che vedete, il gatto rosso Nest è un framework scritto in TypeScript per Node.js per creare delle applicazioni dei server, delle web app in Node ecco NEST quello che ti dice il mio codice open source puoi farci quello che vuoi se vuoi l'assistenza mi paghi per cui se tu hai un problema e quando entri nell'enterprise tendenzialmente hai molti problemi NEST ti dice va bene ti do io il supporto di cui hai bisogno oppure ti dice vuoi questa feature questa non è compresa nel software open source te la sviluppo a parte e tu la paghi e chiaramente poi si rientra nel ciclo di vendor lock-in e così via, però chiaramente queste aziende hanno questo tipo di modello di business e bisogna esserne consci quando si adotta una delle loro soluzioni. Detto questo, dall'altra parte della scrivania invece, quali sono i vantaggi per chi adotta software open source dal punto di vista imprenditoriale? Innanzitutto il codice open source è più economico. Ora, voi immaginate che siete un'azienda, una startup magari, per cui non avete neanche troppi soldi da investire e avete bisogno di un database. Le cose sono due, o pagate qualcuno o assumete qualcuno per sviluppare un database, che è un lavoro incredibilmente complesso, oppure utilizzate un database già esistente, open source, e vi basate su quello, poi ci ripenserete più avanti. Un altro punto importante, si condividono i costi di manutenzione. Per cui, se prima ho chiesto a una società di svilupparmi un database, oppure ho un dipendente che sviluppa un database, se c'è un bug, se c'è della manutenzione da fare, ha un costo molto alto. Se invece più persone utilizzano lo stesso database open source e si presenta un bug su di esso, magari io non l'ho neanche notato quel bug, ma un'altra azienda si, per cui mette in campo una risorsa che metta a posto questo bug e nella prossima release questo bug sarà fissato. Io magari neanche mi accorgo di aver avuto, che avrei potuto avere quel problema, perché appunto dato che ci sono tante persone che ci lavorano, A quel punto qualunque bug viene un po' condiviso su tutta quanta la community che adotta questo database, per fare l'esempio del database, ma lo stesso problema c'è con qualunque altro tipo di tool si evita il vendor lock-in, quello che abbiamo visto prima. Se io chiedo alla società di sviluppare un database apposta, poi sono legato a quella società per molto tempo, se utilizzo MySQL, ad esempio, effettivamente qualunque altra società può prendere in carico operazioni e lavorazioni fatte su quel database, perché la conoscenza non è tutta racchiusa in una sola società, ma più figure professionali possono avere competenze in questo ambito. permette alle startup di iniziare dal piccolo, quindi quello che abbiamo visto prima mi permette di iniziare con magari un database piccolino, che è quello che mi serve per questo momento, poi più avanti ci penseremo, mi servirà una soluzione custom, la adotteremo, ma al momento mi permette di crescere, di far crescere il mio business e arrivare al punto di dire, va bene, facciamo qualcosa di custom. Inoltre, una cosa a cui tengo molto, permette di attrarre talenti. Per cui se io piccola startup utilizzo ad esempio Redis, faccio un esempio, potrei attrarre gente appassionata a questo database che vuole lavorare a tutti i costi su questa tecnologia e allora viene da me e si propone. Chi fa recruitment lo sa che magari il programmatore non è la figura professionale più semplice da assumere. e avere delle tecnologie magari anche un pochino fuori dallo standard, ecco questo aiuta a attrarre la nicchia, per cui può essere un pro. Parlando proprio di Recruiter, vediamo come il software open source può aiutare il recruitment. Vi mostro il mio profilo Github, che è il sito di cui abbiamo parlato prima. Ora, mettiamoci un attimo nell'ottica di un recruiter che ha bisogno di uno sviluppatore TypeScript. Facciamo l'esempio. Su Github ho una primissima overview di quello che lo sviluppatore sa fare. Come vedete al centro, ad esempio, si vede che ho un po' di esperienza in JavaScript, in Haskell, in Go e in TypeScript. Per cui, ecco, una prima scramatura l'ho fatta. vedo quanto partecipa alla community, vedo con quali altre aziende ha collaborato, in questo caso Facebook, Node, Image Proxy, eccetera, per cui mi faccio un po' l'idea di chi ho davanti. Vado nei suoi repository privati e dico, va bene, io ho bisogno di una figura che scrive in TypeScript, vediamo cosa ha realizzato, che software open source ha realizzato in TypeScript. E vengono fuori una lista di software, che ho realizzato in questo caso io in TypeScript, e posso anche leggermi il dettaglio, per cui a questo punto posso passare, se la figura mi sembra interessante, posso passare questo blocco di codice ad esempio a una figura più tecnica dell'azienda che possa analizzarlo e darmi un feedback sulla persona alla quale voglio fare una proposta. Ora, per concludere, mettiamoci invece da un altro punto di vista, cioè la professione dello sviluppatore o meglio, dell'ingegnere informatico, è una professione molto redditizia. Questo è stato studiato anche dal Michigan Technological University, scusatemi, l'ho scritto perché non so mai come si scrive Michigan, dal Michigan Technological University, e ha notato come i software engineer, tra tutti gli ingegneri, sono effettivamente le figure professionali più pagate. Per cui, perché uno sviluppatore in America, che è la professione più pagata, dovrebbe scrivere codice gratis? Allora, innanzitutto mettiamoci nei panni di un junior che deve fare esperienza. Il software open source ti permette di fare tantissima esperienza. Qui abbiamo un esempio preso da JetBrains in cui c'è uno sviluppatore, una sviluppatrice, che ha scritto del codice, ha scritto quello che ha fatto e c'è sotto qualcuno di più senior che gli sta dicendo ok, guarda, va tutto bene, avrei preferito quest'altra soluzione, per cui Un junior nell'open source può fare tantissima esperienza e può sperimentare tantissimo, capendo effettivamente qual è il percorso che vuole fare. Interessa la sicurezza informatica? Può fare quello. Interessa magari il front-end? Può buttarsi a fare front-end. Non ha nessun tipo di obbligo o vincolo. Dall'altra parte il software open source ti permette di migliorare le tue skill. Per cui io scrivo il mio software e ho qualcuno che puntualmente mi fa una review per cui mi dice guarda va tutto bene però qui c'è questo piccolo errore e posso iniziare una conversazione con questa persona che mi spiega effettivamente qual era la strada migliore per risolvere un dato problema. Un altro motivo può essere per cambiare le cose. Un ottimo esempio che ammiro moltissimo è quello di Salvatore Sanfilippo, uno sviluppatore nostrano, che ha scritto Redis, che è un database incredibile, è un database veramente fantastico. Ogni anno su Stack Overflow, che è un sito di riferimento per noi sviluppatori, viene fatta una classifica ad esempio dei database più amati e Redis è sempre la prima posizione. In questo caso Salvatore Sanfilippo voleva davvero cambiare le cose e lo ha fatto e ha reso il suo codice disponibile per tutti. L'ha reso disponibile per tutti perché il codice open source è etico. Questa è la cosa che sinceramente a cui tengo di più. Quando scrivi codice open source non importa minimamente chi sei, non importa la tua etnia, le tue preferenze sessuali, non importa da dove scrivi, se stai scrivendo di notte, se stai scrivendo di giorno, da una stazione o puoi scrivere ovunque, l'unica cosa che conta è il software. Talvolta non conta neanche quello, perché non importa neanche quanto sei bravo. L'unica cosa che ti insegna veramente il software open source è che tutti quanti contiamo, ma contiamo davvero. Vi ringrazio per avermi ascoltato, vi lascio dei riferimenti se voleste contattarmi in seguito. Scannerizzando il codice QR potrete accedere a Hackdor e leggervi degli articoli che ho scritto, ovviamente che ho scritto io o altri writer, e possiamo sentirci anche lì. Ora magari rispondo a qualche domanda che ho visto che sono

arrivati. Sì, vai pure in ordine sparso, come preferisci tra quelle. Poi ragazzi, se qualcuno di voi volesse, come ho detto, anche alzare la manina, vedo Matteo è sempre con la mano alzata, poi non so se volete fare una domanda o quant'altro, nel caso abbassa, ecco, infatti l'ha abbassata, nel caso se volete fare una domanda anche a voce, per quindi confrontarsi meglio, potete farla

tranquillamente. Ok, allora vedo che un anonimo mi ha chiesto quali sono i contro dell'open source. Allora, sicuramente un contro... quello che dico chiaramente è una... non so come dire... è un parere personale, naturalmente. Credo che questa risposta dipenda dalle varie esperienze che abbiamo avuto come sviluppatori. Un contro sicuramente è che se vuoi un cambiamento all'interno di un software devi portare delle ragioni molto valide. Prendiamo l'esempio di Redis, ne abbiamo parlato poco fa. C'è questo sviluppatore che Salvatore Sanfilippo, che lavora nell'open source, significa che lui è pagato da Redis Labs, che è un'azienda di consulenza su Redis, è pagato per sviluppare solo Redis tutto il giorno e rilasciarlo open source, non deve fare nient'altro. Ciò significa che se però io voglio apportare una modifica a Redis, devo passare dalla sua approvazione, ma lui avrà centinaia di migliaia di richieste ogni anno di modifica. Per cui, soprattutto per questo tipo di progetti in cui c'è una sola persona dietro che fa un po' da filtro per le varie richieste, effettivamente può essere un po' complesso arrivare a ottenere la modifica che si vuole. Che poi è un contro dall'altra parte, dici va bene non mi fai la modifica che voglio, faccio un fork per cui prendo il tuo codice, lo copio, lo modifico e introduco le modifiche che voglio. significa che poi però te lo devi mantenere. Per cui questo è sicuramente un contro. Per il resto un altro contro può essere che, abbiamo detto prima ad esempio, utilizzo MySQL, viene scoperta una vulnerabilità all'interno di MySQL e la persona che la scopre al posto di comunicarla la sfrutta per degli attacchi malevoli, per fare hacking malevolo su chi utilizza quel tipo di database. Allora, questo sicuramente è un contro. C'è anche da dire che più i progetti crescono, più è difficile che ci siano questo tipo di situazioni. È qualcosa che può succedere soprattutto nei progetti molto piccoli. In più, soprattutto GitHub e altre società del genere hanno messo a disposizione dei tool gratuiti che ci aiutano a identificare bug di questo tipo. Per cui diciamo che Tendenzialmente per ogni contro che mi viene in mente, mi viene in mente anche una possibile soluzione. Se qualcuno poi magari vuole intervenire su questo punto sarebbe molto interessante parlarne ancora. Poi vedo un'altra domanda anonima. Ciao Michele, nei panni di un giovane informatico alle prime armi, su quale linguaggio open source punteresti per formarti? Ecco questa è un'ottima domanda. Allora io direi che dipende soprattutto dalle ambizioni che hai, nel senso che se devi fare sicurezza informatica probabilmente non ti consiglio ad esempio Node. Node non te lo consiglierei perché per fare sicurezza ha più senso magari che impari a programmare system programming, per cui C++ Anzi, sì, piuttosto che Rust, Go, eccetera. Se invece vuoi fare front-end, vabbè, vai su JavaScript, TypeScript, eccetera. Se vuoi fare back-end, valuta un po' le alternative che ti dà anche il mercato in questo momento. Ti consiglierei magari di andare su Stack overflow, LinkedIn, eccetera, vedere anche un po' le offerte di lavoro che ci sono per farti un'idea di cosa è richiesto. E poi, riservati sempre il diritto di cambiare idea. In questo momento magari è molto facile trovare lavoro nell'ambito Node.js, Java e PHP, però uno di questi linguaggi potrebbe anche non piacerti. Il mio consiglio è sperimento al più possibile e arriva al punto in cui dici, arriverà il momento in cui dirai, ok non mi sta piacendo tantissimo, magari provo, boh, scala. E quello ti piace, punta su quello. Devi fare qualcosa che ti piaccia giorno per giorno, altrimenti non ne viene a capo, ti passerà la voglia di fare questo lavoro, ma almeno questa è la mia idea. Poi Valerio mi chiede come si convince la propria azienda a rilasciare software open source. Allora, innanzitutto non so se sei uno sviluppatore, ma dobbiamo essere noi sviluppatori i primi a essere convinti della bontà del software che realizziamo. software open source ha diversi tipi di licenze, per cui quello che ti posso consigliare è leggiti i vari tipi di licenze che esistono. Esiste ad esempio la GPL v3 che dice il software ce l'hai gratuitamente, puoi rivenderlo, puoi modificarlo, però devi ricondividerlo con la stessa licenza, per cui se tu lo rivendi a qualcuno che a sua volta lo modifica è costretto a dare la paternità dell'opera e dire tu puoi, mio cliente, utilizzare il mio software ma devi utilizzare la stessa licenza per cui si crea una catena tale per cui se uno dei tuoi clienti a catena ha modificato il software questa modifica tu la puoi fare tua. Serve per migliorare sempre di più il software di partenza. Esistono altri tipi di licenze come la MIT invece sono molto permissive e ti dicono fai quello che vuoi. L'unica cosa magari la paternità dell'opera rimane mia, la proprietà intellettuale praticamente non esiste, cioè ok sono io che ho scritto il software ma ci puoi fare assolutamente quello che vuoi. Per cui primissima cosa informati sul tipo di licenze che possono essere applicate al tuo software. Secondo, se il software che scrivi e che vuoi mettere open source mostra dei meccanismi, delle logiche di business molto importanti per la tua azienda, valuta se effettivamente può essere il caso, perché soprattutto se l'azienda è piccola i competitor possono cannibalizzarti tramite il tuo stesso software. Per cui questo bravo, come hai fatto unire in mente un altro contro del software open source, bisogna essere molto bravi a gestire il proprio codice open source. Dopodiché penso che un imprenditore Dipende qual è anche la priorità dell'imprenitore. Come dicevo prima, assumere sviluppatori immagino che non sia molto facile e scrivere codice open source di alta qualità può aiutare sicuramente ad assumere perché hai un portfoglio come azienda che dice guarda sto sviluppando questo, se tu sviluppatore vuoi far parte di questo cambiamento puoi venire con noi. Questa è un'arma molto potente che sicuramente puoi utilizzare. In più c'è il fatto che se scrivi un buon software e hai delle persone che tutto sommato ci lavorano gratis, ci guadagna anche l'imprenditore. Poi, allora Matteo mi scrive, mi ringrazia per la presentazione, grazie a te per essere qua. Anche noi ci stiamo approcciando al mondo dell'open source, vogliamo rilasciare un piccolo framework per fare web AR con Unity 3D. Qualche consiglio per, diciamo, rilasciare il progetto al meglio, o errori da evitare. Ci sono delle best practices da seguire? a parte parlarne sui propri social e cercare di creare engagement, eccetera. Allora, Best Practices sicuramente quello che ti dico è il progetto molto interessante, non ne conosco molti, per cui quello che potresti fare è andare a vedere come si muovono i competitor. Tu dici Unity 3D, prova a vedere Unity o repository affini come si comportano. Sicuramente dovrete impostare un code of conduct in modo che chiunque voglia partecipare al progetto PenSource abbia una serie di regole da rispettare, ad esempio nomina le variabili in inglese, utilizza camel case e non pascal case, insomma una serie di regole del genere. Dopodiché scrivete un bel readme, vi prego, è l'unica cosa che davvero mi sento di chiedere, un bel readme che abbia tutte le informazioni che servono a chiunque per iniziare ad utilizzare il software che state scrivendo. Questo secondo me è molto importante perché tante persone abbandonano un progetto open source nel momento in cui non trovano quello che stanno cercando e spesso noi sviluppatori Diciamo che ci interessa molto il software, un po' meno la presentazione almeno. Io mi accorgo che a volte per me è così ed è una cosa che tento di correggere. Rilasciate tanta documentazione, questo è assolutamente fondamentale per avere successo quantomeno nel software open source. Dopodiché esistono anche dei social che possono aiutarti a diffonderlo, banalmente Reddit, Hacker News e Product Hunt. Lì trovate davvero tanta gente che dice, oh bello sto progetto, voglio partecipare anch'io. Per cui ecco, il vero consiglio che ti do è guarda davvero dei repository che ti attirano, prova a capire perché ti stanno attirando e quanto è facile iniziare a lavorare col software presente in quel repository. Quando riesci a risponderti a queste domande hai trovato una modalità di lavoro che può essere assolutamente comoda anche per gli altri.

Sì, Matteo non so se vuole anche... ho visto che mentre rispondevi ha alzato la mano, quindi do un attimo la parola per capire effettivamente se c'era una cosa in più che voleva aggiungere rispetto a qualcosa che avevi detto. Dovresti poter parlare, Matteo?

Mi sa che sei in muto, Matteo. Mi

senti? Sì. Ciao, intanto grazie mille per la presentazione. Grazie a te. Molto carina. E' utile anche per la risposta che hai appena dato. Allora, sì, noi stiamo per... abbiamo creato questo framework, diciamo, perché le soluzioni attuali per lavorare in realtà aumentata, soprattutto per i web, sono molto poche e soprattutto quelle che ci sono sono tutte a pagamento, a licenza e costano un casino. Che è appunto il discorso che facevi tu prima. e sui social stiamo cercando di creare insomma dell'aspettativa comunque stiamo sharando i nostri progetti, stiamo condividendo i nostri progetti e i nostri risultati e la gente è interessata soprattutto anche persone business che chiedono quando sarà disponibile ma lo metterete a pagamento eccetera eccetera perché vogliono utilizzarlo nelle proprie soluzioni. E quello che mi chiedo è, intanto, come hai detto tu, che può essere una palla difficile da gestire. Secondo te come faccio a capire il punto in cui io metto questo progetto che comunque è ancora in fase di sviluppo, lo metto scaricabile gratuitamente? E come faccio però a non farmi rubare l'idea? Nel senso che magari la cosa è forte, però sono aziende appunto, perché la cosa è molto interessante per le aziende, che la vedono, te la fregano un attimo, oppure magari tu che non sei conosciuto eccetera, finisci per avere un repo gratuito con l'idea che è buona, fregata e non fai engagement tu che l'hai creata. Non so se mi rendo

l'idea. Allora, innanzitutto ti dico esistono delle metodologie di sviluppo chiamate inner source tali per cui effettivamente sviluppi un codice proprietario con l'intenzione poi finale di rilasciarla open source per cui lo sviluppi come se fosse a tutti gli effetti open source e quando è diciamo in beta, ad esempio, oppure in una versione stabile, lo metti open source e dici guardate il mio prodotto è già pronto. La cosa più logica a quel punto per qualcuno non è copiarti l'idea, ma andare a collaborare. Per cui una possibile soluzione è quella appunto di sviluppare in inner source, per cui col tuo team lavori magari anche su GitHub. Adesso hanno messo i repositori privati, gratuiti per chiunque, per cui puoi lavorarci su un repositorio

privato. Stiamo facendo esattamente

così. ottimo quando arrivi al punto che dici ok sono in una beta oppure in una versione stabile a questo punto la rilasci come open source metti tanta documentazione e credimi che quello è proprio quello che fa la differenza tra un buon software e uno pessimo è meglio un software brutto con della buona documentazione secondo me perché ti permette almeno di capire dove andare a modificare cosa per cui buona documentazione buona community perché comunque ci sarete tu e i tuoi colleghi che ci lavorate se siete anche abbastanza rapidi a rispondere so come dire, non a fixare bug o fare nuove feature, ma se siete rapidi a dare una risposta alla community, la community poi vi ricompensa dicendo ok, magari ci mettete anche un po' a implementarla, magari non è quello che mi aspetto, ma c'è stato un dialogo. Per cui a quel punto la cosa più logica per chiunque è, uno, prendere un software fatto e finito e dire lo forco, faccio una modifica, e poi se tu ti accorgi, perché comunque su GitHub vedi chi ha forcato cosa, dici va bene, hai fatto la tua modifica, magari ho utilizzato la GPL V3, per cui sei obbligato ad utilizzare anche tu quel tipo di licenza, mi prendo la modifica che hai fatto e ti do la paternità di quella modifica. Per cui a quel punto, dato che, come dicevo prima, far software è qualcosa di molto complesso e molto dispendioso sotto vari punti di vista, credo che sia difficile, sinceramente, arrivare al punto in cui qualcuno con un software fatto e finito dica, no, io lo rubo. No, è più facile che lo implementa, più facile che usa il tuo. Per cui quello che ti posso consigliare è metterlo open source magari quando senti che è

pronto. Ok, infatti è proprio quello che stiamo cercando di fare. Va bene, perfetto.

Perfetto. Grazie

mille.

Figurati.

Matteo, ti rimuto. Mi è venuta in mente una domanda nel frattempo che magari lo sfruttiamo anche poi per chiusura di questo intervento. Ricordo a tutti quanti che sarà poi inviato, lo riceverete via mail in modo da rivedere effettivamente e magari riflettere nuovamente col senno di poi su l'intervento intero di Michele, che ringrazio ancora, mi è venuto in mente un aspetto forse più legato a chi effettivamente magari è interessato a un cambiamento lavorativo, piuttosto che è anche una figura giovane, una figura junior che entra in

azienda.

Che cos'è che, secondo te, per la tua esperienza del tutto personale, cerca in un'azienda uno sviluppatore open source? Quali sono le qualità che dovrebbe avere un'azienda per uno sviluppatore open source che si vuole affacciare al mondo del

lavoro?

Allora, innanzitutto dipende dalle motivazioni che lo sviluppatore adotta per scrivere codici open source. Ci può essere lo sviluppatore che scrive software open source appunto per migliorarsi e a quel punto non ha grandissime pretese diciamo a livello aziendale. Per cui ci sono sviluppatori che scrivono ottimo codice open source per farsi notare da aziende. Facciamo un esempio Google. Google che è sicuramente una delle aziende più appealing in questo momento. Google ha tantissimi repository, quindi tantissimo software open source, ma la maggior parte di quello che fa effettivamente è nascosto, è proprietario. Per cui ci sta anche che uno sviluppatore si faccia notare da Google, collaborando nel loro ambito open source, per poi essere assunto e messo a lavorare su qualcosa che open source non è. Per cui c'è anche questa cosa da considerare. per uno che cerca lavoro o che comunque ha intenzione di cambiare la propria posizione lavorativa a quel punto scrivere codice open source appunto è utile perché nel momento in cui ti contatta un recruiter la cosa che puoi fare è dire va bene guarda qui c'è il mio codice, valuta tu se sono in grado di essere assunto in quella posizione. Dopodiché un'azienda un'azienda che assume uno sviluppatore che sente come proprio il tema open source può trarre giovamento anche dal fatto appunto di una metodologia inner source per cui non più l'aspetto gerarchico d'azienda in cui c'è il CTO che dice al head of technology che dice allo sviluppatore, al technical leader che dice allo sviluppatore per cui questa ramificazione ma una gestione un po' più, passatemi il termine, anarchica del software, tale per cui ogni sviluppatore di quel team può dare il proprio contributo in base alle proprie competenze, aspirazioni eccetera. spesso quello che succede in tante aziende effettivamente è che si mettono degli sviluppatori a fare quello per cui non sono portati o addirittura quello per cui non sono stati assunti. In un ambiente inner source questo non può accadere perché si può sviluppare, io ad esempio non sono forte in java, però so di poter dare magari una buona un buon contributo nella fase magari di CI, nella fase magari di testing, perché è quello che mi appassiona su altri linguaggi. Per cui è inutile che magari l'azienda mi metta a sviluppare Java tutto il giorno, perché non sarei molto competente in quello, ma posso dare un ottimo contributo da un'altra parte. Questo grazie a questo tipo di metodologia e queste differenze tra i vari sviluppatori vengono fuori soprattutto quando si adotta questo tipo di metodologia di sviluppo. penso che sia il momento in cui ogni sviluppatore vuole veramente dare il meglio di

sé. Ok, quindi ampliando anche un attimo la prospettiva, di per sé ritorniamo sul fatto dell'efficienza e dell'efficacia di adottare questo tipo di soluzione, anche questo tipo di tecnologia, comunque sviluppare software open source lato azienda perché magari permette davvero di valorizzare le proprie risorse piuttosto che invece metterle lì a fare, a ricoprire un ruolo, a fare attività che magari non le appartengono nemmeno. Quindi c'è anche un vantaggio, diciamo, Anzi, non anche, è un grandissimo vantaggio la tua azienda.

Assolutamente. Giovanni scrive, spesso le aziende in fase di colloquio chiedono di fare esercizi futili senza neanche guardarlo in profilo GitHub. Hai assolutamente ragione. Io non sono un grande fan dei colloqui tecnici in cui chiedono, so, fammi, non so, quicksort su una lavagna bianca, su una whiteboard. Quella roba lì non serve proprio sempre, io sono più dell'idea che un buon profilo github possa essere un ottimo portfoglio per uno sviluppatore, questo ripeto è un pensiero assolutamente personale Dopodiché, sì, è vero, ci sono tante domande futili. Considera che bisogna, nella maggior parte dei casi, scremare tanti sviluppatori. Diciamo, aziende come Google ti fanno domande un po' futili, appunto tipo domande su whiteboard, perché devono scremare un po' quelli che magari proprio non hanno l'esperienza necessaria per entrare. Dall'altra parte ti dico, io non sono laureato ma vedo molti profili di tab di universitari che studiano computer science che effettivamente non sfruttano i tab, per cui dall'altra parte c'è da dire che ci sono ottimi sviluppatori usciti da ottime università che però dell'open source non sanno assolutamente nulla Per cui è un po' colpa di entrambi, secondo me. Da una parte sì, le aziende non puntano tanto su GitHub, dall'altra noi sviluppatori magari non diamo il 100% su GitHub stesso. Io sono sicuro, e lo so anche per esperienza personale, che se hai un buon profilo GitHub, o quantomeno un profilo curato, le aziende poi lo notano. O quantomeno glielo puoi far notare anche tu. Io ti dirò una cosa, in tutti i colloqui che ho fatto in vita mia, ho fatto forse tre volte test tecnici proprio perché avevo GitHub a supporto. mi è capitato rarissimamente di fare test tecnici e domandi futili, che anche secondo me sono futili, proprio perché avevo un profilo GitHub che poteva in qualche modo far vedere le mie

competenze. E ultimo consiglio, cosa vuol dire un profilo al 100% soprattutto, magari se ci sono gli ultimi studenti che sono un attimo collegati, un profilo di tab, chiamiamolo secondo il tuo compitivista, 100% comunque utile anche magari a farti risparmiare appunto tempo che sia un una grande cosa a lato candidatura naturalmente perché ti fai magari uno step in meno, sia anche lato azienda magari uno spreco di risorse e di tempo minore perché già guardando il tuo profilo possono già valutarti. Quali sono i tuoi

consigli? Allora, vedete ancora il mio schermo giusto? Questo ad esempio è il mio profilo Github, io lo curo abbastanza perché comunque collaborando in diversi progetti mi piace anche tenerlo in ordine, mettiamola così. Vi faccio un esempio, inizio 2019 mi ha contattato Uber per fare un colloquio e mi hanno contattato proprio perché avevano visto la mia homepage su Github. e mi hanno detto, cavolo è fantastico, hai tutta la green bar. La green bar è questa area verde che vedete nel mio profilo, in cui ogni quadratino rappresenta un giorno e più il verde è scuro, più ho contribuito al software open source in quel giorno, sostanzialmente. Per cui soprattutto le grandi aziende puntano tantissimo su questa cosa qua. per cui collaborare, a parte far vedere magari che avete collaborato con Facebook ad esempio, io ho collaborato con Duckling, è un progetto open source di Facebook, mi è piaciuto tanto, ho voluto dare una mano, è chiaro che se mi presento a un'azienda dicendo guardate sono uno sviluppatore, non ho ancora molta esperienza e non ho neanche un profilo github, l'azienda mi dice va bene in qualche modo le tue competenze le devo testare se invece mi presento e dico guardate ho collaborato con facebook, collaborato con node, con microsoft e tutto quanto allora l'azienda si fa anche un'idea diversa magari di quello che lo sviluppatore sa fare ed è una cosa che secondo me paga Una lezione che ho imparato è che la community open source è molto welcoming, cioè è nel loro interesse fare in modo che tu contribuisca, per cui non abbiate paura magari di prendere un progetto di Google e andare a modificare il codice e mandarglielo indietro perché è nel loro interesse fare in modo che voi scriviate il miglior codice possibile e quel miglior codice possibile poi il vostro biglietto da visita per le aziende, qua mi riferisco soprattutto agli studenti pubblicare anche le più piccole stupidaggini su github può avere senso io ad esempio ho fatto in questa slide vedete aquarium è una blockchain scritta in typescript è ovvio che non è un progetto che andrà mai in produzione è un progetto puramente accademico però è qualcosa che un recruiter tecnico può dire ok hai questo tipo di competenze vedo che questo tipo di applicazioni le sai sviluppare Per cui anche se non sono progetti che chiunque può utilizzare, potete dimostrare a qualcuno però quello che sapete fare. E questo non spaventatevi, la cosa migliore che possa succedere è che qualcuno vi scriva e vi dica il vostro codice fa schifo e voi a quel punto gli direte ok perché? Ed è lì veramente che ci sarà la crescita professionale lato sviluppo

software. Ok, mi venite a dire quindi che sicuramente il far parte della community open source e il mettersi comunque in gioco debba evolvere comunque da un'apertura, una disposizione all'apertura, ad essere pronti a ricevere soprattutto critiche che poi siano anche appunto costruttive, cioè da questo punto di vista qua.

Esatto. Una cosa da tenere sempre a mente è che noi non sappiamo cosa non sappiamo, per cui Facciamo sempre domande, anche se sembrano stupide, non sono mai stupide. L'unico vero modo per crescere in questo ambiente, secondo me, per quello che ho imparato negli anni, è trovare qualcuno che sappia correggervi. Per cui il software open source, questo lo sa fare molto bene. Ci corregge, ci migliora e ci rende sviluppatori

migliori. Ok, direi che con questo, diciamo, sembrava quasi a pennello, non era programmata, ma con questo tipo di analogia e anche metafora assolutamente vedo che non ci sono domande e io ti ringrazio comunque per la disponibilità e comunque per l'ora passata e soprattutto per i preziosi consigli anche per un recruiter. per un utilizzo migliore che sicuramente farò e condividerò con il resto del team, soprattutto di Github, che conoscevo ma non in modo così approfondito, soprattutto sul lato greenbar. Ti ringrazio ancora, ti ringrazio a tutti i partecipanti che sono rimasti connessi fino adesso, Appuntamento, naturalmente, se volete approfondire altre tematiche relative magari alle Data-Driven Solutions. Soprattutto, vi rimando anche al webinar di domani con C-TECH, quindi se vi interessa soprattutto l'ambito o avete conoscenti soprattutto del gine di sesso, quindi comunque ragazze che vogliono entrare nel mondo STEM, nel mondo dell'informatica, nel mondo tech, che si chiedono un po' come fare o stanno sperimentando difficoltà, domani sarà l'intervento di due persone, due donne, che hanno sicuramente fatto valere la loro presenza nel mondo tech e digital, quindi un appuntamento abbastanza imperdibile, così come quello di giovedì con le Data Driven Solutions di Michael Sarugia. Quindi, nel caso, guardate un po' il programma di Lavoro Digital Italia e vedete anche quelli che sono i webinar che potrebbero interessarvi. Io Michele ti ringrazio ancora e ringrazio tutti quanti. Ci vediamo presto e riceverete assolutamente la registrazione in modo che comunque possiate riprendere tutto quanto detto nell'ultima ora. Ciao a tutti, buona

serata! Ciao a tutti, grazie