Il Canada è riconosciuto per il suo popolo amico e amico.

Ma sapevate che quando scelte di promuovere le vostre affare in Canada, scelte anche di far profitare la vostra azienda dalla manovra più adeguata al mondo? Non importa dove trovi l'azienda.

Faciliteremo il suo sviluppo qui.

Investisci in Canada.

Il tuo secondo casamento.

Dicovri d'altri avvantaggi su investircanada.ca.talent Sono stato un po' impegnato, ho girato un po', 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.

La sto spettando a botto questa, 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.chiosciola.gitbar.it Gitbar.it, a proposito, tra un po' aprirò il repository.

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.

Esatto.

Quindi, se tagliamo l'issue con la lab dell'Oktoberfest, possiamo far entrare tutta la community a contribuire.

Esatto.

E se raggiungete, se ricordo bene, 5 pull request registrandomi, avete indietro il gadget degli organizzatori dell'Oktoberfest.

Sì, fighissimo.

Naturalmente, il gadget io l'ho preso l'anno scorso.

La cosa divertente è che era la bellissima maglietta dell'Oktoberfest.

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 Gitbar a Code Motion per tutti quelli che verranno.

Perché sì, c'è un panel di Code Motion dove ahimè dovrete risoportare la mia voce, ve lo dirò alla fine.

Comunque, tra i nostri contatti c'è anche Hetbrain Repo su Twitter e...

Il gruppo Telegram.

Accipicchia, quante persone, quante belle discussioni.

Dai, Het.

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 Gitbar.

Detto questo, io direi che possiamo iniziare.

Benvenuti su Gitbar, 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.

ANDREA, IL NOSTRO OSPITE Andre, non ti avevo avvertito, ma 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.

Nostro.

Sì, vabbè, oggi è una giornata un po' così, quindi...

Va bene, non fa niente, siamo costanti.

Ecco qua, distrugge il microfono.

Ve l'ho detto che era una giornata un po' così, prendetela un po' come va.

No, 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 prodotto, la mia domanda è, chi è Francesco? Eh, bella domanda.

Allora, Francesco è un ultra cinquantenne, ahimè, orgogliosamente, e si definisce, un software engineer.

Io ho fatto sviluppo per più di vent'anni, toccando tantissimi settori, tecnologia 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 miliardi 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? Beh, 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 ragazzi con cui lavoro, che sono assolutamente più bravi di me quando sviluppiavo, 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, ho sempre lavorato su piattaforme che sono molto tecniche, perché è dove mi piace di più, insomma.

Ora lavoro su una piattaforma che aiuta la developer experience, e quindi è un po' non plus ultra per me, è open source, quindi è un paradiso.

Champagne.

Sì, cioè 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 è bisogno un po' sapere che fanno questi developer, altrimenti non è che si può aiutare non sapendo di cosa parliamo, 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? Perché io seguo gli sviluppi di questo strumento da più di un anno, da quando era uscito in alpha, poi beta, la prima staple 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, possiamo dire che forse è anche merito tuo? No, allora, è merito di tutti, considera che dietro c'è...

questa cosa nasce da lontano, davvero, si sente dire agli sportivi, questa mia vittoria alle Olimpiadi nasce da lontano, quando da piccolo mi allenavo...

è esattamente la stessa cosa.

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 assolutamente è un contributo insieme a...

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.

Cioè erano 400 i Spotify, gli sviluppatori, dovevano diventare 1.350 in circa otto 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 4.000 sviluppatori su una app che è tanta, tantissima roba.

C'è, andiamo alla 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, credo, il vuoi più cattivo.

Esatto, capito, era 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, ma è veramente quando...

cioè è più un'adrenalina questo che ho fatto, la responsabilità, cioè è l'adrenalina di giocare...

Io ho la percezione di giocare in serie A, e quindi, devo dirti, 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, ripeto, ormai in 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.

E quindi, diciamo, c'è questa cosa qua.

Il fatto che sia un progetto di grande successo è anche sotto i nostri occhi, ve 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 trecentomila developer che stiamo aiutando, quello che si dice, a avere una vita migliore e più serena.

Stiamoci 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, anche per giustizia, 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 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.

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 develo 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' meglio di definita, soprattutto un po' tuttologi, ce 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, portarli 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ò rimigliorare.

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 manager sono persone con MBA, 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 puntualizzare.

