Non ho potuto partecipare all’incontro perché non potevo quel giorno, ho letto il verbale/riassunto e vorrei aggiungere qualche commento.
Personalmente, infatti, ho seguito e tuttora seguo un progetto all’interno di un’università dove ci sono vari studenti, volontari, che fanno cose tra cui realizzare software open source.
Non faccio nomi perché non è rilevante, la cosa rilevante è che in questo “team” mi sono passati davanti decine di studenti, quindi under 35, e per anni ci siamo già scontrati con gli stessi problemi e tentato alcune soluzioni di cui avete parlato.
Tutto il mio discorso è focalizzato sulla produzione di software perché è l’area che conosco meglio, non posso commentare su quanto queste cose siano applicabili ad altri tipi di contributi al mondo open source.
La prima cosa di cui tenere conto è che a pochissimi studenti interessano queste attività, si possono fare stime in vari modi ma siamo sempre intorno all’1% o meno. Questo forse perché gli studenti studiano già a tempo pieno e non tutti hanno voglia di caricarsi di altro lavoro e nemmeno retribuito, di fatto, o per semplice disinteresse verso il tema.
La seconda cosa è che quell’1% sono comunque studenti, che stanno all’università per imparare, quindi inutile illudersi che abbiano già competenze incredibili. Anche perché, tra i programmatori duri e puri, al di là del nozionismo con cui vengono ingozzati dall’università, l’esperienza fa tantissimo e l’esperienza si acquisisce solo in anni e anni e anni passati a pigiare tasti, provare, sbagliare e riprovare.
La terza cosa è che la motivazione degli studenti, quella che spinge la gente a imparare l’impossibile in 5 minuti e scrivere migliaia e migliaia di righe di codice di getto, non è mai stata “Che bello contribuire all’open source”, anche perché il software è principalmente di backoffice e ad uso interno quindi non ha neanche un impatto diretto sul genere umano, né tantomeno il “Così imparo qualcosa e faccio la gavetta” anche se un pochino forse fa, e neppure “Questo software risolve problemi reali a persone reali, che quindi sto aiutando” anche se questo può contribuire.
La massima motivazione viene dal fatto che quel software sia utile per sé e dal fatto di avere controllo e libertà per sperimentare e imparare.
E chi arriva in quella situazione, tale da avere quelle due forti motivazioni, è forse un 1% dell’1% poiché devono verificarsi una serie di congiunture: dev’essere una persona che si trova bene nel team e va d’accordo con gli altri studenti (il team diventa la cerchia sociale di alcuni, che invoglia a spendere più tempo lì), che abbia capito le dinamiche interne per evitare di fare una cosa inutile (che motivazione può mai dare creare un software bellissimo e poi vedere che nessuno vuole usarlo a parte sé stessi, o ancora peggio venir criticati?), deve trovare un problema che affligge sé e anche in qualche misura gli altri, deve avere in mente una possibile soluzione (c’è anche un aspetto di autonomia di chi fa le cose, in tutto questo) e deve avere il coraggio di proporla.
Praticamente qualunque cosa venga proposta in tal senso viene approvata con entusiasmo, che di solito è l’ultimo impulso, dopodiché è fatta: quella persona realizzerà il progetto che tanto desideriamo, studiando l’impossibile per farlo, sfornando codice di qualità in tempi record, e così via.
Questa serie di condizioni non è strutturabile, non è meccanizzabile, non è riproducibile a comando, non esistono ricette magiche, non ci sono panacee, non ci sono soluzioni tecnologiche a problemi sociologici: bisogna solo costruire e favorire un certo tipo di cultura, faticando, impegnandosi costantemente, con attenzione e cura, e sperare che nel mucchio di studenti ci sia qualcuno che si ritrovi in quella fortunata congiuntura.
Sì, è anche possibile convincere gli studenti a contribuire dicendo “Guarda che bello l’open source, guarda che bello fare questo software che abbiamo già deciso come fare e che risolve problemi reali”, ma non è la stessa cosa e i progetti che gestiamo in questo modo, per quanto vadano avanti, vanno molto più a rilento e le issue da risolvere aumentano soltanto, perché ci vengono sempre più idee per migliorie incredibile rispetto a quante riusciamo a realizzare in un dato tempo.
E anche in quel caso, l’intera cultura del team dà un aiuto non indifferente. La direzione che ho cercato di dare (perché la cultura non può essere imposta né non può essere pianificata a tavolino, è una proprietà emergente) è di essere sempre disponibili e comunicare per non abbandonare mai la gente a sé stessa in caso di dubbi o difficoltà, tenere conto di ogni dubbio o critica per evitare di realizzare l’inutile o cose che non funzionano, ascoltare chiunque abbia una proposta, non criticare mai (dopotutto è gente che lavora gratis…), prendere le decisioni su base tecnica ma mediarle sempre sulla base di chi ha voglia di fare cosa. Probabilmente queste sono ovvietà, ma non è banale trovare una cultura del genere e non è banale che chi è già “dentro” abbia la forza e la voglia di mantenerla viva.
È infatti molto più facile pensare “nessuno ha voglia di lavorare, sono tutti degli imbecilli tranne me” e decidere tutto di testa propria, fare tutto senza guardare in faccia nessuno o smettere completamente di fare qualunque cosa, o formare cricche che escludono gli altri finché tutti non si stancano e se ne vanno.
Ho sempre cercato di stroncare questi comportamenti sul nascere, spingendo le persone a collaborare o almeno condividere le informazioni e demolendo le cricche come potevo. Questo, di nuovo, richiede costante sforzo, costante vigilanza e anche sufficiente rispetto da parte degli altri per essere ascoltato: non posso demolire una cricca se sono l’ultimo degli ultimi e la cricca sta in cima alla “gerarchia”, non sono i nuovi a poter cambiare le cose, non da soli almeno.
Questo è ovviamente diverso dalla gente che ha voglia di fare e quindi realizza un progetto da sola ma comunicando con gli altri e ascoltando e proponendo e capendo e imparando, le cricche sono diverse dai “jelled team” (un gruppo di persone affiatato) che lavorano per un obiettivo comune e utile a tutti.
Per fare un parallelismo azzardato, in ILS i LUG e le sezioni locali sono da un lato considerabili dei “jelled team” perché la gente che ne fa parte spesso si trova bene e diventano una cerchia sociale che poi organizza anche attività, ma dal punto di vista di ILS sono anche spesso delle cricche, dove può essere difficile entrare per gli esterni e che talvolta (non sempre, lo so) preferiscono occuparsi delle “proprie cose” e contribuire in maniera esigua alle attività di ILS stessa.
Ovviamente non dico di demolire i LUG perché l’aspetto di “coesione sociale” è molto buono e appunto è essenziale secondo me, però vale la pena riflettere su questa cosa e pensare a come far pendere l’ago della bilancia verso “jelled team” piuttosto che cricca. A parte fare i ritrovi in birerria invece che in luoghi sperduti come ha proposto in vari momenti Bob, perché il luogo è solo parte di quello che è più un problema culturale e che richiede cambiamenti forse più ampi di quello che possa fare un singolo LUG.
Ho visto che avete parlato dei corsi: noi ci abbiamo provato e abbiamo fallito miseramente.
Dato che avevamo davanti degli studenti che quindi non sanno già tutto, abbiamo provato a organizzare dei corsi interni al team, non di programmazione ma di ambito informatico, tenuti da altri studenti un po’ più esperti in un determinato campo.
Chi ha seguito i corsi ne era entusiasta e ne voleva ancora con sete insaziabile, ma quello che ci aspettavamo è che la gente, carica di conoscenze e competenze che prima sosteneva di non avere, poi contribuisse alle attività del team. Questo quasi mai è successo. Percepivano i corsi come dei corsi universitari: da seguire attentamente ma fini a sé stessi, da non applicare mai alla realtà neanche per sbaglio. Sono stati solo un colossale spreco di tempo rispetto ai nostri fini, per quanto siano stati apprezzati.
Quanto ai tutoraggi/mentoring, non so esattamente in che ottica ne abbiate parlato, ma da un lato sì, alcune informazioni sono utili ed è meglio che le fornisca un essere umano che parla ad altri esseri umani e non un testo scritto buttato da qualche parte, ma non credo che siano risolutivi.
Intendo dire che, sì, reputo utile è spiegare come funzionano i progetti già avviati, quali sono i requisiti, com’è organizzato il codice, etc… ma quelle mi sembrano informazioni essenziali che in sostanza i maintainer di qualunque progetto dovrebbero fornire ai nuovi contributor.
Può anche essere utile dare qualche indicazione sulle questioni più annose dove la gente spesso inciampa o rischia di perdere tempo. Ad esempio, far vedere come configurare alcune cose utili su Pycharm di persona è più immediato che dire “vai a leggerti la documentazione” che è immensa, oppure se ho esperienza con una certa libreria e so che la documentazione non è molto chiara posso spiegare a un’altra persona come fare alcune cose.
Al di là del fatto che si potrebbe pensare di contribuire alla documentazione della libreria per migliorarla, che si ricollega a un altro punto che volevo sollevare: la cattedrale e il bazaar.
Il software che realizziamo in team è gestito come un bazaar, sia a livello del singolo progetto, sia a livello dell’intero sistema di software che interagiscono: se c’è una buona idea su feature da aggiungere si aggiunge, se qualcuno esterno che usa il nostro software fa una pull request la accettiamo (è successo una manciata di volte), se qualcosa come viene proposto non è fattibile si cerca una soluzione alternativa che abbia senso per tutti, se del codice che qualcuno vuole aggiungere non va bene per qualche motivo (bug, problemi di sicurezza) con educazione si propongono modifiche o chi accetta la pull request fa direttamente le modifiche, se qualcuno vuole realizzare un nuovo progetto gli diciamo “vai!” con entusiasmo se è effettivamente utile, il tutto comunicando come esseri umani.
Invece su progetti open source più grossi dei nostri mi rendo conto che questo sistema sia meno sostenibile, perché se ti arrivano 2 issue in cui non si capisce il problema di solito la voglia di chiedere educatamente delucidazioni la trovi, se te ne arrivano 200 o 2000 a un certo punto non hai più tempo e forza e le chiudi e basta, anche se può sembrare maleducato.
Da qui può avere senso un tutoraggio specifico su questi progetti, tenuto da qualcuno che li conosca decentemente, per evitare che i nuovi contributor si vedano tutte le pull request scartate senza commenti. Non so se era stato proposto questo. In ogni caso dev’essere qualcosa di tenuto da un maintainer o contributor regolare, non è banale trovare qualcuno che lo sia e che abbia tempo e voglia di aiutare i nuovi, né trovare nuovi che abbiano voglia di contribuire proprio a quel progetto, o che abbiano le competenze necessarie. Sui progetti che abbiamo in team possiamo chiudere un occhio su varie cose, essendo principalmente di backoffice l’importante è che funzionino bene per noi, ma per progetti ad uso più pubblico è più difficile trascurare incompatibilità strane con gli ambienti di produzione, bug reconditi, edge case assurdi, potenziali questioni di sicurezza, etc…
Un altro problema è anche che, come ho evidenziato prima, la voglia di contribuire e farsi un mazzo così per farlo, studiando e imparando e facendo cose, viene dalla necessità di risolvere i propri problemi. Quindi chi si trova in quella situazione vuole contribuire proprio a un certo progetto, dove magari vuole aggiungere una feature che ritiene utile o risolvere un bug fastidioso.
Io probabilmente ho avuto sfortuna, ma tutte le volte che ho provato a contribuire a progetti altrui in questo senso mi sono scontrato con un muro: “no questa feature non la voglio perché io non la userei”, “il mio progetto punta al minimalismo, questa funzionalità è troppo complicata”, “no, aggiungere la compatibilità con questa cosa non va bene perché non voglio aggiungere altri test e non sarebbe coperta, anche se la copertura dei test è il 20% del codice al momento”.
Non è il “gatekeeping” del “formatta meglio il codice, riorganizza l’architettura, fai passare i test, risolvi i warning del linter e poi ti accettiamo le modifiche” che potrebbe avere un grande progetto, è una gestione dei progetti a cattedrale, spesso nel deserto, dove il maintainer (dittatore benevolo, azienda, gruppo di amiconi, etc…) rifiuta una modifica con motivazioni più o meno sensate ma senza possibilità di appello.
Questo è un altro problema culturale e che ovviamente non possiamo essere noi a risolvere: la gente dovrebbe solo farsi furba e capire che se arriva qualcuno col codice in mano e ti implora di accettarlo è perché risolve problemi reali e dovresti solo essere contento di poter aiutare qualcuno con uno sforzo minimo, così come sicuramente hai usato gratis migliaia di programmi e librerie realizzati da altri e che ti hanno aiutato. Oppure leggere “La cattedrale e il bazaar”, è un testo veramente breve, non ci cono scuse per non conoscerlo.
Quindi? Quindi se io voglio contribuire proprio a quel progetto e non genericamente “contribuire all’open source” che è un obiettivo che nessuno ha come primario, cosa me ne faccio di un hackathon dove ci sono tanti bei progetti, che non conosco, che non uso, che magari non mi interessano, per risolvere issue decise da altri in maniere spesso decise da altri, per fare pull request che magari non verranno mai accettate?
Oppue, a cosa può servirmi un tutoraggio “generico” (di nuovo, non so bene se se ne sia parlato) su progetti che non mi interessano, o sul “contribuire” generico che magari dà qualche informazione generale ma non aiuta a leggere nella testa dei maintainer e capire cosa vogliono?
L’hackathon secondo me può essere utile per “imparare a programmare”, certo, ma non per fare la “gavetta”, non per essere motivati, non per fare qualcosa di utile per sé, è alla stregua di dire “contribuisci all’open source perché è bello”, credo che pochissime persone possano trovarlo stimolante da quel punto di vista. E le infinite liste di TODO di ILS, che continuano a crescere, temo che crescano per la stessa ragione.
L’unica speranza che vedo è una congiunzione astrale difficilissima per cui qualcuno è infastidito da un certo problema e per miracolo la issue è su quel medesimo problema e la issue è un po’ l’equivalente dell’entusiasta “vai!” che dà l’impulso, piutosto che dividere per temi o fare TODO list colossali. Ma è inutile illudersi che un 1% di un 1% di una ridotta % di persone che sanno programmare e hanno un minimo di tempo e voglia si trovi in quella situazione guardando la LugMap o LinuxSi o altro: è possibile, ma le possibilità sono veramente esigue e l’unico modo per aumentarle è a monte e consiste in un costante lavoro per attirare persone e realizzare una cultura che incoraggi questo genere di contributi. Oltre a cercare di diffondere il più possibile i propri progetti e fare in modo che siano più utilizzati, che è impossibile per i vari repository con siti, lo so, nessuno si metterà mai a self-hostare LinuxSi perché non avrebbe senso.
Non è per nulla semplice e richiede un sacco di tempo e fatica, non ho soluzioni semplici da proporre purtroppo.
Ho invece una proposta più azzardata, che mi è venuta in mente mentre scrivevo quindi non è molto ragionata quindi prendetela con le pinze.
Insomma, si potrebbe considerare l’aspetto economico: sia dal punto di vista che i soldi sono una motivazione a sé stante, sia dal punto di vista che un lavoro pagato purtroppo viene considerato in maniera leggermente più seria del “fare cose a caso gratis” anche noto come volontariato.
Ad esempio, ho visto vari studenti preferire tirocini e stage pagati una miseria rispetto al “lavoro” in team, dove invece di essere seguiti e sostenuti come avremmo fatto noi venivano messi come polli in batteria davanti a un computer e spinti a produrre codice-spazzatura senza alcuna indicazione, del tipo che il capo dice “realizzami questa cosa con questa libreria, se hai dubbi leggi la documentazione, tra 3 giorni torno e valuto il tuo lavoro, ciao” e dopo 3 giorni tornava per dire che erano cambiati i requisiti e bisognava rifare tutto da capo. Questo in qualche modo veniva visto dagli studenti come un’esperienza edificante o almeno che valesse la pena fare, e veniva vista così a posteriori.
Personalmente non me ne capacito, però se lo standard è questo, se in ILS vogliamo giovani che contribuiscano scrivendo codice con le loro manine, si potrebbero proporre agli studenti dei tirocini pagati. Loro si prendono dei CFU e 600 € in cambio di 300 ore di lavoro, noi ci prendiamo il codice, magari gli studenti si appassionano e restano anche dopo, in quel giro la gente inizia a vedere ILS come “una cosa seria” con gente che lavora e non come una banda di scappati di casa dove dei nerdacci barbuti che non si lavano fanno cose inutili gratis, si demolisce il meme che “il software libero non paga perché è fatto interamente da volontari volenterosi” (che già non è vero perché è pieno di aziende con dipendenti regolarmente saliarati che fanno software open source, ma è una cosa veramente poco nota, per quanto a noi sembri assurdo).
Tuttavia non ho idea se ciò sia fattibile dal punto di vista legale.
Qualcosa del genere sarebbe, secondo me, molto più efficace sui giovani rispetto a promettere premi (dove 10 persone lavorano, 1 vince e si prende i soldi e gli altri hanno solo perso tempo) o pagare cifre misere a gente che lavora.
Infatti lo stadio successivo degli studenti universitari è il lavoro, a tempo pieno, presso un’azienda, che rende molto più faticoso contribuire volontariamente ad altro (che voglia hai dopo 8 ore o più passate a pigiare tasti su una tastiera, di accendere il computer e fare di nuovo la stessa cosa?) e non rende minimamente attraenti “100 € se fai questa cosa”, per quanto gli stipendi medi dei neolaureati siano una miseria quei 100 € possono creare problemi burocratici (chi lavora in una grande azienda spesso deve dichiarare e chiedere autorizzazioni per fare qualsiasi altra forma di lavoro retribuito) o fiscali (vale davvero la pena complicarsi la vita per dichiarare correttamente quei 100 € o rischiare multe? Per una persona che ha un unico reddito da lavoro dipendente, cioè la schiacciante maggioranza della gente comune, è solo una rottura di scatole ulteriore).
Invece non ho mai visto alcuno studente esprimere anche solo lontanamente il desiderio di lavorare in proprio, cosa che permetterebbe di accettare più facilmente eventuali miseri pagamenti a progetto e affini, per questo la struttura del tirocinio/stage potrebbe avere più senso.
Ah, un’ultima cosa: è vero, è difficile trovare programmatori PHP. Ma i linguaggi di programmazione dello stesso tipo sono tutti uguali: chi sa già programmare in altri linguaggi OOP, ad esempio, non ci mette nulla a imparare PHP se vuole. Non si parte da 0 in quel caso, è più un partire da 90 per arrivare a 100.
Conoscere i concetti senza tempo permette di saltare da un linguaggio all’altro senza difficoltà: la logica booleana è la stessa, le strutture di controllo sono sempre le stesse, le classi sono sempre le stesse, le strutture dati sono sempre le stesse, gli algoritmi sono sempre gli stessi, il funzionamento del debugger è sempre lo stesso… Sì, cambia la sintassi, cambiano le funzioni di libreria, ma non è una tragedia, una persona che sappia programmare quelle cose le impara in fretta o le cerca nella documentazione.
Se cercando “programmatore con lunga e larga esperienza pluriennale in PHP” non si trova nessuno, si può provare umilmente a cercare “programmatore che conosca decentemente un paio di linguaggi OOP e disposto a programmare in PHP”.
Il problema forse è che PHP non attira, per via delle gente che vive per meme e ripete come scimmie “PHP è incoerente, è insicuro, è brutto, è cattivo, è un martello con due levachiodi”, ma non so bene come risolvere questo, a parte ripetere ossessivamente dei concetti opposti ma più verosimili di queste critiche ormai stantie da un decennio…
