In questo articolo Indice dei contenuti 3 sezioni
Kagi ha deciso di fermare lo sviluppo diretto di Orion su Linux e Windows, e il codice delle due versioni diventerà open source. La notizia va oltre la cancellazione di un paio di port, perché mostra quanto sia complicato oggi costruire e mantenere un browser davvero indipendente senza appoggiarsi a Chromium. L’azienda lo ha spiegato apertamente nell’annuncio del 2 ottobre 2026. Orion è nato da una squadra di pochissimi sviluppatori che ha scelto di proposito “la strada difficile” evitando un fork di Chromium. Seguire insieme macOS, iOS, Linux e Windows è diventato semplicemente troppo per una struttura così piccola.
Cosa cambia per Orion su Linux e Windows
Il piccolo team interno di Kagi concentrerà ora tutte le energie sulle versioni per macOS e iOS. Su Linux il browser era già arrivato alla beta pubblica e continuerà a funzionare, ma dal 2 ottobre non riceve più aggiornamenti dall’azienda, che anzi sconsiglia di usarlo come browser principale. Su Windows il lavoro era meno avanzato. Era prevista un’uscita entro la fine del 2026 che a questo punto non arriverà, almeno non da parte di Kagi.
Il codice dei due progetti sarà reso pubblico e l’azienda ha già contattato fondazioni e organizzazioni del mondo open source per capire se qualcuno sia disposto a raccoglierne l’eredità. Ulteriori dettagli sono attesi entro 30 giorni dall’annuncio.
Visto da fuori un browser sembra una cosa semplice, con una barra degli indirizzi, qualche scheda, la cronologia e i preferiti. La parte complessa però sta quasi tutta sotto la superficie. Il programma esegue di continuo codice che arriva da fonti non affidabili e deve interpretare HTML e CSS, compilare JavaScript, far girare WebAssembly, decodificare immagini e video, gestire font, WebSocket, WebRTC, Service Worker, IndexedDB, notifiche, videocamere e microfoni, oltre a decine di API che dialogano con il sistema operativo.
Perché Chromium semplifica la vita e WebKit no
Chi parte da Chromium non riceve soltanto Blink, il motore che disegna le pagine, e V8, quello che esegue JavaScript. Eredita un’intera infrastruttura multipiattaforma già capace di gestire processi, rete, GPU, sandbox, codec, certificati, storage e aggiornamenti su Windows, macOS e Linux. Non a caso domina buona parte del mercato desktop attraverso Chrome, Edge, Brave, Vivaldi, Opera e tanti prodotti minori. Costruire Brave o Vivaldi non è certo banale, ma si parte da una base che Google e una grande comunità curano ogni giorno, e si può dedicare più tempo a interfaccia, privacy e funzioni distintive.
Orion ha invece scelto WebKit, il motore maturo usato da Safari e da altre applicazioni Apple. Kagi crede che il Web non debba dipendere da un solo motore e dalle decisioni di una sola grande organizzazione. Una posizione comprensibile che però ha un costo tecnico alto. Su Linux esiste WebKitGTK, che integra WebKit con GTK ed è alla base di browser come GNOME Web. Gestisce già aspetti molto difficili come il rendering accelerato, il compositing e i processi separati, mentre per la parte multimediale entra in gioco GStreamer.
Tra incorporare un motore e avere un browser completo però c’è parecchia strada. Servono l’interfaccia, la gestione di schede e finestre, profili, download, password, permessi, scorciatoie, accessibilità, stampa e aggiornamenti. Poi arrivano le stranezze di ogni piattaforma. Quello che funziona su macOS non passa da solo a Windows e Linux porta con sé ambienti desktop diversi, Wayland, X11, vari sistemi audio e diversi metodi di distribuzione.
Il peso tecnico dietro la concentrazione del mercato
La vicenda aiuta a leggere in modo diverso il predominio di Chromium. Non dipende soltanto da scelte commerciali ma anche da una ragione pratica, perché quella base riduce moltissimo il lavoro che un produttore deve sostenere da solo. Mozilla mantiene Gecko grazie a un’organizzazione dedicata a Firefox e Apple spinge WebKit con Safari e le proprie piattaforme. Per una realtà delle dimensioni di Kagi portare un browser WebKit su quattro sistemi operativi è un impegno di tutt’altra scala.
Rendere open source il codice è con ogni probabilità il modo migliore per non disperdere il lavoro fatto, ma non risolve tutto. Un eventuale fork comunitario dovrà seguire l’evoluzione di WebKit, integrare in fretta le patch di sicurezza, mantenere l’infrastruttura di compilazione, pubblicare release per più architetture e verificare di continuo la compatibilità con i siti. Su Windows bisognerà anche completare un port che Kagi non era ancora riuscita a portare alla distribuzione pubblica.
Fonte: TecnoAndroid