Io in questo periodo sto dedicando tanta attenzione al mondo dei DevRel, sto studiando a livello sistemico le interazioni e le dinamiche che si creano.

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ù 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 è un creiamo 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 il budget, non i developer, ok? E poi se tu hai come target i developer, cioè quindi i team che fanno sviluppo, gli sviluppatori, lo sapete un esercizio bellino che si fa è quello di prendere una persona di marketing, bene? Marketing puro e cominciare a spammare le email, contattare le persone, parlare una persona che parla solo marketing con un tecnico.

Allora, i developer, si dice a Firenze, gli vengono le bolle dopo tre minuti.

Cioè la prima reazione che ha un developer A, alle 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, ok? Quindi ai developer, no ma che vuoi da me? Cioè, capito? 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 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, cioè io ho la soluzione, questo è il pacchetto, dammi i soldi, io ti do la soluzione.

Se te gli dici così a un developer, non ti sta nemmeno a ascoltare, non sa nemmeno cosa vuol dire.

Se gli 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 c'è con il giocatto, 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 ha il lavoro con il developer, eh, non spassa, perché te non è che gli devi vendere cose, te li devi far divertire, e ti devi divertire con loro, perché tanto è tutto relazionato.

Quindi, in questo, l'open source gioca un ruolo spaventoso, perché dimmi te 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, destinato 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.

Scherzi a parte, là ho capito veramente che quando si parla con un cliente qualunque, questo procedo di co-creazione può esserci o non esserci, e 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, deve capire che con te può 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 fanno machine learning, data engineering, che non sono proprio developer.

Ovviamente non tratto poi quelli che sono QA desk.

Data science.

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 stamparadam di 4000 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, cioè li fruivo tramite backstage.

Quindi tutte le, l'onboarding l'ho fatto là sopra.

E questo lo fanno i due 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, una cosa che funziona per Spotify è il fatto che questo strumento non è uno strumento che sia costritti 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, il Codemotion ci sono anch'io, così magari ci si vede anche.

Sicuro! 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 è quella.

Chiarissimo.

Sempre riguardo a questo, cioè ci ha detto perché backstage, cioè perché Spotify ha voluto creare backstage come Spotify Super 2 a Gadiride usa backstage, mi pare, diciamo, al lato sviluppo al 100%, lo comprendo benissimo, me ne ho conosciuto, però la percezione di Francesco riguardo alle altre aziende con cui sicuramente avevai 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 media doctor e questo è fantastico.

Vorrei anche essere in contatto di più, 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, gli dico che Spotify esiste perché c'era un problema di onboarding, c'era un problema di un'azienda microservizi che è passata a gestire più di 35 mila 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 tutte le varie, l'email...

Con Doc, Dropbox...

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.

Più grossa l'azienda, più questa problematica è evidente.

Perché oggi, parliamoci chiaro, siamo in un momento di crisi, ma proprio in un momento di crisi bisogna ottimizzare.

Quindi non è più il momento in cui, vabbè, 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 Deutsche Bank, parliamo di aziende del settore privato, pubblico, farmaceutico, perché questo è un problema che ogni azienda tecnologica sta avendo, soprattutto at 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 at scale, tutti vanno verso i micro servizi 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 dire tutta, c'è quello che Spotify fa una bandiera a ragione, direi, ed è un qualcosa che fa innamorare, in questo senso, tra le discorsi che 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 lo devi fare 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 usare...

se è un ma non, ma non, ma non, è l'innovazione che non viene, non è che l'innovazione viene perché fai una linea di codice a 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 avere controllo di tutta sta nuova qua? E quindi, quando ragioni di queste cose, la gente dice, porca miseria, ma lo sai che ho anche io questo problema, non mi fai capire com'è 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, le resto le posso nominare, altre le devo stare attente.

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 è, io nella mia vecchia azienda ho lavorato su CRM e RP Custom, quindi sviluppavo degli strumenti, 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 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 è quella di rimanere procedure agnostic, e quindi rimanere strumento e non prodotto.

Allora, il discorso è questo, assolutamente sì, e tra l'altro non solo prodotto ma anche tecnologia agnostic, 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 facendo, non sostituendosi al developer, ma creando una cosa che aiuta il developer a rimuovere le distrazioni.

Cioè il discorso è questo, se voi pensate a cosa fanno la maggior parte di 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 deliverata la feature e parte la frusta.

