Il 18 agosto 2026 Modular ha rilasciato sotto licenza Apache 2.0 l’intero linguaggio Mojo. Non solo la libreria standard, già aperta nel 2024, e nemmeno i soli kernel di MAX resi disponibili l’anno successivo. Questa volta sono finiti su GitHub il compilatore e l’intera catena di strumenti, cioè le parti che contavano più di tutto.
La promessa risaliva al maggio 2023, quando Chris Lattner, l’uomo dietro LLVM e Swift, presentò Mojo come il linguaggio capace di mettere d’accordo la leggibilità di Python e le prestazioni del codice di sistema. Tre anni e qualche slittamento dopo, quella promessa è stata mantenuta in un momento tutt’altro che casuale. Sei giorni prima Mojo aveva raggiunto la versione 1.0, e venti giorni prima Qualcomm aveva completato l’acquisizione di Modular per circa 3,9 miliardi di dollari in azioni.
Mojo nasce per erodere il vantaggio che CUDA garantisce a NVIDIA da oltre quindici anni. Alla ModCon 2026 Qualcomm ha anche annunciato il supporto nativo a Windows, sviluppato insieme al team della piattaforma Microsoft. Fino a oggi Mojo richiedeva Linux, macOS o WSL, e per un linguaggio che ambisce a un pubblico ampio era un limite non trascurabile.
Qualcomm ha aperto al pubblico anche Modular Cloud, con endpoint condivisi compatibili con l’API di OpenAI, deployment dedicati e tariffazione a token. Tra i clienti citati compare MiniMax, che vi esegue il modello M3 con finestra di contesto da un milione di token.
Cosa è finito nel repository
L’apertura riguarda il cuore del progetto. Chiunque può clonare il monorepo di Modular, compilare il compilatore con Bazel ed eseguire un programma senza toccare un binario precompilato.
git clone https://github.com/modular/modular.git
cd modular
./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo
Chi vuole lavorare solo sulla libreria standard può passare a --config=prebuilt-mojo ed evitare una ricompilazione completa, mentre ./bazelw test --config=build-mojo mojo/stdlib/test/... manda in esecuzione la suite di test. La licenza Apache 2.0 significa inoltre che nessuno deve chiedere permessi per fare un fork, portare Mojo su una piattaforma non prevista o costruirci sopra un prodotto commerciale.
Resta però una distinzione da tenere a mente, perché aperto non è sinonimo di governato in modo aperto. Il progetto continua a funzionare con un modello in cui le pull request esterne sul compilatore non vengono accolte liberamente, un po’ come accade con SQLite.
La libreria standard racconta una storia diversa e più incoraggiante, con quasi duecento contributori, oltre 1.100 pull request e più di 200.000 righe di codice toccate, ma quella era già aperta da due anni. Anche MAX, il framework di inferenza su cui poggia buona parte del valore commerciale dell’azienda, non è transitato ad Apache 2.0.
Ha perso i vincoli d’uso sui dispositivi ed è diventato source-available, accompagnato da un programma rivolto a produttori hardware, fornitori di modelli e operatori cloud. È un avanzamento ma non un’apertura completa, perché stabilisce chi può mettere le mani sul motore e chi si limita a guardarlo.
Una versione Mojo 1.0 che stabilizza il contratto
Il numero di versione ha generato qualche fraintendimento. Mojo 1.0 non dichiara il linguaggio finito, dichiara che le API esplicitamente marcate come stabili seguiranno il versionamento semantico e non romperanno il codice sorgente esistente. È una garanzia contrattuale, non un certificato di completezza, e arriva dopo tre anni in cui aggiornare la toolchain significava spesso riscrivere pezzi di programma.
L’assenza di un’ABI stabile (Application Binary Interface, cioè l’interfaccia binaria di un’applicazione) è la voce che pesa di più, perché senza di essa distribuire librerie precompilate resta complicato e ogni aggiornamento del compilatore obbliga a ricompilare l’intera catena.
Mancano inoltre un debugger e un profiler all’altezza, e chi arriva da ecosistemi maturi se ne accorge subito. Va riconosciuto, però, che nessuna di queste lacune viene nascosta, dato che la documentazione le elenca senza giri di parole. Mojo 1.0 è pronto per l’uso in produzione su carichi ben delimitati, molto meno per diventare il fondamento di un’intera infrastruttura software aziendale.
Perché un produttore di chip compra un compilatore
L’operazione Qualcomm-Modular è stata insolitamente rapida, con accordo firmato il 21 giugno, annuncio pubblico il 24 e chiusura il 29 luglio. Cinque settimane in tutto, per circa 3,9 miliardi di dollari. Chris Lattner è diventato executive vice president per il software AI avanzato, e Modular oggi compare nei propri documenti come “A Qualcomm Company”.
Per afferrare la logica dell’acquisto bisogna guardare i numeri messi sul tavolo davanti agli investitori, ovvero 40 miliardi di dollari di ricavi non legati agli smartphone entro l’anno fiscale 2029, di cui oltre 15 miliardi provenienti dal data center. È un salto notevole per un’azienda che il mercato associa ancora ai processori mobili.
Vendere acceleratori nel data center non è un problema di transistor, è un problema di software. Chi compra hardware per l’AI compra soprattutto la certezza che il proprio stack esistente girerà senza riscritture, e quella certezza oggi la vende NVIDIA insieme a CUDA.
Un compilatore aperto è la via più economica per provare ad attaccare quel problema. Se Mojo fosse rimasto proprietario e legato al silicio di un solo fornitore, nessun concorrente lo avrebbe adottato e il linguaggio sarebbe scivolato nella nicchia. Distribuito sotto Apache 2.0, invece, può essere usato anche da chi compete direttamente con Qualcomm.
Oltre alle GPU NVIDIA e AMD già supportate, la piattaforma copre AWS Trainium, le TPU di Google, il Cloud AI 100 Ultra di Qualcomm e il nuovo Dragonfly, ancora in fase di abilitazione. La prova vera sarà la disponibilità ad accettare e mantenere ottimizzazioni scritte per hardware concorrente.
Conviene metterci le mani adesso?
Dipende da cosa devi farci. Se il tuo lavoro consiste nello scrivere kernel per acceleratori o nell’ottimizzare inferenza su hardware eterogeneo, oggi hai un motivo in più per provarlo. La licenza non ti vincola a nessuno, il compilatore è ispezionabile e la garanzia di stabilità sulle API riduce il rischio che il codice scritto questo trimestre smetta di compilare al prossimo aggiornamento. Se invece speravi in un rimpiazzo indolore di Python, conviene ridimensionare le aspettative.
Il progetto ha ufficialmente abbandonato l’ambizione di diventare un superset del linguaggio. Mojo ne eredita la sintassi e l’interoperabilità nelle due direzioni, quindi puoi chiamare Python da Mojo e Mojo da Python, ma non la compatibilità. Il codice esistente non si trasferisce da solo, e la stessa azienda suggerisce di appoggiarsi a strumenti di assistenza al porting, il che è di per sé un’ammissione della distanza da colmare.
C’è poi la questione dell’ecosistema. Le librerie native esistono e crescono, tra cui framework HTTP, parser JSON e tentativi di equivalenti a NumPy, ma il confronto con quello che trovi in Python o in Rust non regge ancora.
Una scelta sensata per chi programma acceleratori
Modular è nata nel 2022 su un’ipotesi che allora sembrava azzardata, cioè che l’AI non sarebbe rimasta per sempre su un solo tipo di silicio. Quattro anni e mezzo dopo, quella scommessa è stata comprata per 3,9 miliardi di dollari da un’azienda che ha bisogno esattamente di quel presupposto per entrare nel data center. L’apertura di Mojo è la conseguenza logica di entrambe le cose. Non un gesto di generosità, ma il riconoscimento che uno strumento pensato per unificare hardware diverso non può appartenere a un solo produttore.
Nel frattempo la situazione per chi sviluppa è migliorata in modo tangibile. Garanzie di stabilità, un compilatore che si può leggere e modificare, il supporto a Windows in arrivo e una lista di acceleratori che si allunga. La domanda giusta non è più se Mojo sia interessante, ma se il suo ecosistema crescerà abbastanza in fretta da giustificare l’investimento di chi lo adotta oggi. I prossimi dodici mesi diranno praticamente tutto.
