Diciotto anni. Tanto è durato il rapporto tra Mitchell Hashimoto — il creatore di Vagrant, cofondatore di HashiCorp, utente GitHub numero 1.299 — e la piattaforma che ha definito un’intera generazione di sviluppatori. Il 28 aprile 2026, Hashimoto ha annunciato che Ghostty, il suo emulatore di terminale open source, abbandona GitHub. Non per un capriccio, non per una moda: perché GitHub, nelle sue parole, «non è più un posto per lavorare seriamente». La notizia ha fatto esplodere la community tech — migliaia di reazioni, oltre 800 commenti — e ha riaperto una ferita che la comunità open source si ostina a ignorare da troppo tempo.
Ghostty non è un progetto marginale: è un terminale veloce, GPU-accelerato, multipiattaforma, con un’interfaccia nativa che ha conquistato una comunità fedele di sviluppatori. Che un progetto di questa portata, guidato da uno dei nomi più rispettati dell’ecosistema, decida di andarsene da GitHub non è gossip tech. È un segnale politico. Significa che il patto implicito tra GitHub e chi ci lavora si sta sgretolando, e le ragioni vanno molto oltre qualche server che non risponde.
Hashimoto ha tenuto un diario per un mese intero, segnando con una X ogni giorno in cui un disservizio di GitHub gli impediva di lavorare. Il risultato? «Quasi ogni giorno ha una X.» Mentre scriveva l’annuncio stesso, un’interruzione di due ore di GitHub Actions gli ha bloccato le review delle pull request. L’ironia è talmente amara da sembrare una sceneggiatura scritta male. Ma dietro i numeri dei disservizi c’è una storia più grande — una storia di monopolio, estrazione di valore e tradimento della filosofia open source. Ed è ora di raccontarla senza giri di parole.
GitHub non funziona più (e non è un caso)
I numeri parlano da soli, e sono impietosi. Solo tra febbraio e marzo 2026, GitHub ha accumulato oltre 65 incidenti documentati — 37 nel solo mese di febbraio, 28 a marzo — con otto interruzioni gravi che hanno fatto saltare la soglia del 99,9% di disponibilità promessa ai clienti Enterprise. Non stiamo parlando di rallentamenti impercettibili: parliamo di ore in cui milioni di sviluppatori nel mondo non potevano fare merge, non potevano eseguire test, non potevano pubblicare codice. Il 9 febbraio un cluster di database responsabile dell’autenticazione è andato in tilt per colpa di modifiche alla configurazione che hanno scatenato un’elaborazione incontrollata in background — un effetto domino che ha messo in ginocchio l’intera piattaforma. E ad aprile la musica non è cambiata: il 23 aprile un altro disservizio, il 28 — il giorno stesso dell’annuncio di Hashimoto — ancora problemi con Elasticsearch che mandavano in errore le pull request.
GitHub lo ha ammesso pubblicamente, con quel tono aziendale che sa tanto di comunicato scritto dall’ufficio legale: «Non abbiamo rispettato i nostri standard di affidabilità.» Ha parlato di «accoppiamento stretto tra servizi» che trasforma un guasto locale in un collasso sistemico, di incapacità di gestire il carico proveniente da client problematici. La piattaforma aveva iniziato a ottobre 2025 un piano per aumentare la capacità di dieci volte, ma a febbraio 2026 si è resa conto che serviva un’infrastruttura capace di reggere trenta volte il carico attuale. Detto in parole povere: GitHub è cresciuto più in fretta di quanto Microsoft fosse in grado di gestire, e gli sviluppatori ne pagano le conseguenze ogni singolo giorno. Il tutto mentre Microsoft non ha il minimo problema a trovare miliardi da investire in OpenAI e data center per l’intelligenza artificiale — ma per i server che tengono in piedi l’infrastruttura del software mondiale, evidentemente, i soldi non bastano mai.
Il nocciolo della questione, però, non è tecnico. È politico. Un ex dipendente di GitHub, intervenuto nella discussione su Hacker News, ha messo il dito nella piaga con una lucidità che vale più di mille comunicati stampa: «Dopo l’acquisizione da parte di Microsoft, si sono create molte strade per fare carriera dentro GitHub-la-divisione-di-Microsoft che non avevano nulla a che fare con GitHub-il-prodotto.» Le priorità sono cambiate, e non a favore di chi scrive codice. Il CTO di GitHub ha esplicitamente messo la migrazione verso Azure davanti al lavoro sulle funzionalità del prodotto — lo ha fatto a ottobre 2025, pubblicamente, e i risultati li abbiamo sotto gli occhi. Un altro commentatore ha sintetizzato il problema con una domanda che dovrebbe togliere il sonno a chiunque mantenga un progetto open source su GitHub: «Non esiste nessun canale attraverso il quale un utente normale possa migliorare GitHub continuando a usarlo.» Il feedback degli sviluppatori non sposta nulla. Le decisioni strategiche si prendono a Redmond.
Facciamo un passo indietro per capire la portata della cosa. GitHub ospita oltre 200 milioni di repository. È l’infrastruttura su cui si regge una fetta enorme del software mondiale — dalle librerie che fanno girare il tuo browser ai sistemi che gestiscono ospedali, banche, trasporti pubblici. Eppure questa infrastruttura critica è nelle mani di una singola azienda privata, che l’ha comprata nel 2018 per 7,5 miliardi di dollari non per amore dell’open source, ma perché aveva capito che controllare il luogo dove il codice nasce significa controllare l’intera catena del valore del software. Chi ha seguito i problemi di sicurezza del cloud Microsoft non si stupirà: è lo stesso schema. Si acquista un’infrastruttura critica, la si lascia degradare perché gli investimenti vanno altrove, e quando il giocattolo si rompe non paga l’azienda — pagano gli sviluppatori, pagano i progetti open source, pagano le comunità che hanno costruito le loro fondamenta su una piattaforma che non controllano e non controlleranno mai.
Copilot e il grande saccheggio del codice libero
Se la crisi di affidabilità è il sintomo visibile, la malattia ha un nome più preciso: estrazione di valore. Il caso emblematico è GitHub Copilot — l’assistente di programmazione AI che Microsoft ha costruito addestrando i modelli di OpenAI su miliardi di righe di codice pubblico ospitato sulla piattaforma. Codice scritto da milioni di sviluppatori, rilasciato sotto licenze open source che prevedono condizioni precise di riutilizzo e attribuzione. Condizioni che Copilot ignora sistematicamente, suggerendo blocchi di codice senza mai informare l’utente della licenza originale, senza attribuire credito a chi quel codice l’ha effettivamente scritto. Chi cerca alternative open source a GitHub Copilot lo fa anche per questo: perché non vuole essere complice di un meccanismo di espropriazione mascherato da innovazione.
Non è un’interpretazione partigiana: è il cuore di una causa legale depositata nel novembre 2022 presso il tribunale federale della California settentrionale dallo studio Saveri e dall’avvocato Matthew Butterick, per conto di programmatori open source. Nel 2024 il tribunale ha bocciato alcune accuse legate alla proprietà intellettuale pura, ma — e qui sta il punto cruciale — ha fatto proseguire le cause per violazione delle licenze e dei contratti. Il messaggio del giudice è stato inequivocabile: le licenze open source non sono suggerimenti, sono accordi giuridicamente vincolanti. Eppure Microsoft continua a vendere Copilot come servizio in abbonamento, ha appena modificato i piani ad aprile 2026, e il meccanismo resta identico nella sua brutalità: ospiti il codice gratis sulla tua piattaforma, lo risucchi nei tuoi modelli AI, poi lo rivendi sotto forma di abbonamento a chi l’ha scritto. Se questa non è estrazione di valore in stile capitalismo delle piattaforme, francamente non so cosa lo sia.
La questione Copilot ha cambiato radicalmente la percezione che molti sviluppatori avevano di GitHub. Per anni, la piattaforma era stata vista come uno spazio sostanzialmente neutro — un luogo dove il codice nasceva e cresceva in modo collaborativo, quasi una piazza pubblica del software. L’acquisizione da parte di Microsoft nel 2018 aveva generato malumore, certo, ma molti avevano dato il beneficio del dubbio: finché il servizio funziona e resta gratuito per i progetti open source, che male c’è? Copilot ha spazzato via quell’illusione con la delicatezza di un bulldozer. Ha reso evidente che GitHub non è un servizio pubblico — è una miniera, e gli sviluppatori sono i minatori che scavano gratis. Hashimoto stesso, pur concentrando le sue critiche pubbliche sull’affidabilità, ha toccato un nervo scoperto quando ha scritto: «Voglio fare codice, e GitHub non vuole che io faccia codice.» Dietro la frustrazione tecnica c’è una consapevolezza più profonda: la piattaforma non lavora per te. Lavora per i suoi azionisti.
E non è solo una questione di principio astratto: è una questione concreta di potere. Chi controlla l’infrastruttura su cui il software viene sviluppato ha un vantaggio strategico enorme — può decidere le regole, modificare unilateralmente i termini di servizio, limitare l’accesso, estrarre dati dai repository senza chiedere il permesso. La stessa OpenAI, per dire, aveva valutato di costruire la propria alternativa a GitHub per non dipendere da una piattaforma che va in tilt quando serve. Questa asimmetria di potere tra chi possiede la piattaforma e chi ci lavora sopra è il vero cuore del problema, e nessun miglioramento dei server potrà mai risolverla. Perché non è un bug — è una feature del modello di business.
Le alternative dal basso esistono, e stanno crescendo
La buona notizia — perché una buona notizia c’è — è che la storia non finisce con la denuncia. Mentre Hashimoto valuta dove portare Ghostty e dichiara di essere «in discussione con molteplici provider, sia commerciali che FOSS», l’ecosistema delle alternative a GitHub è più vivo e politicamente consapevole che mai. E la direzione che sta prendendo dovrebbe interessare chiunque abbia a cuore la sovranità tecnologica e il software libero.
Forgejo è forse il caso più interessante, e non solo dal punto di vista tecnico. Nato nel 2022 come fork di Gitea — dopo che l’azienda dietro Gitea aveva iniziato a prendere decisioni unilaterali che la comunità non condivideva — Forgejo è oggi mantenuto sotto l’ombrello di Codeberg e.V., un’organizzazione no-profit tedesca con governance democratica. La versione 14.0, rilasciata a gennaio 2026, ha portato filtri inline per le issue, un editor web più leggero basato su CodeMirror al posto del pesante Monaco, e un’interfaccia che funziona progressivamente anche senza JavaScript. Forgejo è rilasciato sotto licenza GPL, ha rilasci di sicurezza mensili e — il dettaglio che fa tutta la differenza — non ha azionisti da soddisfare, non ha un consiglio di amministrazione che risponde a Wall Street, non ha obiettivi di fatturato trimestrale da raggiungere. Non è un clone di GitHub con un’altra skin: è un’alternativa costruita su principi radicalmente diversi.
Codeberg, la piattaforma che ospita Forgejo stesso, rappresenta la dimostrazione concreta che si può fare infrastruttura per il codice senza scopo di lucro. Gestita democraticamente dalla comunità, finanziata dalle donazioni degli utenti, Codeberg è la prova vivente che non serve un colosso da decine di miliardi di dollari per offrire un servizio di hosting del codice funzionale e affidabile. Non ha le GitHub Actions, non ha Copilot, non ha centinaia di milioni di repository e il network effect del monopolista. Ma è precisamente questo il punto: non tutto deve scalare fino all’infinito per funzionare bene. Anzi — e qui c’è dell’ironia genuina — è proprio l’ossessione per la scala che ha generato i problemi di affidabilità che hanno spinto Hashimoto alla porta.
Il segnale politico più forte, però, viene da dove meno te lo aspetti: le istituzioni. Ad aprile 2026 il governo olandese ha lanciato code.overheid.nl, una piattaforma basata su Forgejo dedicata al software open source della pubblica amministrazione. L’Open Source Program Office del Ministero degli Interni ha motivato la scelta con parole che sembrano uscite da un manifesto per la sovranità digitale: «Forgejo offre la possibilità di studiare, modificare e distribuire tutto il suo codice sorgente. Soldi pubblici, codice pubblico.» Non è un esperimento accademico — è un governo europeo che dice apertamente di non poter dipendere da GitHub per le proprie infrastrutture critiche. Che la sicurezza della supply chain del software è una questione di interesse nazionale. Che il controllo pubblico sull’infrastruttura digitale non è un capriccio da attivisti, ma una necessità strategica che non ammette più rinvii.
Questa è la parte della storia che i media tech tendono a trattare come nota a piè di pagina, quando invece è il cuore di tutto. Non si tratta solo di sviluppatori scontenti che cambiano piattaforma per dispetto: si tratta di un ripensamento strutturale di come viene gestita l’infrastruttura del software. Il self-hosting — ospitare la propria istanza di Forgejo su server propri o di una cooperativa — non è una scelta meramente tecnica: è un atto politico. Significa rifiutare la delega del proprio lavoro a un’entità che non controlli, costruire autonomia dal basso anziché chiedere il permesso dall’alto. Le cooperative digitali, le reti federate, le istanze comunitarie non sono utopie da circolo anarchico: sono strumenti che funzionano già oggi, e che hanno bisogno solo di massa critica per diventare l’alternativa concreta che troppi considerano impossibile. Ogni progetto che migra via da GitHub — ogni Ghostty, ogni libreria, ogni tool — indebolisce il monopolio di rete del colosso di Redmond. Non è una rivoluzione istantanea. È una strategia di logoramento, e storicamente è così che cambiano le infrastrutture: un pezzo alla volta, finché il vecchio sistema non regge più il confronto con ciò che cresce ai suoi margini.
Domande frequenti
Cos’è Ghostty e perché la sua uscita da GitHub è importante?
Ghostty è un emulatore di terminale open source creato da Mitchell Hashimoto, cofondatore di HashiCorp e figura di primo piano nella comunità degli sviluppatori. È un terminale veloce, GPU-accelerato e multipiattaforma con interfaccia nativa. La sua uscita da GitHub è significativa perché rappresenta la prima grande migrazione di un progetto ad alta visibilità guidato da uno degli sviluppatori più influenti dell’ecosistema, segnalando che il malcontento verso la piattaforma ha raggiunto un punto di non ritorno per molti nella comunità open source.
Dove migrerà il progetto Ghostty?
Al momento dell’annuncio del 28 aprile 2026, Hashimoto non ha rivelato la destinazione finale. Ha dichiarato di essere in trattativa con diversi provider, sia commerciali che open source. Le alternative più probabili includono Codeberg, GitLab o un’infrastruttura self-hosted basata su Forgejo. Un mirror in sola lettura resterà disponibile su GitHub per non interrompere i link esistenti e mantenere una presenza minima sulla piattaforma.
Quali sono le alternative principali a GitHub nel 2026?
Le alternative più rilevanti sono Forgejo (fork comunitario di Gitea con governance no-profit e licenza GPL), Codeberg (piattaforma no-profit basata su Forgejo), GitLab (disponibile sia come SaaS che self-hosted) e SourceHut. Per chi vuole il massimo controllo, il self-hosting di Forgejo è la scelta raccomandata dalla comunità per la trasparenza della governance e le patch di sicurezza regolari. Il governo olandese ha scelto Forgejo per la propria piattaforma di codice pubblico.
Quanto è grave la crisi di affidabilità di GitHub?
I dati ufficiali documentano oltre 65 incidenti tra febbraio e marzo 2026, con 8 interruzioni gravi che hanno portato la disponibilità sotto il 99,9% garantito ai clienti Enterprise. GitHub ha ammesso pubblicamente di non aver rispettato i propri standard, attribuendo i problemi a una crescita più rapida del previsto e a debolezze architetturali nei propri sistemi. L’azienda sta tentando di scalare l’infrastruttura di 30 volte rispetto alla capacità attuale.
Migrare un progetto da GitHub è complicato?
Spostare i repository Git è tecnicamente semplice perché Git è un sistema distribuito: basta aggiungere un nuovo remote e fare push. La vera complessità riguarda tutto ciò che circonda il codice: issue, pull request, wiki, pipeline CI/CD di GitHub Actions, pacchetti e integrazioni con servizi esterni. Forgejo e GitLab offrono strumenti di importazione, ma ricostruire i workflow automatizzati richiede lavoro significativo. È proprio questo ecosistema di servizi collaterali a generare il lock-in che rende GitHub così difficile da abbandonare.
La fuga di Ghostty da GitHub non è una storia di tecnologia. È una storia di potere — di chi possiede l’infrastruttura su cui lavoriamo, di chi decide le regole del gioco, di chi estrae valore dal lavoro di altri senza restituire nulla alla comunità che quel valore lo ha creato. Mitchell Hashimoto ha impiegato diciotto anni per arrivare a questa conclusione, e la sua onestà intellettuale nel raccontare il percorso merita rispetto — anche perché la maggior parte degli sviluppatori nella stessa situazione preferisce lamentarsi in privato e continuare a fare push su GitHub come se nulla fosse.
Ma non basta che i singoli sviluppatori migrino: serve un cambio di paradigma collettivo. Serve che la comunità open source smetta di costruire le proprie fondamenta su piattaforme che non controlla e non potrà mai controllare. Serve che le istituzioni pubbliche seguano l’esempio del governo olandese e investano in infrastrutture digitali sovrane. Serve che ci chiediamo, ogni volta che apriamo un browser e digitiamo github.com, a chi stiamo regalando il nostro lavoro e il nostro codice.
Le alternative esistono. Forgejo, Codeberg, il self-hosting: non sono perfetti, non hanno le GitHub Actions, non hanno l’effetto rete di un monopolista con centinaia di milioni di utenti. Ma sono nostri. E in un mondo dove il codice è potere, possedere l’infrastruttura su cui quel codice nasce non è un lusso da puristi — è una necessità politica che non possiamo più permetterci di rimandare.