L'hai finita questa cosa, te l'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 repeat yourself, rimuovere il fatto che se io non sono un devop, non mi voglio rompere le scatole, non 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 su un impiego, una pipeline o qualcosa del genere, non c'è nessun problema, lo puoi skippare 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, qua che si può dire? No, no, io sono interessato, lo voglio sapere.

Allora, cosa è 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 un nuovo microservizio, clicco là dove lo voglio mettere, boom, mi porta tutto, già c'è tutto lo scaffolding e la configurazione è già pacchettata.

Quindi ti aziona e ti accelera anche nel momento in cui devi partire con un nuovo servizio.

Ti accelera appunto quello che dicevamo 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 puoi anche comprendere senza parlare con nessuno su chi sta dando impatti alla tua nuova funzionalità, se può dar fastidio a qualcuno perché viene utilizzata oppure no, ce ne so.

Ma 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, abbiamo bisogno assolutamente...

Grazie.

Felicissima.

State contribuendo, tra l'altro, con plug-in e con idee, bug fix, eccetera, eccetera, fantastico, ancora una volta.

Vi ho già invitato a una community session, spero che accetterete, eccetera, ma sennò sembri una marchetta qui.

Qualche punto d'attenzione, difficoltà, perché poi il product manager può sapere anche cosa migliorare, oppure lesson learned, cioè roba che ti senti di dire, perché sennò sembra davvero una marchetta questa cosa.

Cioè, dimmi, andando un po' anche...

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 se volete che se ne parla, potrebbe essere una cosa interessante, che sono ovviamente punti di miglioramento, ma li voglio sentire da te.

Beh, 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, ok? 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 le diverse cose, quindi potremo parlare anche di cose che ancora i nostri ascoltatori non sanno, se non si parla di sistema.

Falco de motion Esatto, falco de motion sicuramente ascolterò con molto piacere anche ai nostri ascoltatori il Totalk 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 ha un'architettura diversa, finquanto c'è tutto lineare.

Sto su GitHub, c'ho AWS, perfetto.

Comincia a mettere altri sistemi di cose che c'è, self-hosted, private cloud, altri strumenti self-hosted, eccetera, dove non tutti i plugin 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 emergency request, diversi contributi, perché ovviamente non essendo un ecosistema che ha 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 limite nostro, potrebbe essere una documentazione che deve essere un po' più approfondita, cioè la documentazione è super tecnica perché si vede che è scritta da sviluppatori, che cos'è questo, che cosa fa questo.

Però forse manca un qualcosa del tipo, noi ti consigliamo di fare così.

C'ho beccato? Sì.

Ah, perfetto, meno male.

Puoi aggiungerne altri, ma insomma, ripeto.

Ma 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.

Ma si parla tendenzialmente di internal developer portal.

Da stare molto attenti rispetto agli internal developer platform, che sembra la stessa cosa.

In realtà no.

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.

E 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 degli internal developer portal.

Perché bisogna aiutare i developer ad essere più produttivi? Perché bisogna semplificare un lavoro che è oggettivamente complesso e 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 portal, 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'internal developer portal è un portale che ha proprio il ruolo di astrarre questa complessità, e quindi io dico sempre che Backstage e gli internal developer portal coordinano e stanno on top di tutti i servizi, ma non sostituiscono nessuno dei servizi nell'azienda.

Quello che dicevi te, Andrea, torna tantissimo, perché è quello che fanno tutti.

Cioè tu non vai a cambiare i servizi alla 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 tuo developer.

E questo il valore aggiunto.

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 dei 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 devop.

Ripeto, devop 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 internal developer portal, ma ti fanno anche molti servizi di provisioning, deployment, quindi tutto questo mondo devop.

Ma è diverso l'internal developer platform, che ripeto è servizi più portal dall'internal developer portal, perché l'internal developer portal, io dico sempre, che senza servizi è completamente inutile, non serve assolutamente a niente.

Senza l'internal 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, 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.

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 cosa ne so, sto banalizzando, la mia pull request è il mio ticket a fianco.

Non ho mai visto una cosa...

non so se è così, sto ragionando in termini astratti.

Il mio ticket su Gira è la mia pull request su GitHub.

Nel contempo magari se è emergiata e deployata, correlata alle informazioni di deploy, prese da Gira stesso, o con informazioni di release.

