Kagi si arrende con Orion su Linux e Windows: il codice diventerà open source

La rinuncia di Kagi a sviluppare direttamente Orion per Linux e Windows racconta qualcosa di più interessante della semplice cancellazione di due versioni di un browser. Mostra quanto sia diventato difficile costruire e mantenere, nel 2026, un browser realmente indipendente senza prendere Chromium come base.

Kagi lo ammette apertamente nell’annuncio del 2 ottobre: Orion nasce da una squadra composta da appena una manciata di sviluppatori e l’azienda ha scelto consapevolmente “la strada difficile“, evitando un fork di Chromium. Portare avanti contemporaneamente macOS, iOS, Linux e Windows ha infine superato ciò che una struttura di quelle dimensioni poteva sostenere.

Chromium domina buona parte del mercato dei browser desktop attraverso Chrome, Edge, Brave, Vivaldi, Opera e numerosi prodotti minori. Scegliere Chromium non significa semplicemente utilizzare Blink per disegnare le pagine: significa ereditare una gigantesca infrastruttura multipiattaforma già capace di gestire processi, rete, GPU, sandbox, codec, WebRTC, storage, certificati, aggiornamenti e gran parte delle complessità che separano un motore Web da un browser realmente utilizzabile. Orion ha invece scelto WebKit. Proprio qui la vicenda diventa tecnicamente interessante.

Kagi ferma Orion su Linux e Windows

Kagi ha annunciato che non svilupperà più direttamente Orion per Linux e Windows: entrambi i progetti diventeranno open source, mentre il piccolo team interno concentrerà le proprie risorse sulle versioni macOS e iOS.

Per quanto riguarda Linux, Orion aveva già raggiunto la beta pubblica: il browser continuerà a funzionare, ma dal 2 ottobre non riceve più aggiornamenti da parte di Kagi e l’azienda stessa sconsiglia di utilizzarlo come browser principale. Su Windows il progetto era meno maturo: Kagi prevedeva una release entro la fine del 2026, che a questo punto non arriverà, almeno non per mano dell’azienda.

Il codice dei due port sarà pubblicato e Kagi ha già contattato fondazioni e organizzazioni open source per capire se qualcuno voglia assumersene la gestione.

Guardando un browser dall’esterno è facile sottovalutarne la complessità. Ci sono una barra degli indirizzi, alcune schede, cronologia, preferiti e una superficie nella quale appaiono le pagine. La parte difficile vive quasi tutta sotto.

Un browser esegue continuamente codice proveniente da soggetti non affidabili: deve interpretare HTML e CSS, compilare JavaScript, eseguire WebAssembly, decodificare immagini e video, gestire font, comunicazioni WebSocket, WebRTC, Service Worker, IndexedDB, notifiche, videocamere, microfoni e decine di API che interagiscono in qualche modo con il sistema operativo.

Perché Chromium rende tutto molto più semplice

Chromium offre un vantaggio enorme a chi vuole realizzare un nuovo browser: non fornisce soltanto Blink, il motore che interpreta e visualizza HTML e CSS, e V8, il motore che esegue JavaScript. Il progetto comprende già gran parte dell’architettura necessaria a creare un prodotto desktop completo su Windows, macOS e Linux.

Chi sviluppa un browser Chromium può quindi concentrare molto più lavoro su interfaccia, privacy, servizi, sincronizzazione e funzioni distintive, lasciando alla base comune una quantità impressionante di problemi tecnici. Non significa che costruire Brave, Edge o Vivaldi sia facile; significa però partire da un software che Google e una grande comunità mantengono quotidianamente sulle principali piattaforme.

La situazione di Orion è diversa. Kagi vuole evitare Chromium anche per una ragione precisa: ritiene importante che il Web non debba e non possa dipendere da un unico motore e dalle decisioni di una sola grande organizzazione. La posizione è comprensibile, ma comporta un prezzo tecnico elevato.

Cos’è e come funziona WebKit

WebKit è un motore Web maturo, utilizzato da Safari e da altre applicazioni Apple; dispone inoltre di port specifici per altre piattaforme. Su Linux esiste WebKitGTK, che integra WebKit con GTK e costituisce la base di browser come GNOME Web.

WebKitGTK gestisce già problemi molto complessi: la documentazione descrive, per esempio, rendering accelerato e non accelerato, compositing, processi Web separati e trasferimento dei frame verso il processo dell’interfaccia. Con il rendering accelerato può utilizzare buffer DMA-BUF per consegnare al processo UI le immagini prodotte dal processo Web; la parte multimediale coinvolge invece componenti come GStreamer.

Tutto ciò riduce enormemente il lavoro rispetto a scrivere un motore da zero, ma resta una differenza sostanziale fra incorporare WebKit e disporre di un browser desktop completo, rifinito e omogeneo su più sistemi operativi.

Bisogna costruire l’interfaccia, gestire schede e finestre, profili, download, password, sessioni, permessi, integrazione con il desktop, scorciatoie, drag and drop, protocolli esterni, associazioni dei file, accessibilità, stampa e aggiornamenti. Poi arrivano le peculiarità della singola piattaforma. Ciò che funziona su macOS non si trasferisce automaticamente a Windows; Linux, a sua volta, porta con sé GTK, differenti desktop environment, Wayland, X11, sistemi audio, portali e diversi metodi di distribuzione.

Orion mostra perché Chromium continua a conquistare browser

La vicenda di Kagi aiuta infine a leggere sotto una luce diversa la concentrazione del mercato intorno a Chromium.

È facile attribuirla soltanto alle scelte commerciali delle aziende, ma esiste anche una ragione tecnica: partire da Chromium riduce enormemente la quantità di infrastruttura che un produttore deve costruire e mantenere autonomamente.

Scegliere un motore differente significa preservare la diversità tecnologica del Web, ma obbliga anche ad affrontare una montagna di lavoro che difficilmente una piccola azienda può sostenere su quattro sistemi operativi.

Mozilla può mantenere Gecko grazie a un’organizzazione dedicata allo sviluppo di Firefox; Apple può spingere WebKit attraverso Safari e le proprie piattaforme. Per un’azienda delle dimensioni di Kagi, portare un browser WebKit completo contemporaneamente su macOS, iOS, Linux e Windows rappresenta un impegno di tutt’altra scala.

L’open source non risolve automaticamente il problema

Pubblicare il codice di Orion per Linux e Windows è probabilmente la soluzione migliore per evitare che il lavoro svolto sinora finisca abbandonato.

Kagi promette ulteriori dettagli entro 30 giorni dall’annuncio del 2 ottobre 2026 e dichiara di aver già cercato possibili organizzazioni interessate alla gestione futura.

L’eventuale fork comunitario di Orion dovrà comunque confermare WebKit e seguire le sue evoluzioni, integrare tempestivamente le patch di sicurezza, mantenere l’infrastruttura di compilazione, produrre release per più architetture, gestire regressioni e controllare continuamente la compatibilità con i siti. Su Windows bisognerà inoltre completare un port che Kagi non aveva ancora portato alla distribuzione pubblica.