Security Weekly: GitHub tra decentralizzazione e sospensioni
Il sogno decentralizzato di Dorsey per il controllo di versione del software
📬 Ben ritrovato caro cyber User.
La storia si ripete, sempre uguale a se stessa. Jack Dorsey, l’uomo che ha creato Twitter per poi vederlo trasformarsi in qualcosa che probabilmente non aveva immaginato, torna a parlare di decentralizzazione. Questa volta il bersaglio non sono i social network, ma GitHub, la piattaforma che negli ultimi anni è diventata il cuore pulsante dello sviluppo software mondiale. E come sempre accade quando Dorsey si esprime, le sue parole cadono su un terreno già fertile di malcontento.
La vicenda parte da una segnalazione apparentemente banale: uno sviluppatore si ritrova con l’account GitHub sospeso. Non è il primo, non sarà l’ultimo. Ma questa volta la discussione prende una piega interessante quando qualcuno suggerisce la necessità di una versione distribuita di GitHub per prevenire proprio queste situazioni. E Dorsey risponde con un laconico “Yes”, una parola che racchiude in sé un mondo di implicazioni tecniche e filosofiche.
La questione delle sospensioni su GitHub merita un’analisi approfondita perché tocca un nervo scoperto dell’intero ecosistema dello sviluppo software contemporaneo. GitHub è diventato nel corso degli anni molto più di una semplice piattaforma di hosting per repository Git. È diventato il portfolio dello sviluppatore, il luogo dove si costruisce la propria reputazione professionale, dove si collabora su progetti open source, dove si documenta anni di lavoro e di contributi alla comunità. Quando Microsoft ha acquisito GitHub nel 2018 per 7,5 miliardi di dollari, molti hanno storto il naso, ma la maggior parte degli sviluppatori ha continuato a utilizzare la piattaforma, considerandola ormai indispensabile.
Il problema delle sospensioni arbitrarie, o perlomeno percepite come tali, non è nuovo. Nel mio caso personale, alcuni mesi fa, mi sono ritrovato con l’account sospeso senza alcuna spiegazione chiara. Nessun preavviso, nessuna possibilità di dialogo, solo un messaggio standardizzato che informava della sospensione. Il risultato? Anni di lavoro, contributi a progetti, fork personali, tutto inaccessibile. La perdita non è stata solo di codice, che in molti casi avevo in locale, ma di tutta quella rete di relazioni, issue tracking, pull request, discussioni tecniche che rappresentano il vero valore di una piattaforma collaborativa come GitHub.
La risposta di GitHub a queste situazioni è sempre la stessa: termini di servizio violati, procedure standard, impossibilità di fornire dettagli per motivi di sicurezza. Ma per chi si trova dall’altra parte dello schermo, questa opacità è inaccettabile. Come può uno sviluppatore professionale costruire la propria carriera su una piattaforma che può cancellare anni di lavoro con un click, senza possibilità di appello o anche solo di recuperare i propri dati? La ricercatrice di sicurezza Celeste ha raccontato un caso analogo: account bloccato senza motivo apparente, nessun accesso per fare backup dei repository. Una situazione kafkiana che evidenzia quanto sia pericolosa la dipendenza da un’unica piattaforma centralizzata.
Qui entra in gioco la proposta di Dorsey e la questione diventa tecnicamente interessante. Git, di per sé, è già un sistema di controllo versione distribuito. Ogni clone di un repository è una copia completa della storia del progetto. Non esiste un server centrale che detenga la verità assoluta. È nella natura stessa di Git essere decentralizzato. Il problema non è Git, ma quello che ci abbiamo costruito sopra: GitHub, GitLab, Bitbucket e le altre piattaforme che hanno centralizzato la collaborazione aggiungendo layer di servizi che diventano poi indispensabili.
L’infrastruttura per un GitHub decentralizzato esiste già, tecnicamente parlando. Moe Amaidi, consulente IT, lo spiega chiaramente: Git è già robusto e distribuito, gestisce repository di qualsiasi dimensione. Il problema è che GitHub non compete sul piano del controllo versione, ma su quello dell’ecosistema: issue tracking, continuous integration e continuous deployment, code review, sistemi di discussione integrati, gestione delle chiavi SSH, autenticazione, autorizzazioni granulari. Tutto questo funziona perché c’è un’entità centralizzata che lo gestisce.
Esistono già tentativi di creare alternative decentralizzate. Radicle, per esempio, è una piattaforma peer-to-peer per la collaborazione sul codice costruita sopra Git. Secondo i dati di settembre dello scorso anno, aveva circa duemila repository e poco più di duecento nodi attivi settimanalmente. Numeri ridicoli se confrontati con i centocinquanta milioni di utenti di GitHub. Il problema è evidente: la decentralizzazione ha un costo in termini di usabilità e convenienza. Mantenere un nodo, gestire la sincronizzazione, occuparsi della discovery dei peer, tutto questo richiede uno sforzo che la maggior parte degli sviluppatori non è disposta a fare quando può semplicemente creare un account su GitHub e dimenticarsi dell’infrastruttura sottostante.
La questione della decentralizzazione tocca anche aspetti più sottili. Un sistema veramente distribuito richiederebbe un ripensamento completo di come gestiamo l’identità digitale, la reputazione, la fiducia. Su GitHub, il tuo profilo è legato a un’identità centralizzata gestita dalla piattaforma. In un sistema distribuito, come si garantisce che l’utente Alice su un nodo sia la stessa Alice su un altro nodo? Come si prevengono attacchi Sybil? Come si gestisce la moderazione dei contenuti in un ambiente dove non esiste un’autorità centrale? Sono domande che l’industria blockchain si pone da anni senza aver trovato risposte completamente soddisfacenti.
Dorsey, naturalmente, è un grande sostenitore della blockchain e delle tecnologie decentralizzate. Quest’anno ha lanciato BitChat e White Noise, due applicazioni di messaggistica decentralizzata. Il suo approccio è coerente con la filosofia di David Clark, lo scienziato informatico che ha contribuito allo sviluppo di Internet fin dagli anni Settanta e che predicava il consenso e il codice come principi fondamentali. Ma c’è una differenza sostanziale tra gli ideali e la realtà pratica dell’adozione di massa.
Il vero problema è che la maggior parte degli sviluppatori sceglie GitHub non perché sia tecnicamente superiore, ma perché è dove si trova la comunità. È l’effetto network in tutta la sua potenza: GitHub vale perché ci sono gli altri sviluppatori, i progetti open source importanti, i recruiter che cercano talenti guardando i profili. Spostarsi su una piattaforma alternativa, anche se tecnicamente migliore, significa perdere questa rete. È lo stesso problema che affligge ogni tentativo di creare social network alternativi: puoi costruire la piattaforma tecnicamente perfetta, ma se non ci sono gli utenti, rimane un deserto.
La mia esperienza personale con la sospensione dell’account GitHub mi ha portato a una conclusione semplice: non ricreerò un account su quella piattaforma. La perdita di fiducia è totale. Ma questa scelta individuale deve essere supportata da alternative concrete. Ho spostato i miei progetti su piattaforme self-hosted, e usando Gitea per ora, mentre invece l’account dedicato a Ransomfeed è ancora su GitHub. È più complicato? Certamente. Richiede manutenzione? Assolutamente. Ma ho il controllo completo sui miei dati e nessuno può svegliarsi una mattina e decidere di cancellare anni del mio lavoro.
Questa è però una soluzione che funziona per chi ha le competenze tecniche e le risorse per gestire la propria infrastruttura. Per la stragrande maggioranza degli sviluppatori, soprattutto quelli agli inizi della carriera, GitHub rimane la scelta obbligata. Ed è qui che la proposta di una piattaforma decentralizzata diventa interessante, almeno in teoria. Se Dorsey o qualcun altro riuscisse a creare un sistema che offre le stesse funzionalità di GitHub ma con le garanzie della decentralizzazione, potremmo assistere a uno spostamento significativo.
Il problema è che “le stesse funzionalità” è una condizione molto stringente. Gli sviluppatori si sono abituati a GitHub Actions per la CI/CD, ai GitHub Packages per la distribuzione dei pacchetti, a GitHub Copilot per l’assistenza AI nel coding. Replicare tutto questo in un ambiente decentralizzato è un’impresa titanica. E poi c’è la questione delle prestazioni: un sistema peer-to-peer introduce latenze e complessità che un server centralizzato non ha. Come si gestisce la scoperta dei peer? Come si garantisce la disponibilità dei repository? Come si previene che nodi malevoli corrompano i dati? Secondo me andrebbe fatto un ragionamento e un passo leggermente indietro, verso la natura originale di Git. Noi ci siamo abituati ad un ecosistema che non è necessariamente “sviluppare” in senso stretto e si potrebbe benissimo tornare alle origini, con meno fantasmagoriche funzioni, ma con maggiore sicurezza e rispetto per chi costruisce tale rete.
La blockchain potrebbe offrire alcune soluzioni, ma introduce i suoi problemi. La scalabilità delle blockchain pubbliche è notoriamente limitata. Le transazioni hanno costi, anche quando si tratta solo di aggiornare riferimenti a commit. La governance di una piattaforma decentralizzata basata su blockchain richiederebbe meccanismi di consenso che potrebbero essere lenti e macchinosi. E poi c’è sempre il rischio che, come spesso accade nel mondo crypto, il progetto diventi più una speculazione finanziaria che una vera soluzione tecnica.
Guardando ai dati statistici, GitHub ha raggiunto dimensioni che lo rendono praticamente insostituibile nell’ecosistema attuale. Con centocinquanta milioni di utenti e milioni di repository, qualsiasi alternativa parte con uno svantaggio competitivo enorme. Anche GitLab, che è probabilmente il concorrente più serio e che offre opzioni self-hosted, non è riuscito a scalfire significativamente la dominanza di GitHub. E GitLab è centralizzato esattamente come GitHub, quindi non risolve il problema delle sospensioni arbitrarie.
La situazione attuale ricorda molto quella dei social network. Tutti sanno che affidare la propria presenza digitale a piattaforme centralizzate è rischioso, ma le alternative decentralizzate come Mastodon o ActivityPub non hanno raggiunto una massa critica sufficiente. Gli sviluppatori sono consapevoli del rischio di vendor lock-in con GitHub, ma continuano a usarlo perché i benefici immediati superano i rischi percepiti. Almeno fino a quando non si ritrovano con l’account sospeso.
Le soluzioni esistono, ma richiedono un cambio di mentalità. La federazione potrebbe essere una via di mezzo interessante: invece di un’unica piattaforma centralizzata o di un sistema completamente peer-to-peer, si potrebbero avere istanze federate che comunicano tra loro usando protocolli standardizzati. È l’approccio di ActivityPub per i social network, e potrebbe funzionare anche per il code hosting. Ogni istanza mantiene il controllo sui propri utenti e repository, ma può interagire con le altre istanze per la collaborazione. Se un’istanza comincia a comportarsi male con sospensioni arbitrarie, gli utenti possono migrare su altre istanze mantenendo la loro identità e storia.
Il ruolo di Dorsey in questa discussione è ambivalente. Da un lato, è uno dei pochi imprenditori tecnologici di alto profilo che ha dimostrato un impegno coerente verso la decentralizzazione, anche a scapito dei propri interessi commerciali immediati. Dall’altro, i suoi progetti precedenti hanno mostrato che c’è un gap significativo tra gli ideali e l’implementazione pratica. Twitter, sotto la sua guida, è diventato sempre più centralizzato e controllato, nonostante le sue dichiarazioni a favore della decentralizzazione. Bluesky, il progetto di social network decentralizzato che ha promosso, è ancora in fase di sviluppo e deve dimostrare di poter funzionare su larga scala.
La domanda è se il mercato sia pronto per una piattaforma di code hosting decentralizzata. Gli sviluppatori che hanno subito sospensioni arbitrarie sono sicuramente interessati, ma sono una minoranza. La maggioranza silenziosa continua a usare GitHub senza problemi e probabilmente continuerà a farlo anche se emergesse un’alternativa decentralizzata. A meno che non accada qualcosa di drammatico, un cambio di policy massivo o una serie di sospensioni così diffuse da creare un movimento di protesta, è difficile immaginare un esodo di massa.
La tecnologia per costruire un GitHub decentralizzato esiste. Git stesso è già distribuito, i protocolli peer-to-peer sono maturi, la crittografia per garantire identità e integrità è disponibile. Il problema è costruire un’esperienza utente che sia altrettanto fluida e conveniente di quella offerta da GitHub, con tutti i suoi servizi integrati. Questo richiede non solo competenza tecnica, ma anche visione di prodotto e capacità di costruire una comunità.
La mia scelta personale di abbandonare GitHub e gestire la mia infrastruttura è una soluzione che funziona per me, ma non è scalabile. Non posso aspettarmi che ogni sviluppatore monti il proprio server Gitea o GitLab. Serve un’alternativa che offra la stessa facilità d’uso di GitHub ma senza il rischio di perdere tutto da un giorno all’altro. E questa alternativa deve essere economicamente sostenibile, perché gestire l’infrastruttura costa, e qualcuno deve pagare.
Forse la risposta non è una singola piattaforma alternativa, ma un ecosistema diversificato di soluzioni, ognuna adatta a esigenze diverse. Per progetti critici e professionali, istanze self-hosted o gestite da organizzazioni di cui ci si può fidare. Per la collaborazione open source, piattaforme federate che permettono l’interoperabilità. Per sperimentazioni e progetti personali, soluzioni peer-to-peer completamente decentralizzate. La monocultura di GitHub è comoda, ma è anche fragile e pericolosa.
Il “Yes” di Dorsey è significativo non tanto per quello che dice, quanto per la conversazione che apre. La decentralizzazione di GitHub è tecnicamente possibile, ma politicamente e economicamente complessa. Richiede un ripensamento di come gli sviluppatori collaborano, di come si costruisce la reputazione professionale, di come si garantisce la disponibilità e l’integrità del codice. Sono sfide che vanno oltre la tecnologia e toccano aspetti sociali ed economici dell’industria del software.
Nel frattempo, continuerò a evitare GitHub e a investire il mio tempo in soluzioni alternative. Non è una scelta facile, e comporta sacrifici in termini di visibilità e networking. Ma la dipendenza da una piattaforma centralizzata che può cancellare il tuo lavoro senza spiegazioni è una dipendenza sbagliata, un rischio che non sono più disposto a correre. E forse, se abbastanza sviluppatori faranno la stessa scelta, il mercato risponderà con soluzioni migliori. O forse no, e GitHub continuerà a dominare l’ecosistema. Ma almeno avrò il controllo sui miei dati e sul mio lavoro, che alla fine è tutto ciò che conta davvero.
Anche quest’oggi abbiamo concluso, ti ringrazio per il tempo e l’attenzione che mi hai dedicato, augurandoti buon fine settimana, ti rimando al mio blog e alla prossima settimana per un nuovo appuntamento con NINAsec.
Il network
Con questo piccolo schema riepilogo in breve i punti di riferimento che alimento con i miei contenuti, su diversi fronti, quasi quotidianamente.
Ransomfeed.it - piattaforma di monitoraggio ransomware, realtime;
inSicurezzaDigitale.com - blog di sicurezza informatica con approfondimenti tematici;
SecureBulletin.com - news internazionali su cyber security, analisi e frodi;
Spcnet.it - notizie geek;
ilGlobale.it - note politiche e di economia, di rilevanza internazionale;
Ziobudda.org - notizie Linux, open source e software libero, segnalabili e commentabili (socialnews).
NewsDF - il raccoglitore di tutto questo, con un suo feed RSS generale, per non perdere niente di quello che pubblico.