A livello invece di azione che fai attualmente, dove è il trade-off da triggere un'azione da backstage o la triggere dallo strumento sottostante? Dove è il limite? È una buona domanda.

Allora, va visto caso per caso, perché non è che ci sono veri e propri limiti, è un libro.

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...

ti faccio un esempio, se si usa Git, se si usa GitHub Action piuttosto che 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 questa cosa, quali use case incarna backstage? Il materiale che abbiamo è molto chiaro e ne nomina tre.

Io in genere ne cito quattro, ma sono il Create Manager Explorer, che crea, gestisci e esplora.

In realtà c'è uno quarto che è la documentazione tecnica, technical documentation.

Allora, il Create è praticamente un engine, che è uno scaffolding system, quindi un engine, dove te gli dai uno YAML file che rappresenta il tuo step by step e lui praticamente macina questo 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 repository su Git, piuttosto che Bitbucket, dove farle la struttura giusta, metterci gli esempi, creare la base della documentazione direttamente nel codice, creare l'iPipeline, impostare le autorizzazioni, deployare in un cluster, magari nei AWS, piuttosto che Azure, piuttosto che Google, piuttosto che quello che ti pare a te, impostare correttamente i diritti, vedere la visibilità.

Tutto questo, automaticamente, c'è il robottino dietro, in maniera standard, perché una volta che tu autorizzi il template, non devi far altro, perché ti danno il bollino, l'azienda, per il template, tu picci il tasto e cosa fai? In maniera self-service, 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 picci il tasto, vai a prendere il caffè, magari vai a fare il wifi, torni e te c'hai tutta la tua pipeline in piedi.

Quindi vai su una pagina web, sempre di backstage, e te lì, proprio in sync, 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 unico cruscotto, tutto, il deployment, dov'è, quanti è il 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 picci un tasto da backstage e ti apre la finestra che 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 e ti dice il tuo errore è questo, vattela a guardare.

Ovviamente devi essere esperto nel tuo lavoro, nella tecnologia.

Se sei un QA tester, vai nel tab del QA tester 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 centomila, perché, ripeto, partiamo da un'altra cosa che è molto developer.

Ai developer non piace fare la documentazione, sfido chiunque, ascolta qui, a contattarmi e dirmi no, non è vero, io, a me mi garba da morire fare la documentazione.

Ai 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, peggio andare di notte, allora cosa fai? Vai su Google Doc o Office 365, auguri, poi le cerca le cose.

Quindi allora si fa un, 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 click si salta da una cosa all'altra, e ora la versione va via.

Scusate? Aiuto aggiungendo che se hai motiva di utilizzare l'interfaccia su backstage te lo scrivi su tuoi ide in markdown ed è, l'output è identico.

E certo.

Ho fatto, 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 oggi.

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 e 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.

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 pull request, 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 in Backstage è un plug-in.

E quindi in realtà Backstage alla fine dei salmi non è altro che una collezione di librerie che formano il foundation di Backstage, quindi tutto 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 l'esempio, alcune delle banche mondiali più grandi usano Backstage, e non posso fare nuovi.

Bene? Immaginatevi i sistemi legacy che ce hanno queste istruttori qui, le aziende farmaceutiche, quelle più grandi.

Bene? Quindi loro hanno l'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 a 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, perché eravamo in 0.qualcosa, e c'era troppe beta e alpha al giro, e sì, 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.

Cioè, 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 di staging 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 versioni 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.

7000 membri nel forum, 7000 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, tutte 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.

Ok, ma esiste? Perché ovviamente un content andare a mettere il plugin è comunque una feature, ma che tu puoi plugare appunto, un content toccare il cuore del sistema, che ovviamente la gente anche naturalmente è un po' più inibita.

Però quindi statisticamente c'è meno contributi sul core, ma questo vuol dire che di ingegnera 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, mi pigliano la badirata in testa e hanno ragione.

Aspetta.

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 mi va bene.

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 hai fatto sul WEN, che è importantissima.

Io mi azzardo a dire ragazzi, io questa cosa deve essere deliberata per domani.

Lo so che succede, ho lavorato sui figure, ho lavorato 20 anni in Italia, non so come funziona.

Per ieri, ma lo deliberate per ieri.

Mi azzardo per ieri, fanno una risata e durano una settimana e mezzo e mi fanno sì, va bene.

Sì, fantastico.

Andrea, volevi chiedere qualcosa? Sì, ero curioso di una cosa.

