Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua sul bar degli sviluppatori.Io sono con Andrea.Ciao Andre, com'è? Ciao Mauro, ciao a tutti.Tutto benissimo, grande grande episodio.Come va dalla capitale? Come stai? Era da un po' che non ci sentivamo.Eh sì, sono stato un po' impegnato, ho girato un po' indaffrato col lavoro, piove, fa caldo, non si capisce come bisogna vestirsi, la gente si raffredda, raffreddore, tosse, però siamo in piedi.Dai dai dai, anche perché oggi secondo me esce una di quelle super puntate come piacciono a me.Si la sto aspettando da un po' questa lo sai lo sai.Prima di parlare dell'ospite e presentarvi l'ospite il mio compito, sempre un po' noioso, quello di ricordarvi i nostri contatti.Info@gitbar.it.Gitbar.it a proposito tra un po' aprirò il repository e il sito è stato aggiustato usando Astro quindi abbiamo abbandonato Gatsby siamo passati ad Astro se qualcuno vuole dare una mano c'è qualcosa da fare quindi preparerò un po' di issue in settimana perché abbiamo bisogno d'aiuto io non ce la faccio più col tempo.È il momento perfetto perché c'è anche l'Oktoberfest, quindi se tagliamo l'issue con la lab l'Oktoberfest possiamo far entrare tutta la community a contribuire e se raggiungete, se ricordo bene, 5 pull request registrandovi avete indietro il gadget degli organizzatori dell'Oktoberfest.Sì, fighissimo, naturalmente tipo il gadget io l'ho preso l'anno scorso, la cosa divertente è che era la bellissima maglietta dell'Octoberfest, l'unico problema è che in realtà ho pagato più di 10 euro di dogana, quindi praticamente se me la compravo spendevo meno Ma l'importante è fare open source dai! Ma sì ma e poi vuoi mettere i fantastici sticker no? Vabbè noi abbiamo un feticismo Ripeto porterò gli sticker di Geetbar a Code Motion per tutti quelli che che verranno perché sì C'è un panel di codemotion dove ahimè dovrete risoportare la mia voce ma ve lo dirò alla fine Comunque tra I nostri contatti c'è anche @brain_repo su twitter e il gruppo telegram Accipicchia quante persone quante belle discussioni Dai No molto figo davvero se non l'avete ancora fatto io so che molti di voi non l'hanno ancora fatto mi raccomando iscrivetevi perché secondo me è il posto giusto dove scoprire l'altra faccia, quella bella, di Geetbar.Detto questo io direi che possiamo iniziare.Benvenuti su Geetbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango per creare, nel modo più efficiente possibile, quei prodotti digitali che quotidianamente usiamo.[Musica] Andre non ti avevo avvertito ma avrei il super...vorrei avere il super piacere che presentassi tu il nostro ospite Ma io lo faccio con immenso onore anche perché sono mesi che sono lì aggrappato alle cose basse di Mauro per dire "Dai chiamiamolo, dai scriviamogli" Dobbiamo fare un episodio con lui e quindi con immenso piacere vi presento Francesco Corti.Ciao a tutti buonasera e grazie, presentazione ineccepibile, mi sento molto onorato, grazie per l'invito.Il piacere è tutto noi, nostro.Oggi è una giornata un po' così, quindi ecco qua, distrugge il microfono.Ve l'ho detto che era una giornata un po' così e quindi prendetela un po' come va.Francesco è il product manager di un prodotto che se non avete usato nel vostro contesto lavorativo dovete usare.Il product manager di backstage, il produttone di Spotify che parla ai developers e alle organizzazioni.Però prima di introdurre il Il prodotto.La mia domanda è chi è Francesco? Bella domanda.Allora, Francesco è un ultra cinquantenne, ahimè, orgogliosamente si definisce un software engineer.Io ho fatto sviluppo per più di vent'anni, toccando tantissimi di settori, la tecnologia la lasciamo perdere perché si parla sin dagli anni '90, ma...Ah, nasco ovviamente con una laurea in informatica, Pisa, che sono di Firenze, si sente piuttosto bene, e niente, da tech leader, project manager, pre-sale, consultant per diversi anni, e poi Un po' per caso, un po' per follia totale, grazie alla voglia di aprire un blog post, questo si fa negli anni 2000, ho cominciato a scrivere blog tecnici su cose che mi appassionavano.Mi sono appassionato un po' al mondo dell'open source e ho cominciato a girare un po' per conferenze, facendo piccoli talk, conoscendo un po' di gente, prendendo ferie e pagando miliaggi da solo, come tanto si fa per passione, eccetera, eccetera.E poi, quasi per magia, ho ricevuto un'offerta per fare developer advocate per un prodotto open source business che si chiama Alfresco.E poi dopo sono entrato a fare product manager, product management, e poi sono atterrato su Spotify, dove lavoro oggi.tutto questo, tutto questo un po' per follia, e tutto questo essendo un po', non voglio dire un pioniere perché non è vero, ma avendo un po' anticipato il momento del lavoro remote, perché io faccio remote da circa il 2015-2016, quindi insomma è stato un bel percorso, sì, assolutamente.Hai detto che hai un passato come software engineer, e la mia domanda è, Cosa ti porti di quell'esperienza nell'attività di product manager? Tantissimo.Prima di tutto il fatto che io continuo ad avere una passione sfrenata per lo sviluppo e credimi non me lo fanno fare ma io ho un'invidia clamorosa per tutti i con cui lavoro, che sono assolutamente più bravi di me quando sviluppavo, ma rimango assolutamente, come dico, un developer at heart, cioè nel senso mi piace tantissimo.Il fatto che io ho lavoro e ho sempre lavorato su piattaforme per gli sviluppatori è quello che io amo fare, perché mi sento assolutamente parte di questo tipo di persone.E lavoro su piattaforme, sempre lavorato su piattaforme che sono molto tecniche, perché è dove mi piace di più.Ora lavoro su una piattaforma che aiuta la developer experience, quindi è un po' il non plus ultra per me, e open source, quindi è un paradiso.Champagne.Sì, cioè è proprio...Per me è proprio dove io, come si dice a Firenze, ci sguazzo, perché è proprio così che mi piace.Però, diciamo, quando soprattutto si fa un product manager, magari forse qualcuno si domanda anche un po' cosa fa un product manager, che è un po' quello che dovrebbe guidare la direzione del prodotto e dire verso cosa bisognerebbe tendere per migliorare il prodotto e per renderlo migliore da tutti i punti di vista.Ovviamente quando si parla di cose che poi riguardano i developer bisogna un po' sapere che fanno questi developer, altrimenti non è che si può aiutare non sapendo di cosa parliamo, insomma, ecco, da questo punto di vista.Super interessante e a questo punto per te, Francesco, come è essere il product manager dello strumento più chiacchierato da diversi mesi a questa parte? No, perché io seguo gli sviluppi di questo strumento da più di un anno, da quando era uscito in alfa, poi beta, la prima stable in primavera, quando era non ricordo bene il mese, però diciamoci la verità, davvero miei complimenti, c'è stata un'impennata di agliozione negli ultimi sei mesi, incredibile, e possiamo dire che forse è anche merito tuo? No, allora merito di tutti e considera che dietro c'è questa cosa nasce da lontano e davvero si sente dire agli sportivi "questa mia vittoria alle Olimpiadi nasce da lontano quando da piccolo mi allenavo" è esattamente la stessa cosa e e assolutamente questo è un effort di una squadra spaziale, di un'azienda che effettivamente ha tanto da dire e da dare e che dimostra che è Spotify.Quindi, diciamo, io posso solo essere orgoglioso del fatto che faccio parte di questo team stellare dove voglio pensare di aver dato il mio contributo, ma solitamente un contributo insieme a tutti, anzi, è minore rispetto a tanti altri.Tutto nasce alla fine da un'azienda stellare che nel 2014 aveva questa esigenza di crescere in maniera esponenziale, passava da centinaia di sviluppatori a migliaia di sviluppatori, tutto in meno di un anno.C'erano 400 di Spotify di sviluppatori, dovevano diventare 1.350 in circa 8 mesi.Ora, se voi pensate a quale possa essere il casino e la sfida di anche solo identificare e assumere 800 e passa persone e tirarle dentro un'unica app… Fare un boarding a tutte queste persone.Cioè, è una roba spaziale, cioè è una roba che farebbe paura a chiunque.E da questa sfida poi è nata quella che è l'idea di un prodotto, grazie ripeto a dei pazzi ma in senso positivo, che hanno poi portato a far crescere questa cosa fino a farla diventare un qualcosa che funziona per 4000 sviluppatori su una app che è tanta tantissima roba.Questa cosa...Ok, chiediamo una domanda.Mi è piaciuta un sacco questa risposta, diciamo un po' anche political cord, siamo davanti a una birra, possiamo anche...Il vuoi più cattivo è questo, credo.Esatto, capito? E' uno scherzo.E quindi, diciamo, senti anche un po' questo peso, questa responsabilità? No, no, perché guarda, ascolta, il fatto è questo, il peso responsabilità, non lo so io, ora non so fare, a me piacciono tanto i paragoni, anche un po' estremi, eccetera, veramente quando...cioè è più un'adrenalina questa responsabilità, cioè è l'adrenalina di giocare...io ho la percezione di giocare in Serie A e quindi devo dirti, c'è una piccola esperienza personale, fa parte un po' del gioco, no? L'esperienza personale è che quando...Io vi dicevo che mi ricordo la sensazione appunto di quando ho ricevuto un'offerta da Spotify e mi ricordo che la prima impressione è stata "il paradiso", la seconda impressione dopo un'ora è stata "porca miseria, ma questi sono forti, ma io ce la farò?" Perché è vero, perché quello che dico sempre, l'ho detto anche in un'altra registrazione che ho fatto qualche mese fa, io credo che la vera differenza in lavorare in Spotify non è nel building, negli uffici, nelle tecnologie, ma è nelle persone.Il livello delle persone è veramente, veramente rilevante e questo io l'ho sentito dire tante volte lavorando, ormai diverse aziende, che le persone sono importanti, spesso mi sono sembrate anche un po' di fuffa detto dai proprietari per motivare le persone, perché poi alla fine questa cosa aveva poco seguito, non in tutte le aziende, ma in tante, Spotify la differenza la fa le persone, effettivamente.Quindi, diciamo, c'è questa cosa qua.Il fatto che sia un progetto di grande successo è anche sotto i nostri occhi, Vi ne dico uno che è una cosa che sveleremo al prossimo CubeCon, quindi in un paio di settimane.Stiamo facendo un conteggio più o meno di quanti developer pensiamo di stare usando.Non lo sappiamo perché è un progetto open source, quindi quanti developer stanno usando più o meno il nostro prodotto.Non avevamo fatto in conto, dovremmo essere solo quelli che hanno già adottato, quindi non quelli che stanno valutando il prodotto.Credetemi, ci sono circa 280 aziende che stanno valutando il prodotto, ce ne sono più di 300 che lo adottano.Dovremmo essere in una potenziale bacino, perché non sappiamo il numero, di circa un milione e due, un milione e 300 mila developer che stiamo aiutando, quello che si dice, a avere una vita migliore e più serena.Sì, guardiamoci chiaro, io non so voi, ma sviluppare nel mondo di oggi è fantastico, perché è veramente potente, cloud, on-premise, pipeline, test, quello che ti pare, però è difficile.Sì, porta in gioco tantissimi elementi che vanno tenuti a bada e tenerli a bada rischia di essere complesso.Tu hai detto che backstage è un prodotto che genera valore per i developers.È da product manager, quindi colui che tiene l'eredini di un prodotto.Come realizzare un prodotto di DX, di developer experience, e avere come utente un developer? Sì, è diverso.Un'altra cosa, non sono l'unico product manager di backstage.e anche per giustizia, no, per mille motivi.Io sono un po' più visibile perché sono molto sull'open source, molto social e quindi all'esterno mi si vede di più, ma ci sono altri tre product manager internamente che si occupano di vari filoni.Questo tanto per dirvi che comincia a essere una struttura rilevante.Possiamo dire che, giusto per chiudere la parentesi, diciamo ruolo in tutto questo, ciò che prima facevi come advocate per una libreria, un SDK, un API eccetera eccetera, ora lo fai per uno strumento enorme.No no, era molto grosso anche, no, L'advocate è un ruolo diverso dal product manager e ovviamente quando ho cominciato a lavorare come advocate ero già in un'azienda non più italiana.Io ho lavorato tantissimo e quasi esclusivamente per aziende italiane, magari crescendo di spessore di azienda, c'è il piccato di diffusione, eccetera, eccetera, ma quando ho cominciato a fare il vanno per advocate.Poi il product manager sono andato su aziende worldwide che hanno un concetto diverso proprio anche nel discorso dei ruoli e anche delle nomenclature che sono un pochino più precise e se vogliamo anche definite da questo punto di vista.In Italia siamo un po' tutti manager di qualcosa in maniera un po' ben definita, soprattutto un un po' tuttologico, lo dico anch'io di me stesso, ma non perché sia non vero, ma semplicemente perché il tipo di lavoro che facciamo in Italia ci porta un po' più a toccare diverse cose, all'estero è un pochino più razionalizzato.Ma il mestiere di developer advocate e il mestiere di product manager è diverso.È diverso, è proprio diverso lo scope, perché l'advocate deve stare in contatto con i developer, renderli contenti e capire le esigenze di come un developer usa i vari prodotti, riportarli al product management e aiutarli a capire il prodotto che si usa.Un product manager invece ascolta tutti i vari utilizzatori e cerca di capire cos'è la cosa che serve e quello che lo può migliorare.Quindi per questo fare il product management di un prodotto molto tecnico, ripeto, al fresco dove lavoravo prima e backstage dove lavoro ora, sono prodotti molto tecnici.Bisogna parlare con i developer e avere una sensibilità di capire un po' qual è la problematica di una pipeline, di quella che è un mestiere prettamente tecnico.Tenete presente, una cosa che mi sto accorgendo, è che i product manager, in generale, non sono affatto tecnici.la stragrande maggioranza dei product managers sono persone con MBA, quindi con Master in Business Administration, tendono a definirsi dei mini CEO, quindi sono una cosa molto lontana dai tecnici e avendo la necessità di avere un product manager per strumenti tecnici è quasi un po' la contraddizione in termini.vero, verissimo.Tra l'altro, Francesco, voglio aggiungere una cosa, scusa se ti interrompo, ma secondo me vale la pena puntualizzarla.Io in questo periodo sto dedicando tanta tanta attenzione al mondo dei DevRel.Sto studiando proprio a livello sistemico le interazioni le dinamiche che si creano.E una cosa che mi è chiara è che emerge un elemento che in qualche modo hai mostrato tu.Cioè l'elemento che nel momento in cui tu realizzi un prodotto dove il tuo utente è un developer o un'organizzazione di developer, il tuo utente non è più un utente o un cliente, cioè tu non vendi più a un utente o un cliente, ma attivi quel processo di co-creazione che è molto più forte perché il developer crea e tu sei lo strumento che utilizza per creare, per cui non è più "ti vendo un prodotto" o "ti do un prodotto" ma ma è un "creamo insieme" e questo porta con sé naturalmente tanta energia positiva, ma anche delle responsabilità grosse, mi sbaglio? Ascolta, dimmi una cosa, ma secondo voi i developer comprano? Cioè, il discorso è questo, il developer tendenzialmente in ogni organizzazione A) non ha budget, perché sono gli IT manager che hanno il budget, oppure il business che ha budget, non i developer.E poi se tu hai come target i developer, cioè quindi i team che fanno sviluppo e gli sviluppatori, lo sapete un esercizio bellino che si fa è quello di prendere una persona di marketing, marketing puro, e cominciare a spammare le email, contattare le persone, parlare una persona che parla solo marketing con un tecnico.Allora i developer dice a Firenze gli vengono le bolle dopo tre minuti.La prima reazione che ha un developer A) all'email B) ai contatti diretti C) a) guarda io non so gli strumenti che usi, non ci capisco nella cosa tecnica ma ti voglio vendere qualcosa, la prima reazione è guarda non mi romper le scale.Quindi ai developer...ma che vuoi da me? Quindi i developer non comprano.Però questo non vuol dire che non abbiano un enorme potere di influenzare chi ha il budget.Quindi il cosiddetto marketing al developer non è che non è efficace.Ci sono proprio prodotti, e questo l'ho visto in tantissimi prodotti di fascia alta, ma insomma non solo di fascia alta, il Il fatto di fare il target dei developer non è affatto un target secondario, è semplicemente che hai bisogno di comunicare con i developer in maniera completamente diversa di come comunichi con una persona di business.Perché alla persona di business te gli devi dire "ascolta, te hai questo problema, c'ho io la soluzione, questo è il pacchetto, dammi i soldi, io ti do la soluzione".Se te gli dici "oh sì, ero un developer" non ti sta nemmeno ad ascoltare, non sai nemmeno cosa vuol dire.Se devi deve attrarlo, farlo divertire, farlo divertire appassionare lo strumento che usa e capire che e soprattutto darglielo il più possibile in maniera gratis e aperta perché un developer non si vuole stare a rompere le scatole con la licenza, con pagare perché poi deve andare dal manager e chiedergli il budget, il budget non glielo dà, ma che che è quel giocattolo eccetera eccetera.e poi a un certo punto fargli, dopo che abbia capito il valore, questo valore lo deve o riportare al business e all'IT manager e allora diventa un processo più commerciale.Nella prima fase, quella di appassionare il developer, di coinvolgerlo, di dargli gli strumenti giusti, di farlo divertire, il devrel, come dici te, la developer experience, no, la developer advocacy, è quello che è il lavoro del developer, è uno spazio, perché te non è che gli devi vendere cose, te li devi far divertire e ti devi divertire con loro, perché tanto è tutto relazionato, no? Quindi in questo l'open source gioca un ruolo spaventoso, perché dimmi se cosa c'è meglio di una roba gratis dove c'è una community di migliaia di persone che tutte insieme si appassionano a uno strumento.Spaziale.Sì, tra l'altro abbiamo parlato di costi, io ci tengo a puntualizzare perché stiamo parlando anche di un prodotto open source, i costi non sono necessariamente i costi di licenza ma i costi d'adozione.Io mi immagino portando una certa tecnologia vuol dire impegnare effort, tempo, energie per l'adozione e quello è un costo a livello manageriale.Però la cosa interessante proprio del product manager di un prodotto tecnologico open source o meno destinata agli sviluppatori, è che deve essere proprio esplicito il rapporto in termini di co-creazione.Io ho fatto, avevo un'azienda mia per tanti anni, quindi ho fatto dalla parte tecnica alla parte commerciale vestendo 70 cappelli e probabilmente per quello che un po' ne sto perdendo, ma no, scherzi a parte, là ho capito veramente che quando si parla con un cliente qualunque.Questo questo questo procedo di cocreazione può esserci o non esserci, è bene o male, ci sono tutta una serie di trick che riesci a vendere.Ma, caspita, l'engineer che ha lo spike, il POC, come strumento di business allocation, di budget allocation, perché tutto parte da quello, dall'esperienza che poi viene riportata ai livelli più alti, devi capire che con te puoi creare, perché quello che lui fa è creare, quindi tu devi essere funzionale a questa creazione e questo genera una responsabilità importante.L'impatto di questo tipo di strumenti poi non è solo individuale o a livelli di business, Ma una cosa che sto vedendo, specie molti strumenti open source, è che hanno un impatto a livello organizzazionale.Non mi viene neanche il termine in italiano.Organizzativo, dici? Organizzativo, esatto.E allora a quel punto la mia domanda è, cos'è backstage nell'ottica di Spotify, però cos'è backstage per Spotify? in quel caso d'uso specifico? No, backstage per Spotify è lo strumento con il quale viene fatta l'app musicale che tutti conoscono e tutto quello che ci c'è intorno.Cioè, internamente Spotify è lo strumento in mano ai developer e non solo, perché ci sono tante centinaia di persone che che fanno machine learning, data engineering, che non sono proprio developer.Ovviamente non tratto poi quelli che sono QA/S.- Qui è la science.- Sì, tutta la loro valigia.Ma non tratto nemmeno quelli che sono poi designer, che sono tecnici, ma non squisitamente developer e tutti internamente usano backstage perché risolve dei problemi e in particolare risolve dei problemi noi diciamo at scale, cioè considerando che l'organizzazione passa da centinaia a migliaia, decine di migliaia e su, su, su.Quindi in realtà Backstage è lo strumento di sviluppo esterno, non è uno strumento di sviluppo, non è una buona espressione, ma è uno degli strumenti che aiutano per coordinare tutto stambaradandi 4.000 persone che fanno una roba.Quindi, tanto per dirne una, io quando ho il primo giorno in Spotify, come tutti, mi è arrivata una simpatica e-mail con tutta una serie di documentazioni e link ai documenti e i corsi che erano da fare erano su Backstage.Cioè, non corsi per imparare Backstage, li fruivo tramite Backstage.quindi tutte le longboarding l'ho fatto là sopra e questo lo fanno i suoi sviluppatori e ti insegnano che qui si lavora più o meno così ma non perché te lo dice l'azienda perché funziona e perché aiuta quello che è l'esperienza degli sviluppatori e quindi è un vantaggio, è un plus avere questo tipo di strumenti.Una cosa che funziona per Spotify è il fatto che questo strumento non è uno strumento che sia costretto a usare, ma effettivamente la gente lo usa perché ha un vantaggio.E il vantaggio, ora, non mi voglio dilungare, anche perché ho sentito che sia del CodeMotion, mostro ci sono anch'io, così magari ci si vede anche.Ci sarà un talk in particolare su questo, dove si vede un po' perché è vantaggioso utilizzarlo, cioè alla fine perché si aiutano i sviluppatori, perché è una cosa di marketing o perché davvero funziona.Ecco, la questione è quello.Chiarissimo.Sempre riguardo a questo, cioè, ci ha detto perché backstage, cioè perché Spotify ha voluto creare backstage, come Spotify, SuperJu, Agadiride usa backstage, mi pare, diciamo, al lato sviluppo al 100%, lo comprendo benissimo, me ne ho conosciuto, però la percezione Francesco riguardo alle altre aziende con cui sicuramente avrai parlato, discusso, eccetera, eccetera.Secondo te, per le altre aziende, che cos'è backstage? Sì, sì.Guarda, io una cosa che mi piace tanto del lavoro che sto facendo ora è che sono in contatto con tantissimi agli adopter e questo è fantastico e vorrei anche essere in contatto di ma poi il giorno è limitato.Allora, è una cosa...c'è tanti elementi.Allora, sicuramente tutte le problematiche che Spotify ha affrontato creando poi backstage sono problematiche che sono presenti in tantissimi...probabilmente in tutti gli altri adopter.Probabilmente Spotify, e qui si ritorna al fatto che Spotify, insomma, la gente è forte lì dentro, è riuscita ad anticipare la problematica e a svilupparla in maniera concreta e quindi in realtà quando io parlo con le aziende fuori e gli dico che Spotify esiste perché c'era un problema di onboarding, c'era un Il problema di un'azienda a microservizi che è passata a gestire più di 35.000 servizi, cosa si gestisce oggi, fra roba in produzione e roba in sviluppo, il problema di sapere chi è responsabile di quali servizi, il problema delle dipendenze, il problema di cercare le informazioni in un posto solo invece che andare su Confluence, Gira, GitHub, Big Bucket e le varie, l'email, "no ma nella mia email, no ma ce l'avevi te" eccetera eccetera, quindi avere un singolo posto dove andare a cercare e ti cerca tutto lui.Tutte queste problematiche sono problematiche che tutti hanno, tutti avevano e tutti continuano ad avere, soprattutto ora che le aziende stanno cominciando a crescere.Il grosso dell'azienda è più questa problematica è evidente, perché oggi parliamoci chiaro, siamo in un momento di crisi, ma proprio in momento di crisi bisogna ottimizzare.Quindi non è più il momento in cui va bene ma assumiamo altre 100 persone.Bisogna far sì che i developer siano più forti, più veloci, ma non veloci con la frusta perché è proprio questo il punto.Bisogna levare la complessità perché il problema di oggi è la complessità e la complessità sta nel fatto che non puoi chiedere a un junior o a un middle seniority developer di essere esperto su pipeline, cloud, AWS, Azure, Git, Terraform, Drevis, la tecnologia con cui devi sviluppare, JavaScript, back-end...ma come fai? Capito? Quindi alla fine tutti hanno questa realtà e quindi quando gli dici "ma noi a Spotify l'abbiamo risolto così, questo è come si usano" effettivamente succede quello che avete detto voi, cioè che ora noi non riusciamo più a contare quanta gente lo sta adottando e non c'è piccole aziende, parliamo di American Airlines, parliamo di Deutsch Bank, parliamo di aziende del settore privato, pubblico, farmaceutico, perché questo è un problema che ogni azienda tecnologica sta avendo, soprattutto a scale.Tra l'altro parlando con gli analisti è una cosa che è un segmento di mercato che sta fondamentalmente nascendo adesso, perché bisogna sempre andare più veloci, le aziende crescono in numero di developer e quindi ancora una volta a scale, tutti vanno verso i microservizi o i servizi e quindi dai monoliti si va ai vari servizi e quindi c'è la complessità di dover gestire tanti developer, tanti servizi, insomma diventa un casino.Ah, poi se proprio la volete di tutta c'è quello che Spotify fa una bandiera a ragione direi ed è un qualcosa che fa innamorare in questo senso, tra le discorsi di prima, Mauro, gli sviluppatori, cioè il fatto che vogliamo dare autonomia ai developer perché si pensa giustamente che dando autonomia ai developer si crea innovazione perché se ai developer gli dici no tu questo non lo puoi fare no questo questo lo devi fa così la security dice che tu non ti puoi muovere da questo articello ma non usare questa tecnologia ma non usare questa libreria ma non usa se è un ma non ma non ma non e l'innovazione non viene non è che l'innovazione viene perché fai una linea di codice e meno, no? Perché devi provare cose nuove.Se voi questa cosa la mettete at scale, quindi con centinaia di team, centinaia, migliaia di servizi, ma come fai a aver controllo di tutta sta roba qua? E quindi, quando ragioni di queste cose, la gente dice "porca miseria, ma lo sai che ho anche io questo problema, ma mi fai capire come è che viene fatto.E questa cosa funziona per Spotify e sta funzionando per Netflix, Zalando e altre che devo stare attento perché non le posso nemmeno nominare.Guarda, Francesco, hai evidenziato una cosa interessante che secondo me costituisce una parte del successo di Backstage, cioè il fatto che si presenta come uno strumento e non un prodotto.È detto così vuol dire tutto e non vuol dire niente, ma la cosa interessante è che io nella mia vecchia azienda ho lavorato su CRM e RP Custom, quindi sviluppavo degli avevamo come obiettivo sviluppare degli strumenti.Il vero problema è che quando tu ti siedi a tavolino e pensi un prodotto di questo tipo, il diavoletto sulla spalla ce l'hai e quel diavoletto sulla spalla ti dice "Ehi, ma perché non embeddi nel modo di pensare del tuo strumento una certa, un certo flow organizzativo, una certa procedura che funziona bene per te ma non sai se funziona per altri.La vera sfida di un prodotto come backstage è quello di rimanere procedure agnostic, no? E quindi rimanere strumento e non prodotto.Allora, il discorso è questo, assolutamente sì, e tra l'altro non solo prodotto ma anche tecnologia agnostic, cioè nel senso backstage.A CodeMotion farò una presentazione hands-on, cioè proprio apro i terminali e faccio roba.E si vede che alla fine si parla di developer experience codificando, cioè facendo codice, ma in realtà non sostituendosi al developer, ma creando una cosa che aiuta il developer a rimuovere le distrazioni.Il discorso è questo.Se voi pensate a cosa fanno la maggior parte dei developer, probabilmente spero, purtroppo non posso avere feedback da chi ci ascolta, ma poi magari me lo dite, è che si aprono 157 ticket per avere il GitHub repository, la pipeline, il database, poi lo devi chiedere a 74 team che sono tutti colli di bottiglia, poi devi avere l'autorizzazione del manager per avere l'acquisto sul cloud perché non sai se hai il budget, poi qualcuno ti telefona perché non l'hai fatto nel modo corretto.Non ti dico una problematica, tutti impazziscono a impostare l'authentication, l'authorization fra AWS, locale, on-premise.Sono settimane che vanno via, ma dove l'hai sviluppato? Hai cominciato a sviluppare? No, ancora hai fatto un tubo.Allora, tutta sta roba qua non è quello che piace a fare il developer.Il developer sa rabbia perché non sa usare Travis, perché non sa usare Terraform, sa rabbia perché non vuole imparare, ma alla fine tutta sta roba qua costa un sacco di tempo e è una frustrazione perché poi c'è il business che ti fa, l'hai deliberata la feature e parte la frusta, è arrivato, l'hai finita questa cosa, ti avevo detto di finire la settimana scorsa, quindi l'obiettivo non è sostituirsi a fare il prodotto software, ma è rimuovere il rumore, rendere quello che è complesso più semplice.Questo è il concetto della developer experience che viene portato in campo, quindi rimuovere il "fix yourself", rimuovere il fatto che se io non sono un devop non voglio rompermi le scatole, non un devop, se io non sono esperto in devop non mi voglio rompere le scatole a fare un qualcosa che non è il mio lavoro, ma mi voglio concentrare a fare front end development piuttosto che mobile o quel che è, e quindi rimuovo il rumore.Se invece poi ho tempo e mi voglio appassionare a mettere in piedi una pipeline o qualcosa del genere, non c'è nessun problema, lo puoi schippare con backstage eccetera eccetera.Ma se te vuoi puoi cliccare, pigiare un bottone e lui fa le cose per te.Prima di entrare poi nel merito di backstage e proviamo a guardarlo con attenzione, io ho una domanda invece per Andrea, perché lui è presissimo da backstage, no? E allora la mia domanda è, cosa è backstage per te, dopo l'esperienza e lo studio, l'analisi che ne hai fatto? Perché mi tiri in mezzo? Stiamo parlando con Francesco.Si tu, è un amico mio.No, no, io sono interessato, glielo voglio sapere.Allora, cos'è backstage per me? Per me backstage è un accentratore, un accentratore dove appunto ritrovi tutto ciò che ti può servire per fare il tuo lavoro, per tenere sotto controllo il tuo lavoro, per tenere sotto controllo e monitorare i tuoi servizi.E anche un acceleratore, anche perché per quello che prima raccontava Francesco riguardo al pezzettino dei templating, che clicchi un bottone "in base al templating devo partire con un nuovo microservizio", clicco là dove lo voglio mettere, boom, mi porta tutto, già c'è tutto lo scaffolding e la configurazione già pacchettata.Quindi diciamo ti aziona e ti accelera anche nel momento in cui devi partire con un nuovo servizio.Ti accelera appunto quello diciamo all'inizio in ottica di onboarding perché ti avvicina immediatamente subito al contesto dove tu devi realizzare la tua nuova feature grazie ai grafici, agli archi, riesci a vedere chi parla con cosa e quindi potenzialmente vuoi anche comprendere senza parlare con nessuno su chi sta dando impatti la tua funzionalità, se può dar fastidio a qualcuno perché viene utilizzato oppure no.La posso fare io una domanda? Certo.Perché, parliamoci chiaro, appunto, Immobiliare Lab con te Andrea, il team che tu rappresenti eccetera eccetera, sono parte della community backstage, fighissimo, siamo felicissimi, sono felicissimo anche perché, cavolo, italiani, aveva bisogno assolutamente, felicissimo.State contribuendo tra l'altro con plug in e con idee, bug fix eccetera eccetera, fantastico ancora una volta.Vi ho già invitato una community session, spero che accetterete eccetera, ma sennò sembra una marchetta qui.Qualche punto d'attenzione, difficoltà, perché poi il product manager vuol sapere anche cosa migliorare, oppure "lesson learned", cioè roba che ti senti dire, perché se no sembra davvero una marchetta questa cosa.Dimi, perché niente è perfetto, ovviamente tutto è perfettibile, quindi cos'è che secondo te va messo un po' in difficoltà? Perché io li so i punti deboli di backstage e e se volete che se ne parla, potrebbe essere una cosa interessante, che sono ovviamente punti di miglioramento, ma li voglio sentire da te.Secondo me, ovviamente, noi siamo degli adopter, diciamo, ci siamo avvicinati a questo strumento da diversi mesi e ora, diciamo, siamo a compimento nella fase in cui stiamo comprendendo come calarlo nel nostro ecosistema e poterlo utilizzarlo al meglio e poterci abbracciare al meglio.Ovviamente per far questo devi andare un po' di try and error, quindi comprendere finché ti puoi spingere a modellare o anche devi capire "no, guarda, sto modellando troppo, devo tornare un po' indietro perché altrimenti il fatto che io voglio risolvere la complessità non voglio che la complessità me la complichi anche ulteriormente".E quindi comprendere un po' questa fase qui di quale può essere il limite giusto.Non voglio andare troppo sul tecnico perché ancora non abbiamo parlato di tutte diverse cose, quindi potremo parlare anche di cose che ancora i nostri ascoltatori non sanno, se ho già parlato di sistemi.Esatto, al Code Emotion sicuramente ascolterò con molto piacere anche i nostri ascoltatori il tuo talk e poi ne potremo parlare tranquillamente, con una vera birra e davvero faccia a faccia.Quindi capire come modellarlo, perché ovviamente ogni azienda è diversa, ogni azienda c'è un'architettura diversa, fin quanto c'hai tutto lineare.Ok, sto su GitHub, c'ho AWS, perfetto.Comincia a mettere altri sistemi di cose che c'è self-hosted, cose che private cloud, altri strumenti self-hosted, eccetera eccetera, dove non tutti i plug-in più blasonati sono già delineati, tutto questo, c'è un po' di barriere che abbiamo dovuto superare, ecco perché prima giustamente citavi che abbiamo fatto diversi emergiri, questi contributi, perché ovviamente non essendo un ecosistema che ha un qualcosa di così lineare, ovviamente bisogna rendere le cose un po' più estendibili, ma per fortuna backstage è super estendibile, customizzabile all'occorrenza e quindi non abbiamo avuto grandissimi problemi.Però se tu mi chiedi che ne so, qualcosa che ci ha fatto soffrire maggiormente è stato quello di comprendere bene al meglio come modellare ogni singola parte della cosa.Potrebbe essere un'intenostro, potrebbe essere una documentazione che deve essere un po' più approfondita.La documentazione è super tecnica perché si vede che è scritta da sviluppatori, che cos'è questo, che cosa fa questo.Però forse manca qualcosa del tipo "noi ti consigliamo di fare così".Ci ho beccato? Si.Perfetto, meno male.Puoi aggiungerne altri, ma insomma, ripeto.Ma tanto tanto ci arriviamo, però per un attimo giusto perché in realtà è già da un po' che ne stiamo parlando, possiamo raccontare qualche feature, almeno quelle più importanti di backstage? Perché non possiamo definire un developer portal o sto sbagliando? Allora, mi hanno sfrantumato con tutti gli analisti per cercare di capire il posizionamento di mercato.Allora, in realtà si sta delineando adesso un po' qual è il posizionamento di mercato.Allora, si parla tendenzialmente di internal developer portal, da stare molto attenti rispetto agli internal developer platform, che sembra la stessa cosa in realtà, no, ma...Questa era una domanda che ti volevo fare, quindi ti chiedo di approfondire.Sì, sì, sì.Allora, praticamente funziona così.Allora, è un segmento di mercato che si sta affermando adesso proprio perché la complessità del development è un problema che sta affliggendo il business esattamente in questo periodo, come si sta discutendo ormai da un po', cioè si sta dicendo in questo podcast ormai da qualche minuto almeno.Quindi il discorso che cos'è? Si sta affermando questo concetto dell'interno developer porta, perché bisogna aiutare i developer ad essere più produttivi, perché bisogna semplificare un lavoro che è oggettivamente complesso, è molto fragmentato, perché pensate alla vostra e nostra esperienza tutti i giorni.In realtà, quando si fa una riga di codice, bisogna aprire sette tab di servizi diversi, altre terminali, eccetera, eccetera, e si perde la testa per star dietro a tutto.Invece quello che fa Backstage non è altro che essere un portale, perché alla fine è un portale React, con un back-end in non-JS, che in realtà tende a semplificare e a astrarre con degli engine che fanno il lavoro stupido al posto dei developer, perché i developer si devono concentrare sul lavoro intelligente, perché i developer sono intelligenti, e quindi il lavoro stupido lo facciamo fare alle macchine e al portale, e il lavoro intelligente lo lasciamo fare ai developer.Quindi, alla fine dei salmi, l'internet developer portal è un portale che ha proprio il ruolo di astrarre questa complessità e quindi io dico sempre che backstage e l'internet developer portal stanno, coordinano e stanno on top di tutti i servizi ma non sostituiscono nessuno dei servizi dell'azienda.Quello che dicevi te, Andrea, torna tantissimo perché è quello che fanno tutti.Cioè, tu non vai a cambiare i servizi della tua azienda, tu ci metti un developer portal sopra, che gli utenti usano per semplificare l'esperienza del developer.In realtà sotto rimane tutto uguale, con la differenza che c'è questo strato, questo layer, che fa il lavoro stupido per controllare il developer.E questo il valore aggiunto, ok? Questi si chiamano internal developer portal.L'internal developer platform è un concetto un pochino diverso e capisco che si faccia ancora tanta confusione, c'è anche qualcuno che ci marcia un pochino su sto concetto, perché l'internal developer platform in realtà è sì un internal developer portal, ma tende a sviluppare anche degli servizi specifici.E molto spesso, la quasi totalità dei player che ci sono sul mercato, tendono a sviluppare degli strumenti di delivery, deployment, quello legato al mondo DevOps.Ripeto, DevOps non è una professionalità, è più un concetto.E quindi il concetto che cos'è? Siccome DevOp è difficile, non tanti lo sanno fare, non tanti lo sanno fare per il business in maniera efficiente, quindi ci sono queste piattaforme che sì ti fanno interna developer portal, ma ti fanno anche molti servizi di provisioning, deployment, quindi tutto questo modo DevOp.Ma è diverso l'interna developer platform, che ripeto è servizi più portal dall'interna developer portal, perché l'internet developer portal, io dico sempre che senza servizi è completamente inutile, non serve assolutamente a niente.Senza l'internet developer portal tu puoi continuare a lavorare perché i servizi ce l'hai, è semplicemente tutto più complesso.Infatti siamo in questa situazione qua.Torna al concetto.Sì, dovendo fare un'analogia, mi verrebbe da dire che è un po' come il cruscotto della macchina, noi dobbiamo controllare la marcia, dobbiamo controllare il livello dell'olio, dobbiamo interagire con la modalità di guida.Ecco, ad altissimo livello abbiamo questa interfaccia, non grafica, ma proprio interfaccia di comunicazione che ci permette di parlare ai livelli sottostanti.Io in realtà l'ho guardato, non l'ho mai usato, quindi non posso portare un'esperienza di quel tipo.Però quanto in realtà A livello di lettura delle informazioni mi viene facile capire.Io developer devo accedere alle informazioni e ho cosa ne so sto banalizzando la mia pull request e il mio ticket a fianco.Non ho mai visto una cosa così, non so se è così sto ragionando in termini astratti.Il mio ticket su Gira è la mia pull request su GitHub Nel contempo magari correle, se è emergiata e deployata, è correlata alle informazioni di deploy prese da Gira stesso, con informazioni di release A livello invece di azione che fai attualmente Dov'è il trade off da Trigger un'azione da backstage o la trigger dallo strumento sottostante? Dov'è il limite? È una buona domanda.Allora, va visto caso per caso, perché non è che ci sono veri e proprio limiti, è un invoco.In realtà dipende un po' da...dipende un po' di cosa stiamo parlando.Ti faccio un esempio.Molte azioni sono in realtà supportate da azioni...azioni, faccio un esempio, se si usa Git, delle Git of Action, piuttosto che delle pipeline per...delle pipeline automatiche.Ti faccio un esempio molto più pratico.Una delle use case, perché mi chiedevi quali use case, poi non è che abbia risposto su sta cosa, quali use case in Carda Backstage? Il materiale che abbiamo è molto chiaro e ne nomina tre.io in genere ne cito quattro, ma sono il Create, Manage and Explore, quindi crea, gestisci e esplora.Ok? In realtà c'è un quarto che è la documentazione tecnica, technical documentation.Allora, il Create è praticamente un engine che è uno scaffolding system, quindi un engine, dove te gli dai un YAML file che rappresenta il tuo step by step e lui praticamente macina sto YAML file e ti crea un'interfaccia dove te, come utente, decidi cosa creare.Vuoi creare un'applicazione React, vuoi creare un back-end service in Java, vuoi creare un "che ti pare a te".Ti chiede alcuni campi, te riempi dei campi, che può essere il nome dei repository, quale utente o gruppo vuoi per le autorizzazioni, quello che ti viene richiesto.Tu clicchi il bottone "create" e dietro del back-end lui fa tutto quello che tu e i tuoi team faresti a mano, tipo creare il reposito di sub-git, piuttosto che il bit-bucket, dove farne la struttura giusta, metterci gli esempi, creare la base e la documentazione direttamente nel codice, creare l'i-pipeline, impostare le autorizzazioni e l'autorizzazione, deployare in un cluster, magari nei AWS, piuttosto che Azure, piuttosto che Google, piuttosto che quello che pare a te, impostare correttamente i diritti, vedere la visibilità, tutto questo automaticamente, pi pi pi pi, c'è il robottino dietro, in maniera standard, perché una volta che tu autorizzi il template non devi far altro, bene? Perché ti danno il bollino dell'azienda per il template, tu pici il tasto e cosa fai? In maniera self-service, no? Perché tu metti i dati e il robottino dietro fa tutto il lavoro.Quindi tu praticamente cosa fai? Invece di aprire Ticket e impazzire, te pici il il tasto, vai a prendere il caffè, magari vai a fare il swi-fi, torni e te c'hai tutta la tua farm in piedi.Quindi vai su una pagina web, sempre di backstage, e te lì, proprio in sing diversi tab, ti puoi vedere la pipeline, se è green o red, tutti i ticket aperti, tutti i branch, e questo non per sostituire git o quello che è, te ti vedi lì in un un unico cruscotto tutto, il deployment, dov'è, quant'è i test, come vanno, quant'è il costo perché tu hai delle varie cose, tutto questo ha un livello di cruscotto.Se tu, siccome questo non sostituisce i tool veri e propri come Gira eccetera eccetera, quando devi andare a un livello di azione tale per cui devi andare su Gira, devi andare su AWS, devi andare su Git, devi andare dove ti pare a te, te pici un tasto da backstage e ti apre la finestra e ti rimanda con il tuo utente, con le tue autenticazioni, al cruscotto giusto, alla funzionalità giusta di GitHub.Quindi, alla fine, Backstage è un cruscotto dove, ripeto, noi diciamo sempre che il developer usa tre cose per sviluppare, perché in Spotify funziona così, ma non solo in Spotify.Usa l'IDE, quindi dipende dalla tecnologia che usi, usa il repository, Github, quello che ti pare a te, Vbit, Bucket, quello che vuoi, e usa Backstage.Quindi, developi, debagli, committi, fai la pull request, vai su Backstage e fai tutto il resto.Guardi come va, guardi come la pipeline, e non devi essere esperto in nulla, perché è una human-friendly interface.Bene? Se c'è qualcosa che va male, vedi il log direttamente da lì, non devi sapere dove è deploiato, non devi sapere dove andare a cercare il log, non devi sapere la tecnologia, c'è un pop-up che ti dice "il tuo errore è questo, vattela a guardare".Ovviamente devi sapere se è spettro nel tuo lavoro, che è la tecnologia.Se sei un Qtester, vai nel tab del Qtester e lavori su quello.Potrei...perché ho toccato uno degli use case, che è il create, sto toccando il secondo, che è il manage, quindi gestire le cose da questo cruscotto, poi c'è l'explore, che è la parte di...che dicevamo prima, cercare le cose in un punto solo invece che in 100.000, Perché, ripeto, partiamo da un'altra cosa che è molto developer.Ai developer non piace fare la documentazione.Sfido chiunque, ascolta qui, a contrattarmi e dirmi "No, non è vero, a me mi garba da morire fare la documentazione".I developer non gli garba fare la documentazione.E questo è un problema, ma non un problema perché non gli garba, è un problema perché gli viene richiesta e quindi quello che fa backstage implementa quello che è la metafora del trattare la documentazione come un codice.Perché? perché il developer è più confidente con gli strumenti, quindi si riduce la distanza fra "vai su Confluence, a nessuno piace Confluence, allora vai su Gira, mamma mia, fai già andare di notte, allora cosa fai? Vai su Google Doc o Office 365, auguri, poi le cerca le cose".Quindi allora si mette il codice, la documentazione è vicino al repository, dove c'è il codice, si dà una bella interfaccia tramite backstage dove puoi scriverlo liberamente, un link fra il git e l'interfaccia in maniera che con un clic si salta dalla cosa all'altra.E ora la versione va via.Scusate? Aiuto aggiungendo che se hai l'attiva di utilizzare l'interfaccia su backstage te lo scrivi sui tuoi ide in markdown ed è l'output è identico.- E certo.Lo so che ho fatto un po' di confusione e mi scuso per questo, però il problema è cos'è.Fa un po' tante cose ed è bellino vederlo un po' in azione e poi ovviamente provarlo.Ripeto, a Code Motion farò proprio uno hands-on.Però il concetto è cos'è.Alla fine il concetto è che bisogna semplificare la vita che è un po' complicata oggi come Quindi avere un portale che non fa il tuo lavoro ma ti riduce le distrazioni perché fa quelle cose che tu sei costretto a fare al di là del tuo lavoro tecnico serve e aiuta.Allora mi viene subito una domanda al product manager che è in te.Vai.In un contesto veramente così vasto, enorme, da product manager come fai a deviare, evitare le feature creep, quando si parla di backstage in qualità di host, di funzionalità? Allora, la situazione è ancora più complessa perché un conto è fare product management di un prodotto per developer dove devi sapere di cosa un po' si parla, ok? Un conto è fare un product manager di un prodotto per developer nel mondo open source perché, tanto per dirvene una, che è un dato molto oggettivo, Backstage riceve più di 100 pull request alla settimana.bene? che è una quantità piuttosto strabiliante quindi ci sono almeno 100 contributi che può essere dal bug fix minimo alla grande feature e va sicuro ci sono tutte e due alla settimana, ok? ora, quanto può essere complicato gestire un prodotto che in realtà va come un razzo da solo in maniera completamente incontrollata, perché sì, posso dire alcune requeste, noi le possiamo rifiutare molte poche francamente, perché non hanno senso, ma la maggior parte hanno un senso enorme e quindi si assiste proprio a delle evoluzioni del prodotto completamente fuori controllo.Bene? Non è assolutamente raro che vengono creati delle feature che sono duplicate o in contraddizione l'una con l'altra.È assolutamente una cosa che fa parte del gioco.Però, l'architettura del prodotto è fatta, si chiama plug-in, e quindi tutto il backstage è un plug-in.Quindi in realtà backstage alla fine di salmi non è altro che una collezione di librerie che formano il foundation di backstage, quindi quello che serve al portale per funzionare.E poi praticamente ognuno, ogni azienda, come diceva Andrea, lui diceva "Sai, noi non è che abbiamo una cosa lineare, nessuno ce l'ha.E più grosso sei e meno ce l'hai".Faccio un esempio, alcune delle banche mondiali più grandi usano backstage e non posso fare nuovi.Immaginatevi i sistemi legacy che ci hanno quei stessi tutori qui, le aziende farmaceutiche, quelle più grandi, bene? Quindi loro hanno integrazione custom, per forza, e funziona questa cosa.Quindi i plug-in funzionano bene.Sul tuo punto, Mauro, quello che facciamo noi a livello di gruppo di maintainers e il product manager, prima di tutto, non è tanto ingabbiare quello che arriva, che va sicuro tutto e di tutto e questo è il bello dell'Open Source, io non lo critico affatto, anzi sono innamorato di questa cosa qua, perché è la community che guida il prodotto e l'integrazione.Quello che facciamo è dare delle direzioni strategiche, delle feature che pensiamo sia strategiche del prodotto.Faccio un esempio, quello che abbiamo fatto negli ultimi sei mesi è lavorare sulla maturità del prodotto, quindi abbiamo rilasciato una versione 1.0 eravamo in 0.qualcosa e c'era troppe beta e alfa al giro e c'erano troppi breaking change, quindi abbiamo creato una versione 1.0.Infatti abbiamo visto che dal punto di vista dell'adoption, quello che ha registrato Andrea negli ultimi sei mesi è grazie a questo lavoro della maturità.La seconda cosa che abbiamo fatto è creare un security plan, perché tutte le aziende più grosse ci dicono "è bello backstage" ma la sicurezza...io ho in mente, non farò il nome, un'azienda di scommesse in Gran Bretagna, grossa, la più grossa, che praticamente è venuta al fatto.Io ho sei sistemi di staging, cioè ho il mio sistema di development, sei sistemi di staging e solo dopo sei sistemi di staging vado in produzione.E io ogni sistema devo passare security e security perché sono sotto l'occhio di tutti.Assicurazioni, banche, quindi la sicurezza era fondamentale.Abbiamo fatto un penetration testing delle emissioni major, abbiamo fatto un threat model per il prodotto, quindi il prodotto è maturo da questo punto di vista.Quindi questo fa un product manager, gestisce quello che è un po' la direzione principale, perché non posso controllare come va un prodotto open source, è impossibile.7.000 membri nel forum, 7.000 membri, 100 pull request alla settimana.Però fammi capire questa cosa, e poi Andrea vedo che è qualcosa da chiedere anche tu, ma per cui, ripeto, io backstage non lo conosco affino, quindi ti sventolo la mia bandiera dell'ignoranza, però la mia domanda è, in questo caso cosa tieni tutti queste contribution, tutto questo apporto, buona parte va nell'ecosistema dei plugin, giusto? Sì, la maggior parte sì, perché in realtà i contributor sono molto più timidi quando si parla di core foundation.Ma è normale che sia, perché ovviamente un content andare a mettere il plugin è comunque una feature ma che tu puoi plugare appunto, non conto di toccare il cuore del sistema che ovviamente la gente anche naturalmente è un po' figli di vita, però quindi statisticamente c'è meno contributi sul core, ma questo vuol dire che di ingegneria hanno strutturato bene il prodotto, capisci che voglio dire? Perché se c'è meno bisogno...La complessità.Eh sì, no, sta la complessità.Direi che sta lì l'innovazione e scusa il termine le palle quadre dell'ingegnere.Perché questo non lo fa il product manager.Cioè il product manager lavora sullo why e lo what.L'ingegnere lavora sullo how e sullo when.Io ho i miei team, se io mi azzardo a parlare di come fare una feature e in che tempo la devono deliverare, io ho un team a New York, uno in Svezia e due in Svezia.Scendono dalla Svezia a Firenze, prendono l'aereo di New York e mi fanno una badilate in testa e hanno ragione.Quindi quando loro si azzardano a dire "no, ma questa feature io non la voglio fare perché non serve al mercato, io prendo l'aereo, vado a New York e piglio una bistecca alla Fiorentina e gliela pianto sulla testa, mai ben cotta, perché questo è il mio agio.Quindi il concetto è molto chiaro, il fatto che ci sia un'architettura con le strapalle non è in merito del product manager, è in merito degli ingegneri.Ti torna Mauro? Sì, sì, mi torno benissimo da...e mi è piaciuta l'evidenziazione che è fatta sul WEN, che è importantissima.Io mi azzardo a dire "ragazzi, io questa cosa deve essere deliberata per domani".Lo so che succede, ho lavorato in Figura, ho lavorato 20 anni in Italia, non so come funziona.Per ieri, ma non è deliberata per ieri.Mi azzardo per ieri, fanno una risata e durano una settimana e mezzo e mi fanno "sì, va Sì, fantastico.Andrea, volevi chiedere qualcosa? Sì, ero curioso di una cosa.Qual è, secondo Francesco, la killer feature di Backstage? Abbiamo parlato ovviamente di tre, anzi quattro, componenti core.C'è un marketplace con tantissimi plug-in, però se tu dovessi scegliere...ne hai citati quattro, poi ne possiamo citare altri, però se ne devi scegliere una.Secondo me già con quella già ha senso backstage.No, allora il software catalog, quindi il fatto di avere un repository dove praticamente tutte le tue software entity, API, software entity, resources, tipo una build table, piuttosto che un certificato, piuttosto che una virtual machine, te c'hai un database dove alla fine ci ficchi tutto e quello diventa il tuo warehouse di quello che è il technology asset management di un'azienda, quindi l'asset tecnologico del tuo IT department e del tuo core.e quindi praticamente in ogni istante tutti nell'organizzazione senza andare su Slack piuttosto che Team piuttosto che Whatsapp ti prego dimmi chi è che ha quel servizio lì perché mi sei piantato e io c'ho la security sul gozzo e non posso non mi funziona più il portale invece te vai su questa cosa e sai subito chi è l'owner di cosa se ci sono dei security incident in qualsiasi servizio, quali sono le dipendenze, cioè se io ammazzo questo servizio qui, cosa creo e a chi do noia e cosa faccio? Questa è una delle più richieste ma non è l'unica.Scusa Andrea, anch'io sono d'accordissimo e tra l'altro secondo me è veramente la parte game changer.Perché? Perché in realtà le funzionalità di cruscotto per il developer hanno un impatto nel flow del developer però diciamo che il developer sopravvive se deve saltare tra github e gira abbiamo fatto fino ad oggi e va bene.Io però ho lavorato per una grande multinazionale, come consulente per una grande multinazionale, parlo di sedi distribuite in tutto il mondo, con sedi di sviluppo in tutto il mondo, con per dirvi tre dipartimenti di IT security per il lancio di un progetto, tre dipartimenti di IT security, accessibility assessment, questo, questo e quest'altro è in realtà il nostro PO che poi tra l'altro era la cosa simpatica che era la prima volta che faceva il PO quindi in realtà il nostro lead e noi come piccolo team di engineering abbiamo dovuto gestire l'esplorazione di un organigramma inesistente quindi tu non sapevi chi era il gatekeeper e qual era il processo e diventa veramente un incubo.Sì, per dirvi, noi per avere i repository abbiamo aspettato 20 giorni.Abbiamo fatto i nostri POC nei repository personali con un certo impatto a livello di azienda, nel senso che le informazioni stanno uscendo fuori, un impatto pericoloso in quest'ottica.Quindi secondo me la vera killer feature è quella.Però nel contempo io ho provato a fare un esperimento mentale e probabilmente proverò a fare questo esperimento.Fino ad ora abbiamo parlato di aziende medie e grandi.Io faccio questo esercizio gli ascoltatori di Gitbar lo sanno io ho tipo 70 side project se penso a Mauro che deve gestire una serie di side project dove ha bisogno magari del suo template per lo scaffolding della versione base del suo SAS e ne ha 70 SAS che però hanno l'autenticazione quella roba deployano su quel certo provider.Secondo me backstage fitta bene da questo punto di vista anche con quel caso d'uso.Se si è moglia.Io ne conosco almeno un paio in Italia dove ci sono pochi sviluppatori, poca complessità.È ovvio che devi trovare un'azienda in Veneto, relativa ad un ospedale, è un public adopter, che si può dire.E questo è quello che mi affligge, quello su cui lavorerò probabilmente nei prossimi sei mesi.Backstage è molto potente, è complesso a mettere in piedi.Andrea, secondo me, sta educato, non l'ha detto, ma è complesso a mettere in piedi, nel senso che richiede un effort di sviluppo, cioè non è l'applicazione plug and play, con il wizard, installa sì sì yes yes, ok, buh, e parte.E dietro c'è configurazione, semplicemente vuoi, ma devi capire l'architettura, capire come plugare le cose, scegliere i tuoi plugin, configurarli, testarli, estenderli.Andrea lo diceva, estenderlo per i propri casi d'uso, è complesso ed è quello su cui i pochi competitor che riescano a stargli dietro, uno, e in realtà s'aggrappano, no? Tutti stanno dicendo "ah, con backstage complesso, però te c'hai bisogno di un team per tirarlo su".Questo è una cosa, per esempio, che un product manager come me è interessato a superare.Quindi, sul tuo punto, Mauro, questa cosa qui è considerata un po' una barriera per le piccole realtà o per le piccole cose, perché in realtà ti devi cominciare a sbattere per imparare un pochino l'architettura, e quindi alla fine cosa succede? Che chi ha dieci sviluppatori preferisce fare una call in Zoom o in Meet o in Team o quello che usa e dire "Senti ragazzi, c'è un gran casino, allora chi è che usa queste API, chi è che fa questo servizio? Boni, organizziamoci tutti, decidi dove si fa così".Quando hai più di 50 persone è un po' un casino fare una call dove si dice "Fermi tutti, adesso facciamo così".e quindi immagina che quando hai decine di migliaia diventa un casino pazzesco, proprio completamente fuori controllo.Quindi è ovvio che vediamo molta fraccia.A quel punto non vedo nemmeno quale sia il problema avere un team che ti tiri su backstage, dentro l'azienda che ti risolve questo problema.Tu dici quelli grandi o quelli piccoli? Ma da 50 è ancora di più.No, ma infatti lo sai cosa si assiste? Lo sai cosa si assiste? Che quelle più piccole in realtà sono molto molto attratti dai software as a service cioè noi abbiamo un partner che è Rodi che prende backstage e lo offre come software as a service funziona? Perfetto! Ovvio c'è il problema che poi hanno tutti quelli che offrano i SAS anche qualche competitor, cioè che non lo puoi customizzare come si potrebbe perché non è pensabile che in un SaaS lo customizzi come vuoi.Quindi è lì il limite.Però infatti è vero che si aggrappano sul fatto "eh ma Backstage è complesso", però da un altro punto di vista se gli chiedi quella feature in più, "eh no, era in SaaS, non si può".Capito? E quindi per loro diventa la complessità, diventa invece la flessibilità che Backstage ovviamente ha naturalmente.però sono d'accordo che come product manager bisogna lavorare sul renderlo più semplice e abbiamo e ciò diverse idee da questo punto di vista.Però c'è pure da dire che non è che l'avete scritto in C++, l'avete scritto con dei linguaggi che sono molto vicini al web e gli utilizzatori sono molto vicini al web quindi diciamo c'è un derimiato feeling anche potenziale metterci le mani a comprenderlo.Si è vero ma per esempio...Non JS come back-end, reazioni di front-end.Però ti dico per esempio in molte aziende soprattutto strutturate, soprattutto banche, dove vengono da sviluppatori back-end, java eccetera eccetera, ci contattano dicendo "eh ma io con javascript e typescript non sono bravo" e ti vengono a dire "eh ho capito figlio mio ma impara oppure...cavoli, ora ragazzi c'è tanti bravi su questa tecnologia qua, però si dica "ma io sono devop e non sono bravo a questa cosa qua" e ho capito.Parlo solo Spring.Sì, capito, cioè ci sono e fa parte un po' del job, però dovremmo fare un miglior lavoro da questo punto di vista.Secondo me in realtà anche a livello di contribution, aprire a quel mondo potrebbe portare veramente un ulteriore boost, anche perché in realtà Francesco, quello che succede, che abbiamo detto prima, degli spike delle sessioni di discovery, spesso nel processo del software ingegner avvengono in un contesto individuale.Sfido chiunque a non aver preso una sera per provare a installarsi kubernetes sulla propria macchina e provare a buttarci dentro un minicube.Ok, fai l'esperienza, poi se lavori in una società che non utilizza kubernetes, dove insomma questo tipo di conoscenze non ci sono, sei portatore sano di quell'informazione perché hai fatto l'esperienza? Quindi in realtà non è solo aprire a Mauro che ha 70 side project e deve monitorarli, ma è proprio anche creare una cassa di risonanza che parla alle organization medio-grandi, quindi è veramente interessante quel lavoro che stai dicendo che vuoi fare perché...Ma ora che pensa, guarda, sai cosa mi fai pensare Mauro? Quello che dicevi ora mi fa riagganciare al devrel che si diceva all'inizio.Tutta questa voglia di sperimentare che è normale in un developer, parliamoci chiaro perché se un developer non si diverte da usare la tecnologia, ma chi è? Qualunque developer è spinto da questa cosa qua.Poi non si abbia tempo e voglia un altro discorso, ma la curiosità c'è.Se tu questa cosa la unisci con avere delle professionalità, che sono i DevRel, che esattamente cavalcano questa eccitazione e questa voglia nel far provare delle tecnologie e li aiuti in questo percorso, perché questo è il concetto, no? Dandogli dei buoni tutorial, delle occasioni di hacking insieme, facendogli venire voglia di fare questa cosa qua.E poi magari queste POC e queste sperimentazioni hanno successo e questi developer, il riporto dell'azienda dicendo "sto vedendo cosa ho fatto la settimana scorsa perché il corti mi ha aiutato oppure ho lavorato con qualcuno che mi ha fatto vedere, ho fatto questo giochino, guarda bellino perché si potrebbe usare per questo e quest'altro.Da un punto di vista di marketing al developer, ha una potenza clamorosa.Cioè, ripeto, noi siamo abituati a pensare il marketing più classico, qualcosa che va dal business e scende sull'IT.Voglio quel software, tu vai, installalo perché io te lo dico.Ma il marketing dal...Si, anche con SAP in Ateneo.Non si dovrebbe dire ma il concetto è questo.Oppure questi mastodonti che poi saranno i meccanici.Guarda, ci sto facendo un'integrazione con SAP.Se vogliamo parlare male di SAP possiamo farlo per settimane.Il marketing al developer ha principi completamente diversi, ma è più bottom up rispetto al business, capito? Quindi si gioca insieme, è divertente, si usa, non lo paghi niente, giocaci, fallo, facci le fiossi, spaccalo, miglioralo eccetera, perché se tu porti un qualcosa all'interno della tua azienda dicendo "ma questo è figata, è questo", se il tuo IT department si eccita su sta roba qui, eh ragazzi, sei un pezzo avanti.Vedrò, vedissimo.E questa è la diversità tra un target di developer e un target di business, ok? Senti Fra, una preghiera.Ci puoi spoilerare qualcosa che potrebbe vedere la luce tra qualche mese? Prima parlavi che sicuramente avresti dato un po' di numeri al BackstageCon.L'avevo già detto.Esatto.Mi chiedevo se oltre a questo avresti annunciato qualcosa, oppure non lo farete ancora ma lo vuoi dire solo a Gitbar? No, no, c'è, c'è.Se si può, non sentirti all'angolo.No, non è povera, se non si può non lo faccio, non c'è problema, perché poi mi crocifiggano.C'è un ufficio, il più bello ufficio che abbiamo mai visto, sulla punta di Manhattan a New York, sul grattacielo più alto.Sì, praticamente il concetto è quello.Ed è su una delle Wall Street Center.Accanto se ti abbassi vedi il buco delle due torri gemelle, abbastanza impressionante.Spotify è gli ultimi 10-20 piani, è una roba clamorosa, quindi sei sull'ultimo grattacielo.Ecco mi crocifiggano tipo fantozzi la sub.Comunque, spoiler.No, si può fare uno spoiler.Prima di tutto, non so se lo sapete, ma il CubeCon a Detroit sarà il 24 ottobre, in realtà il 25 se non sbaglio.Tra il 25 e il venerdì, non me lo ricordo, perché il 24, che è il lunedì insomma, tanto per capirsi, ci sono le conference in person dei vari prodotti, progetti CNCF, quindi c'è la Kubernetes e per la prima volta ci sarà anche il BackstageCon.Siamo già praticamente sold out, non riesco ad avere i numeri ma siamo molto molto avanti e lì ci saranno diversi annunci.Tra l'altro ci saranno diversi annunci relativi al fatto che ci sono tutta una serie di plugin, abbiamo parlato di questi plugin che sono il modo di aggiungere feature, che sono plugin di Spotify, cioè voi tenete presente, questo Andrea ti interessa anche a te per immobiliario ovviamente, praticamente la versione di Spotify di backstage, visto che abbiamo parlato di plugin, è un backstage open source con sviluppato nel tempo 160 plugin aggiuntivi.Bene? Ok? Perché in Spotify c'è praticamente...sapete quanto è grosso il team che sviluppa backstage per l'interno, cioè che mantiene il team interno? No.50 persone? 5.50? Che cazzo! Per gli ascoltatori stavo aprendo la mano perché abbiamo la telecamera.Ci sono cinque persone che per reggere 4.000 sviluppatori è piuttosto poco, no? Perché in realtà tutto lo sviluppo dei 160 plugin viene fatto dai vari team che sono responsabili dello sviluppo.C'è un in-source in puro, ok, da questo punto di vista.Quindi alcuni di questi plugin sono molto figli.Pensate al fatto che backstage abbiamo detto che semplifica la vita degli sviluppatori.pensate se invece di semplificare soltanto aiutasse gli sviluppatori cioè ti battesse alla spalla e ti dicesse senti un po tesoro ma invece di fare la cosa così perché non la fai così guarda che risparmi guarda che è meglio guarda che è più sicuro vogliamo anche la frase motivazionale della direzione di dacts...no no no no no no no no...andiamo andiamo andiamo con calma...diciamo abbiamo detto troppo...andiamo con calma però il concetto è questo ripeto ancora una volta ora noi abbiamo parlato fino a ora a a semplificare la vita degli sviluppatori, perché è vero, perché è vero.Però noi stiamo già pensando a dopo, perché lì ci siamo già arrivati.Ora, quello che si sta facendo è che tante aziende stanno capendo l'importanza di questa cosa qui e stanno adottando questi sistemi per rendere più, noi diciamo felici gli sviluppatori, ma in realtà sarebbe meglio dire per aiutarli e semplificare la loro vita.ma c'è dei passi ulteriori da fare.Cioè, ripeto...Il backstage open source con quello, diciamo, dentro Spotify, sono lo stesso versione oltre ai plugin e inner source aggiuntivi? Spotify incarna...questo non è solo con backstage.Noi in Spotify non abbiamo staging environment.È continuous delivery, ma di quella vera.cioè le pull request sono sul master branch che tramite la pipeline va direttamente in produzione.Quindi il discorso è questo, i team bombardano di pull request, c'è un buon sistema di review, la gente è brava, al momento che viene emergato sul master parte la pipeline e sei in produzione Quindi quello che è in realtà la versione che c'è internamente di backstage è quella open source ultima, ultima, più tutto sto ambaradan di plugin che ne fanno un look e un feel diverso, diverse specializzazioni, diverse feature, eccetera, eccetera.quindi è...sì, è così.C'è un mirror, no? C'è un mirror dalla open source al core più i 160 plug-in, parte la pull request sul master branch di questo repository, boom, e va direttamente in produzione.In produzione.Domanda, invece.Abbiamo messo gli sviluppatori al centro, come è giusto che sia da software engineer, ma l'utente product owner/product manager cosa ci fa dentro backstage? se ci fa qualcosa o se sta in un angolo con la bottiglia? questa è una discussione...allora alcuni dei...allora ci sono dei product manager e ci sono quelli che sono gli engineering manager soprattutto gli engineering manager che sono molto attivi su backstage.I product manager un pelino meno, ma non tutti, perché tenete presente in Spotify di product manager veramente tanti, perché è un asset molto importante per Spotify, cioè i team sono relativamente piccoli, relativamente, e c'è molto spesso un product manager coinvolto e un engineering manager, quindi sono tanti anche i product manager.I product manager a seconda dei vari department, alcuni non lo usano proprio, altri ci lavorano perché tra l'altro è stato costruito delle view e delle astrazioni dei panel sopra tutto l'ecosistema di dati, perché il fatto che cos'è e questo lo vedo in tanti adopter, quando si comincia ad avere un singolo posto, Andrea dimmi cosa ne pensi per quello che avete visto da voi, ma è un esempio, perché quando si comincia ad avere un singolo, un unico portale dove tutti i developer lavorano e agiscano, c'è una enorme tentazione di farlo diventare un po', non voglio dire portare l'azienda, ma portare l'IT, perché "ah ma tanto lì ci lavorano tutti", quindi le comunicazioni, le view, le analytics, le aggregazioni, i jobs to be done, tendono un po' a dire "no ma mettiamolo lì, perché lì ci sono tutti e quindi è naturale che sia lì il posto".È vero, ma stiamo attentando a snaturare un po' lo strumento, perché questo è un po' il dischio, non so Andrea - Guarda, mi ci sento appieno perché una delle prime cose che abbiamo fatto dopo che l'abbiamo fatto funzionare collegando i nostri sistemi è stato dandogli il look e feel di Mobile Labs.La seconda cosa, ah ma allora qua ci possiamo mettere anche il link al nostro blog interno, anche lì ci possiamo mettere anche il link al nostro handbook, che ovviamente se la gente sta lì, funge da aggregatore anche per altre cose internamente, che non hanno per forza a che fare con lo sviluppo e l'avanzamento.Ecco questa cosa questa cosa qui è una cosa che succede a tutti gli adopter incluso Spotify, c'è da tenere un po' sotto controllo perché altrimenti diventa un buglione di un portale e per esempio ci sono delle profili un po' più business diciamo così che su certi tipi di front-end possono essere, se ne sono stati creati anche all'interno di Spotify, ma non solo, delle view su quello che è lo stato più software.Bisogna stare attenti perché, per esempio, backstage non ha feature particolari per facilitare questi tipi, ancora, per facilitare questi tipi di professionalità.Francamente, anche da un punto di vista di product management, ci si sta pensando perché alla fine tutti vogliono farlo.Perché, ti ripeto, è una cosa molto naturale.Integrazione con tabloid e Qlik di data analyst.Quello c'è già, è facile, lo fanno in tanti per creare i dashboard senza però avere tutta quella facilità.Tabloid per esempio, cioè la dashboard è proprio una feature base per Tableau, Curic, con tutto quello che...Ecco, non vorremmo riproporre questa feature in backstage, non ha nessun senso, backstage non può diventare tutto, no? Non può diventare un developer por...Scusa, un portal, come LifeRay, e cioè non ha assolutamente senso questa cosa.Quindi va...Ah, per esempio, in uno degli hack day, quello che ho fatto è integrare backstage con WordPress, per esempio, Perché paradossalmente ha più senso, no? Lascia perdere WordPress, può piacere o no, ma paradossalmente ha più senso questo tipo di evoluzione se uno vuole parlare di portalizzazione o l'iFray o quello che è, invece che caricare backstage di una funzione che è un po' assurdo fargliela fare, ecco, da questo punto di vista.però evidenzio una cosa perché in realtà abbiamo scalfito un attimino, ci siamo affacciati un attimino nel mondo del management e avere per quanto piccola e contenuta un'area in un portale che aggrega le informazioni dove puoi percepire l'impatto del prodotto che stai facendo, che ne so le per dire immagino il team di backstage, vedere i fork, vedere quel tipo di attività se si tratta di un progetto open source oppure l'impatto che hai sugli utenti finali magari aggregato, magari astratto, connette lo sviluppatore al prodotto finale e pompa l'ownership.Non so se sono riuscito a passare l'idea.Che mi vuoi dire che...fammi capire un attimo...che mi vuoi dire che se fossi il team di sviluppo di backstage vorresti avere dei dati sull'uso di backstage tra vari adopter, developer e fischi vari? No, vorrei vedere per esempio, sarei inondato, però che ne so, informazioni che possono essere del tutto inutili ma che danno un impatto, parlo di un NPM modules, il numero delle installazioni del modulo, il grafico delle installazioni, e tu quando stai lavorando tutti i giorni, hai sotto occhio l'impatto, se parliamo di prodotti open source, ma se parliamo di prodotti in termini più larghi, questa cosa si presta ancora meglio, però vedi l'impatto della tua azione quotidiana, che è una cosa che spesso da sviluppatore perdiamo, cioè perdiamo il polso di quello che stiamo facendo perché è troppo vicino alla tecnologia.Io una cosa che lavorando da consulente adesso attraverso NIRFAM in una grande multinazionale perdo, nel senso mi allontano dall'impatto che questa grande azienda sta facendo col prodotto software che sto aiutando a sviluppare.Sì sì, quello potrebbe essere un plug-in.No, io pensavo che ti riferissi a capire un un po' l'utilizzo di backstage tra i vari adopter, perché qui si entra in una cosa ferocessima.No, sarei un pazzo suicida.No, mica te in realtà, a me mi carebbero un sacco, ma non per sapere cosa fa la gente, ma per capire dove non si usa bene il prodotto o dove proprio c'è da intervenire sul prodotto.No, no, non è per niente follia.Ovviamente in questo mondo dove bisogna stare attenti alla privacy, che è una cosa sacrosanta, è semplicemente non fattibile, soprattutto in un mondo open source.Perché figurati se io dichiaro a Andrea "Andrea, ti scarico le statistiche di uso nella tua azienda, nel tuo core business".Figurati, te lo immagini.Ma non perché Andrea, anzi, Andrea forse dovrebbe anche.È semplicemente meglio di farmaciere, farmaceutico, banche, public sector per carità.Cioè non è fattibile, però quello discorso che dici te che rientra nel concetto della telemetry, quindi sapere chi fa cosa come sui vari prodotti, a piace tantissimo.Andrea ti piacerebbe sapere come lo utilizzano i tuoi utenti, il portale.Certo che sì, probabilmente piacerebbe anche sapere quante volte viene utilizzata la libreria interna, gli innessori ai propri registri.Che è simile a quello che dice Mauro, è una delle cose che ci viene richiesta e anche qui il problema che cos'è, è che siamo in tutta una discussione su quale delle feature fare prima, perché ovviamente come maintainer non è che abbiamo 157 milioni di sviluppatori.Abbiamo già diverse aziende che ci stanno contattando per dire "io vorrei aiutare e contribuire sulla telemetry, però vorrei che voi guidaste il carro, però cosa si fa alla telemetry o altre cose?" E qui viene il product manager, perché dovrebbe dire cosa è che viene prima, proprio con un discorso di incremento del prodotto, eccetera eccetera e qui viene la responsabilità che dicevate all'inizio ma perché la responsabilità è adrenalina.Prima parlavamo diciamo del backstage con degli eventi questo grande evento pianificato a Detroit, Michigan, soprattutto ero curioso del perché a Detroit e non a Berlino, Giappone, cioè perché Detroit.C'è un perché molto chiaro.Esatto.E gli after party con la No, ma lui tra un tempo pauroso, ha detto "sarà un freddo birbone, una roba da morire".Esatto, ho pensato la stessa cosa.E poi mi piaceva anche chiederti, riguardo a...sicuramente può far piacere a chiunque si voglia avvicinare, parlare anche di tutti i meetup che organizzate, dalle community session, oppure alle SIG, dei catalog, se ci volevi raccontare un po' il perché e quali scope hanno differenti.Allora, perché Detroit? È molto semplice, perché backstage nonostante che si dica, cioè nonostante il fatto che è creato da Spotify e Spotify ha un team grosso che lo sostiene e lo migliora, ma in realtà non è più una proprietà Spotify, quindi noi non possiamo fare niente con backstage se domani decidessimo, tra virgolette, di venderlo o di pal.Non si può, perché backstage è stato donato alla CNCF, che è una foundation di open source e il prodotto è di CNCF, non è di Spotify.Quindi questo ha una serie di obblighi e onestamente anche garanzie per gli adopter, perché non potrà diventare quello che non è, a meno di forcarlo ovviamente, ma qui si entra in un altro scenario e quindi fa parte del, come Kubernetes, fa parte del cappello.Tra l'altro sono particolarmente orgoglioso di vedere i progressi perché è il quarto progetto per la classifica di autori e contributori al progetto della CNCF, cioè proprio delle statistiche in questo senso.E quindi, siccome fa parte della CNCF, tendenzialmente la CNCF offre tutta una serie di facility per cercare il posto dove fare le conference, dare l'organizzazione, i biglietti e tutte queste cose.Ovviamente sono un costo e un impatto rilevante in generale.Quindi il CubeCon è organizzato da CNCF e si tiene a Detroit e tendenzialmente la CNCF il giorno prima, nelle stesse venue, fa queste conference dedicate.E per la prima volta ci sarà questa di backstage.Quindi in realtà, perché Detroit? Perché in realtà si attacca a CNCF, quindi molto semplicemente.E quindi andremo a pipare di freddo laggiù, perché ci mettono un freddo birbone.Però sarà una venue bellissima, tra l'altro abbiamo già esteso l'audience, perché eravamo andati sold out dopo nemmeno un mese della pubblicazione dei biglietti.Non è uno spazio enorme, ma ripeto, siamo già oltre le aspettative, eccetera, eccetera.Tutti mi chiedono "l'anno prossimo si fa in Europa?" Boh, non lo so, vediamo, anche perché non lo decido io, perché è tutto un settore di marketing.Io le conference di prodotti open source, ci ho sguazzato e vissuto su altri prodotti, sono fantastiche, perché l'hype è altissimo e poi quando ti cominci a vedere un po' con gli stessi appassionati per un po' di tempo, si creano anche dei rapporti, eccetera, eccetera, è bellissimo, quindi spero che ce ne siano altri presto anche.Mi mancava per le discussioni di Covid, eccetera, eccetera.Sono molto contento e non vedo l'ora.Sulla seconda domanda, meet up e roba varia, allora, noi abbiamo le community session, fanno paura perché sono frequentate da centinaia di persone ogni volta.Ne abbiamo due, una per i contributor e l'altra per gli adopter.Quelle degli adopter sono ben frequentate, specialmente da chi vuole imparare da altre esigenze.Per questo, Andrea, te lo dicevo a te ma anche a altri, venite a condividere la vostra esperienza.Onestamente, perché ripeto, immaginati te alle prime POC, probabilmente l'hai anche fatto, quanto farebbe comodo sentire da Andrea e da immobiliare lab della situazione, "guardate, io ho avuto problemi in questo, la mia dimensione è quest'altro, i miei use case sono questi, ho avuto difficoltà in questo, questo l'ho superato così, questo l'ho superato così, se qualcuno si ritrova in te, te gli dai un aiuto clamoroso".Che ridurrebbe il commute dei santi dal paradiso con le bestemme.In Italia va di moda, all'estero lo sai, la bestemmia va un po' più… non c'è tanto.Poi penso a Fiorentino, non c'è Veneti tra di noi.Invece il discorso del SIG, questo è interessante, perché il SIG per ora noi abbiamo un tipo di SIG, il SIG vuol dire per chi non lo sapesse Special Interest Group.Alla fine sono dei meeting ricorrenti che facciamo ogni due settimane su tematiche dedicate, ok? Noi siamo partiti con il Catalog SIG, cioè il special interest group focalizzato sulla feature del catalog, che è una delle feature di backstage, ma, spoiler, negli anni prossimi, cioè negli anni prossimi, nel prossimo anno, nei mesi prossimi, ne faremo altri.Il motivo è molto semplice.non ne facciamo più a coordinare le contribution e la gente ci contatta i contributor delle aziende e ci contattano e ci dicono ragazzi io vorrei contribuire su questa cosa ma prima di fare la pull request vorrei capire se ha senso rispetto alla direzione del prodotto e ancora una volta mi guardano un po' a me e a me, mantenere un po' come iniziavamo un po' questa call come per dire "ma te product manager posso fare sta contributo e io ti dico porca miseria, io ti ringrazio tutta la vita se fai il tuo contributo.Poi se fai un contributo tecnicamente non accettabile, lo diceranno i maintainer o che proprio offende Spotify o offende il prodotto, si possono dire "no, non lo faccio, se no, beh, venga e poi dire grazie, vi voglio bene da questo punto di vista".I SIG nascono proprio per coordinare i contributi, che non ce la facciamo più a lasciare in un flow libero, perché sono tanti e strutturati e quindi ogni, per esempio il CatalogSig lo gestisco io insieme a uno dei tecnici, perché quando vengono disposizioni troppo tecnici mi perdo, io faccio il note taker, io riempio il documentino e ascolto quelle che sono le esigenze delle varie persone.Il CatalogSig sta cominciando a dare i suoi frutti perché si stanno creando delle idee su come disegnare il catalog del futuro, quali fissi raggiungere, come si può dividere il lavoro e quindi il SIG serve per fare contribution at scale, escalare la community.Questo è un po' il concetto.Chiaro, e potrebbe essere anche una specie di trampolino di lancio a portare a bordo altri contribution più strutturati e non spot, cioè avvicinare maggiormente le persone andare in profondità nel core del catalogue e poter contribuire più agilmente.Io ho fatto la ricerca e l'ho già detto quindi non è un segreto, il prossimo, quello che viene più chiesto a gran voce è lo Scaffoldersign, quindi il motore per creare le applicazioni.A ruota c'è c'è il Technical Documentation, TechDoc, e poi forse altri.L'idea del SIG non è nuova, l'abbiamo spuderatamente copiata, ci siamo visti con i ragazzi di Kubernetes, della CNCF, e gli si è chiesto "Sentite un po', ma voi come fate a gestire tutte le contribution?" "Ma si impazzisce!" "Però felicemente, perché sono tante!" "E come fate?" "Eh, grazie ai SIG." Alla fine il sistema di contribution di Kubernetes è tutto basato su SIG, tutto SIG.E noi stiamo un po' seguendo l'onda perché il forum di backstage è su Discord.Io lo sto guardando, abbiamo celebrato e abbiamo festeggiato i 7.000 membri mi sembra tre settimane fa, siamo già a 7.200 e sono passati tre settimane.va forte, cresce.Poi non è che tutti sono attivi sempre, ma 7.200 sono tanti.Ma anche l'organizzazione che avete dato dentro al Discord, con la possibilità di creare dei post tematici di richieste con i canali tematici, anche lì secondo me è stato super vincente.Come ho visto evolversi il prodotto, ho visto evolversi anche il sistema di comunicazione con le persone per il supporto.Salsa è successo la settimana scorsa.Io tutti i giorni tra Linkedin e la papà Maria ricevo contatti da entusiasti o persone che vogliono contribuire.La settimana scorsa è successo, dal Brasile, uno mi fa "Senti, io ho parlato con la comunità brasiliana" perché io ho diversi contatti, so che è molto, soprattutto nelle banche, fa "Noi abbiamo bisogno di un canale brasiliano".Se te vai sul Discord c'è un canale solo e c'è la gente così.E là dentro si sentono più friendly a parlare portoghese? Si sa che i portoghesi non sono proprio il massimo con l'inglese, io l'ho fatto a volte, sembriamo i francesi.E invece gli italiani.Però effettivamente è vero, si può fare un un canale brasiliano, ma per esempio sull'organizzazione tematica sono bravi i ragazzi di Martina, ancora una volta ingegneri.Io non ho nemmeno i diritti per fare queste cose lì, sì sono lì ma io non posso, mi tagliano le braccine.Io credo che abbiamo fatto quasi tutte le domande che volevamo fare.Andrea, hai qualcosa aggiungere.Ma io diciamo massacrato abbastanza Francesco, sono super soddisfatto.No grazie invece e poi ripeto, si fa il Code Motion, si fa l'estensione.Rentierissimo.E tra l'altro abbiamo una birra in sospeso Francesco, sappilo.Volentieri.Spero di riprendermi ad un freddore perché sono un po' così.No problem, no problem.Io ragazzi sono un po' in ritardo perché mi è cascata la rete e sono usando il telefonino come connessione quindi ho un certo lag.Andiamo con il momento tipico e topico di Gitbar, il momento in cui i nostri host e i nostri guest condividono con noi un qualcosa che ha un qualche valore di essere condiviso all'interno della nostra community.E allora facciamo partire la nostra bellissima sigletta.E conduco nel paese dei balocchi.Ah, il paese dei balocchi.Francesco, cosa vuoi condividere alla community di Gitbar? Allora, visto che sono di Firenze e Collodi è qui vicino, anzi si dice che il libro di Pinocchio sia stato scritto a Sesto Fiorentino, che è proprio qui vicino a dove abito io, quindi nemmeno a Collodi, ovvero quelli di Collodi mi uccideranno.Una cosa che vorrei condividere con voi, siccome abbiamo parlato di product management, vorrei condividere un libro che si chiama "Good Strategy, Bad Strategy" di Richard Rumelt.È un libro che è uno dei preferiti del fondatore di Spotify, che si chiama Daniel Ek.È un personaggio, veramente un personaggio.Ah, tra l'altro su Netflix uscirà la serie sulla sua abilità, credo in qualche settimana.e lui è appassionato di questo libro, ovviamente per quanto riguarda le strategie di prodotto, e francamente questo libro ha generato diversi interessi all'interno di Spotify perché tutte le strategie di prodotto in realtà sono basate sui principi che questo libro descrive.Quindi non sto condividendo nessun segreto aziendale, ma in realtà se volete fare strategie di prodotto e anche software, io lo uso frequentemente.Questo è assolutamente un libro interessante da leggere e da approfondire.Appena aggiunto nel cambio di tema.Io sono molto curioso di sentire anche i vostri.Vai Andre! Allora io invece vorrei rimanere in tema backstage e quindi vorrei consigliare un plugin.Un plugin realizzato guarda caso da chi? Dai mobile all'abs! Perché? Applausi! Perché avevamo un problema che attualmente noi volevamo collegarci l'utenza per entrare nel sistema di backstage con il nostro sistema di autenticazione interna che è l'adapt.Non esisteva ancora un plugin per fare tutto questo, c'erano centinaia di plugin per fare il single sign on su qualsiasi tipo di provider esistente al mondo ma mancava quello per l'adapt e quindi lo abbiamo realizzato e quindi qualora qualcun altro voglia avvicinarsi a diventare un nuovo adopter di backstage e anche esso ha questo caso d'uso c'è già un plugin pronto da utilizzare.Grazie grazie grazie grazie grazie grazie.Che troverete ovviamente nelle note dell'episodio.dell'episodio assolutamente sì.Anch'io ho un balocco che non è un libro, non è una libreria, non è un video, ma per la prima volta è una pastiglietta magica.Non sto suggerendo a voi di utilizzare delle micro dosi di qualche droga strana per aumentare la produttività, ma in realtà io avevo un problema.Voi sapete che io sono full remote da un po', e se fate remote sapete quanto è pericoloso il frigo e conoscete la dinamica che io chiamo l'esigenza del sapore, cioè il bisogno di avere un qualche sapore costantemente in bocca.Io tendo a bere coca cola, succhi di frutta...mi sentite ragazzi? Ah, sì.Dicevo, non so se conoscete il problema di avere sempre un...bere qualcosa, mangiare qualcosa per tenere un sapore in bocca.Ecco, io avevo questo problema e nulla, l'ho risolto con queste pastigliette solubili che danno un sapore all'acqua e che non hanno zucchero.Una figata pazzesca, si chiamano Water Drop e le trovate nelle note dell'episodio.Io vorrò provare queste cose perché io ho questo problema, nel senso bevo acqua e basta perché se no divento un bidone e questa cosa mi piacerebbe tantissimo provare.Allora, buone pastigliette a tutti.Esatto, stiamo arrivando a un momento in cui ci nutriremo di questa specie di pastigliette, ma da buoni italiani noi non cascheremo a questa tentazione.detto questo io credo che sia arrivato il momento di ringraziare Francesco grazie Francesco per essere venuto a trovarci grazie a voi, molto piacevole sera e vi vedo presto grazie Francesco noi ti ringraziamo e ti ricordiamo come sempre che Gitbar da oggi è anche un po' casa tua Quindi quando è qualcosa che ti fa piacere condividere con la nostra community, se il benvenuto c'è una birra sempre fresca.Andrea, sei soddisfatto? Tu da buon fanboy di backstage? Tantissimo, tantissimo, tantissimo.Non vedo l'ora di incontrare anche Francesco e parlare ancora di backstage di persone.Molentieri, sarà un piacere.Grazie a tutti! Grazie, alla prossima! ciao ciao gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con brinreppo parliamo di linguaggi e tecniche di sviluppo web di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei full stack dev Hai detto la parola male! Piantala! Maledizione! Che stronzi questi programmatori! Telefona a quelli di Metri.A Cambridge.