Qual è, secondo Francesco, la killer feature del 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 il backstage.

No, allora, il software catalog, quindi il fatto di avere un repository dove praticamente tutte le tue software entity, API, software entity, risorse, tipo una Big 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 funziona più il portale, invece te vai su questa cosa e te sai subito chi è l'owner di cosa, se ci sono dei security incident in qualsiasi servizio, quali sono le dipendenze, se io ammazzo questo servizio qui, cosa creo e a chi do noia e cosa faccio? Questa è un po' una delle più richieste, ma non è l'unica, non è l'unica.

Si, no, questa cosa...

Scusa Andrea, anche io son 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.

L'abbiamo fatto fino ad oggi e va bene.

Io però ho lavorato per una grande multinazionale, come consulente per una grande multinazionale, parlo di save 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.

E in realtà il nostro PO, che poi tra l'altro è 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 il repository abbiamo aspettato 20 giorni.

A voglia.

Abbiamo fatto i nostri POC nei repository personali, con un certo impatto a livello di azienda, nel senso che le informazioni stanno uscendo fuori, quindi ha un impatto pericoloso in quest'ottica.

Quindi secondo me la vera killer feature è quella.

Però nel contempo, 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 SaaS.

E ne ha 70 SaaS che però hanno l'autenticazione e quella roba, deploiano su quel certo provider.

Secondo me Backstage fitta bene, da questo punto di vista, anche con quel caso d'uso.

Sì, sì, a voglia.

Ci sono aziende, tra l'altro io ne conosco almeno un paio in Italia, dove ci sono pochi sviluppatori, poca complessità.

È ovvio, devi trovare un'azienda in Veneto, relativamente a 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 per 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, semplice quanto 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 usi, casi d'uso.

È complesso, ed è quello su cui i pochi competitor che riescono a stargli dietro, uno, in realtà s'aggrappano, no? Tutti stanno dicendo, ah, backstage complesso, però ti c'è 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.

Quindi alla fine cosa succede? Che chi c'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, decido che si fa così.

Quando hai più di 50 persone è un po' un casino, fa una call dove si dice, fermi tutti, adesso facciamo così.

E quindi immagina che quando ne 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 di 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 e ancora di più...

No, ma infatti lo sai cosa si assiste? Che quelle più piccole in realtà sono molto molto attratti dai software da service.

Cioè noi abbiamo un partner che è Rodi, che prende backstage e lo offre come software da service.

Funziona? Perfetto.

Ovvio c'è il problema che poi hanno tutti quelli che offrano i SaaS, anche qualche competitor, cioè che non lo puoi customizzare come si potrebbe.

Perché non è pensabile che in un SaaS si lo customizzi come vuoi.

Quindi è lì il limite.

Però infatti è vero che si aggrappano sul fatto beh 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 ci abbiamo e ci ho 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 deriviato feeling, anche potenziale a metterci le mani e a comprenderlo.

Si è vero ma...

Non JS come backhand, reazioni frontend.

Però ti dico per esempio, in molte aziende soprattutto strutturate, soprattutto banche, dove vengono da sviluppatori backhand, 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 dicono eh ma io sono DevOps e non sono bravo a questa cosa qua.

Eh 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.

Insomma...

secondo me in realtà a livello, 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 engineer 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, che 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 POC, 70, scusami, 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, creando 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 li portano dall'azienda dicendo non so mai che 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 calaborosa.

Ripeto, noi siamo abituati a pensare al 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 nei finti con SAP in adesso.

Bravo, esatto, si.

Non si dovrebbe dire ma il concetto è questo.

Oppure questi mastodonti che poi...

Guarda, ci sto facendo un'integrazione con SAP quindi 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 POC, spaccalo, miglioralo, eccetera perché se tu porti un qualcosa all'interno della tua azienda dicendo, ho visto che figata è questo se il tuo IT department si eccita su sta roba qui eh ragazzi, sei un pezzo avanti.

Vero, verissimo.

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 backstage con L'avevo già detto uno Esatto, mi chiedevo se oltre a questo avresti annunciato qualcosa oppure non lo farete ancora ma lo vuoi dire solo al Gitbar No, no, c'è, c'è Se si può, non sentirti all'angolo No, non è problema, se non si può non lo faccio, non c'è problema anche perché poi mi crocifiggano c'è un ufficio, il più bello ufficio che abbia mai visto sulla punta di Manhattan a New York Sì, praticamente il concetto è quello ed è su una delle Wall Street Center cioè accanto se ti abbassi ti abbassi e vedi il buco delle tue due gemelle è abbastanza impressionante e 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 e 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 immobiliari ovviamente praticamente la versione di Spotify di Backstage 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 mi sembrava un po' per gli ascoltatori stavo aprendo la mano perché abbiamo la telecamera ci sono 5 persone che per reggere 4000 sviluppatori è piuttosto poco perché in realtà tutto lo sviluppo dei 160 plugin viene fatto dai vari team che sono responsabili dello sviluppo c'è un in-house 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 è una figata vogliamo anche la frase motivazionale andando dalla direzione di Daz no static analysis andiamo con calma abbiamo detto troppo andiamo con calma però il concetto è questo ripeto ancora una volta noi abbiamo parlato fino ad ora a semplificare la vita degli sviluppatori perché è vero però noi stiamo già pensando a dopo perché lì ci siamo già arrivati 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 lo stesso version oltre ai plugin e inner source aggiuntivi Spotify incarna questo sì, questo non è solo con backstage noi in Spotify non abbiamo staging environment è continuous delivery ma di quella vera cioè le pull requests sono sul master branch che tramite la pipeline va direttamente in produzione chiaro 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 dall'open source al core più i 160 plugin 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 barra product manager cosa ci fa dentro backstage? se ci fa qualcosa o se sta in un angolo con la bottiglia? questa è una discussione, allora alcune idee, 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 c'è veramente tanti perché è un asset molto importante per spotify 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 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' non so Andrea come pensi di questo 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 relapse la seconda cosa ah ma allora qua ci possiamo mettere anche il link al nostro blog interno ah ma anche lì ci possiamo mettere anche il link al nostro handbook che ovviamente se la gente sta lì fugge da aggregatore anche per altre cose internamente che non hanno per forza a che fare con lo sviluppo e l'avanzamento ecco questa cosa qui è una cosa che succede a tutti gli adopter incluso Spotify c'è da tenere un po' sotto controllo perché altrimenti diventa un bullione 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 l'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 far perché ti ripeto è una cosa molto naturale integrazione con tipo tabloid e Qlik di data analyst questo c'è già, 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 tabloid, Qlik o con tutto quello che è ecco non vorremmo riproporre questa feature in backstage non ha nessun senso backstage non può diventare tutto non può diventare un developer port scusa, un portal come l'iFray 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 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 è un po' assurdo fargliela fare ecco insomma 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 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 cioè te mi vuoi dire che fammi capire un attimo cioè te mi vuoi dire che se fossi il team di sviluppo di backstage vorresti avere dei dati sull'uso di backstage tra i 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 sott'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 dell'attuazione 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 Nirvan 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 io pensavo che ti riferissi a capire un po' l'utilizzo di backstage tra i vari adopter perché qui si entra in una cosa ferocissima no mica sì, in realtà me migarebbe 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 quindi no no, non è per niente follia è che ovviamente in questo mondo dove bisogna stare attenti alla privacy che è una cosa sacrosanta una cosa del genere semplicemente non fattibile soprattutto in un mondo open source perché figurati se io gli chiedevo a Andrea Andrea senti ti scarico le statistiche di uso nella tua azienda, nel tuo core business figurati te lo immagini ma non perché Andrea, anzi Andrea forse le dovrebbe anche è semplicemente maglio di farmacie, banche, 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, i developer, il portale certo che sì probabilmente piacerebbe anche sapere quante volte viene utilizzata la libreria interna gli innessi 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 cosa si fa alla telemetry o altre cose e qui viene il product manager perché dovrebbe dire cosa è che avviene 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 quindi degli eventi questo grande evento pianificato a Detroit, Michigan soprattutto ero curioso del perché a Detroit e non a Berlino o Giappone c'è un perché molto chiaro esatto e gli after party con la tecnicola no ma lo detto in un tempo pauroso lo 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 meet up 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 farlo 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 ed 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 diciamo per la classifica di contributori 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 faciliti 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 kubecon è 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 hanno detto 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 la 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? non lo so vediamo anche perché non lo decido io perché è più il 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 con gli stessi appassionati per un po' di tempo si creano anche dei rapporti è bellissimo quindi spero che ce ne siano altri presto anche mi mancava per le discussioni di covid sono molto contento e non vedo l'ora sulla seconda domanda meet up e roba varia 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 senza perché ripeto immagini di te alle prime POC quanto, probabilmente l'hai anche fatto quanto farebbe comodo sentire da Andrea 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 cioè te gli dai un aiuto clamoroso che ridurrebbe il commute dei santi dal paradiso con le bestemme quello di sicuro in Italia va di moda all'estero lo sai, la bestemma va un po' più non c'è tanto, poi penso a Fiorentino non c'è Venesi tra di noi e invece il discorso del SIG, questo è interessante perché il SIG, per ora noi abbiamo un tipo di SIG 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 e il motivo è molto semplice non ne facciamo più a coordinare le contribution e la gente ci contatta, i contributor delle aziende ci contattano e ci dicono, ragazzi io vorrei contribuire su questa cosa ma prima di fare la full request vorrei capire se ha senso rispetto alla direzione del prodotto e ancora una volta mi guardano un po' a me e a i miei maintainer un po' come iniziavamo un po' con questa call come per dire, ma te product manager posso fare sto 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 non lo so offende Spotify o offende il prodotto si possono dire, no non lo faccio ma insomma, se no, beh venga e poi ti dico, 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 catalog SIG lo gestisco io insieme a uno dei tecnici, perché quando vengono disposizioni troppo tecnici mi perdo e io faccio il note taker, io riempio il documentino e ascolto quelle che sono esigenze delle varie persone il catalog SIG sta cominciando a dare i suoi frutti perché 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 e scalare la community questo è un po' il concetto chiaro, potrebbe essere anche una specie di trampolino di lancia portare a bordo altri contribution più strutturati e non spot cioè avvicinare maggiormente le persone ad andare in profondità nel core del diciamo, nel catalog 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 scaffolder SIG quindi il motore per creare le applicazioni a ruota c'è il technical documentation il tech doc 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? No, 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 7000 membri mi sembra tre settimane fa siamo già a 7200 e sono passati tre settimane cioè va forte, cresce, poi non è che tutti sono attivi sempre ma 7200 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 cosa è successo la settimana scorsa? mi hanno contattato io tutti i giorni tra Linkedin e la Pavaria 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 ho diversi contatti soprattutto nelle banche noi abbiamo bisogno di un canale brasiliano, se te vai sul Discord c'è un canale solo in brasiliano e ci sono tante persone così e là dentro si sentono più friendly a parlare portoghese si sa che i brasiliani scusa, i portoghesi non sono proprio il massimo con l'inglese io l'ho fatto a volte e invece gli italiani però effettivamente è vero si può fare un canale brasiliano a voglia ma per esempio sull'organizzazione tematica sono bravi ragazzi di Martena ancora una volta ingegneri io non ho nemmeno i diritti per fare queste cose lì, si sono lì ma no no io non posso mi tagliano le braccine chiaro io credo che abbiamo fatto quasi tutte le domande che volevamo fare Andrea hai qualcosa da aggiungere? ma io diciamo ho massacrato abbastanza Francesco sono super soddisfatto quindi no grazie invece e poi ripeto si fa il codemotion si fa l'estensione e tra l'altro abbiamo una birra in sospeso Francesco sappilo volentieri spero di riprendermi ad un raffreddore perché sono un po' no problem, no problem io ragazzi sono un po' in ritardo perché mi è cascata la rete e sono sto 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 aaaah 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 ora 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 Eck è un personaggio veramente un personaggio aaaah tra l'altro su Netflix uscirà la serie sulla sua vita in poche settimane 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 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 ma certo allora sei life as Pete m vi chin chin penn M M M M M M M M M M M il che attualmente noi volevamo collegarci l'utenza per entrare nel sistema di backstage con il nostro sistema di autenticazione interna che è l'head up.

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'head up 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.

Troverete ovviamente nelle note dell'episodio.

Dell'episodio assolutamente sì.

Anche 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? 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.

Sono una figata pazzesca, si chiamano water drop e le trovate nelle note dell'episodio.

Io vorrei provare queste cose perché io ho questo problema nel senso bevo acqua ma e basta perché se no divento un bidone e questa cosa mi piacerebbe tantissimo.

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 serata e vi vedo presto.

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, sei 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.

Molti antieri sarà un piacere grazie a tutti.

Grazie alla prossima.

Ciao ciao.

Gitbar il circolo dei fullstack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev..