Perché Fedora non genera distro derivate come Ubuntu e Arch?

Negli ultimi due decenni il panorama delle distribuzioni Linux derivate si è polarizzato attorno a tre famiglie principali: Debian/Ubuntu, Arch Linux e, in misura minore, Fedora. Se oggi è frequente imbattersi in nuovi progetti basati su Debian o Arch, è molto più raro vedere nascere e soprattutto resistere distribuzioni derivate da Fedora. Eppure, fino ai primi anni 2000, la situazione era ben diversa: Red Hat Linux (antenato diretto di Fedora) era una delle basi più diffuse per progetti indipendenti. Cos’è successo in un ventennio?

Alcuni rami hanno prodotto veri e propri ecosistemi paralleli: Debian con Ubuntu, Mint, MX Linux, pureOS; Arch con Manjaro, EndeavourOS, Garuda. Fedora, pur essendo una distribuzione di primo piano e tecnicamente avanzata, non ha generato un numero paragonabile di fork indipendenti. Fuori da progetti specialistici come Qubes OS, Berry Linux o il Network Security Toolkit, la maggior parte delle varianti Fedora rimane nell’alveo degli spins ufficiali (vedere più avanti) o di “remix” strettamente integrati.

Il periodo d’oro delle derivate Red Hat (1997–2003)

Prima del 2003, Red Hat Linux era considerata una base solida e affidabile, tanto che progetti come Mandrake Linux/Mandriva, PCLinuxOS, ROSA, Mageia, Fuduntu e molti altri ne adottarono il codice come fondamenta.

Le statistiche mostrano che, nel tempo, sono stati censiti oltre 90 progetti basati su Fedora o Red Hat Linux, più del doppio rispetto a quelli basati su Arch. Tuttavia, la percentuale di distribuzioni ancora attive oggi è molto bassa: circa 13% per Fedora, contro il 35% per Ubuntu e oltre il 50% per Arch.

Il cambiamento del 2003: dalla stabilità all’innovazione continua

Come accennato in precedenza, l’anno spartiacque è proprio il 2003. Fu allora che Red Hat decise di interrompere la distribuzione Red Hat Linux come sistema desktop, concentrare gli sforzi commerciali su Red Hat Enterprise Linux (RHEL) e creare Fedora come progetto comunitario, con l’obiettivo di sperimentare tecnologie innovative e fare da “laboratorio” per RHEL.

Il cambio di strategia ebbe conseguenze profonde: Fedora divenne più instabile e soggetta a cambiamenti rapidi, introducendo nuove tecnologie (SELinux, cambi di package manager, formati di pacchetti sperimentali) e perdendo parte dell’attrattiva come base per progetti che cercavano un fondamento stabile e di lungo termine.

Fedora è famosa per adottare tecnologie cutting-edge, all’avanguardia, moderne, innovative e avanzate disponibili, molto prima di altre distribuzioni:

• systemd come init system predefinito quando ancora era controverso.
• Wayland come server grafico di default.
• Btrfs come filesystem standard su Workstation.
• SELinux attivo e in modalità enforcing.

Questa spinta innovativa è ideale per sviluppatori e tester, ma meno per chi cerca di congelare un set di tecnologie per anni. Debian si muove lentamente; Arch si muove continuamente ma con una base minimale. Fedora, con i suoi cambi “a scatti” semestrali, si colloca in una via di mezzo che non favorisce fork indipendenti.

Un ciclo di rilascio poco attraente per chi mantiene derivate

Il modello di sviluppo di Fedora prevede rilasci ogni circa 6 mesi e un supporto di soli 13 mesi per ogni versione. Si tratta di una soluzione che colloca Fedora in una posizione intermedia scomoda:

• Troppo breve per chi cerca stabilità e LTS (Long Term Support), come in Debian e Ubuntu LTS.
• Troppo vincolata a rilasci completi per chi preferisce un flusso di aggiornamenti continuo (come Arch).

Per chi mantiene una distribuzione derivata, l’approccio applicato da Fedora implica la ricostruzione e il testing frequenti di pacchetti e immagini, non poter contare su una finestra di supporto estesa, affrontare continui allineamenti di compatibilità, con costi di manutenzione elevati.

Fedora, incubatore per Red Hat Enterprise Linux (RHEL)

Fedora è ancora oggi la base di partenza dove vengono sviluppate e testate nuove funzionalità integrate in CentOS Stream e, indirettamente, in RHEL.

CentOS Stream è una distribuzione Linux che si colloca tra Fedora e RHEL: è una sorta di “preview” o “rolling release” delle prossime versioni di RHEL.

Lo storico CentOS nasceva come un progetto indipendente che ricompilava il codice sorgente di RHEL per offrire una distribuzione gratuita, stabile e compatibile a livello binario con RHEL. Per molti anni, CentOS “classico” era molto popolare proprio perché forniva un’alternativa gratuita a RHEL, usata da aziende, sviluppatori e hosting provider. Nel 2014, Red Hat ha acquisito il progetto CentOS e lo ha mantenuto come distribuzione libera e stabile.

A dicembre 2020, Red Hat ha annunciato una svolta importante: la fine dello sviluppo di CentOS come lo conoscevamo. Al suo posto, Red Hat ha spinto CentOS Stream, che non è più una copia “stabile” di RHEL, ma una distribuzione a sviluppo continuo che anticipa le modifiche di RHEL.

L’iniziativa ha creato confusione e frustrazione, perché CentOS Linux era molto usato in ambienti di produzione per la sua stabilità e compatibilità con RHEL, mentre CentOS Stream è più “dinamico” e meno stabile.

Distribuzioni come Rocky Linux e AlmaLinux sono nate proprio per colmare il vuoto lasciato da CentOS, offrendo un sistema stabile e compatibile a livello binario con RHEL, come era CentOS prima. Queste distribuzioni sono diventate molto popolari soprattutto tra chi vuole stabilità senza pagare una licenza Red Hat.

Oggi, quindi, chi vuole una “Fedora stabile” sceglie di basarsi direttamente su RHEL o su progetti alternativi come Rocky Linux e AlmaLinux, evitando il continuo inseguimento delle versioni Fedora.

L’effetto “spins” e il paradosso della visibilità

Fedora offre un’infrastruttura ufficiale per creare spins (KDE, Xfce, Cinnamon, i3, LXQt,…) e labs per scenari specifici (design, sicurezza, robotica,…): sono tutte varianti ufficiali con desktop environment e tool diversi, integrate e distribuite direttamente attraverso i canali Fedora.

Le conseguenza sono evidenti: vi è una ridotta necessità di creare progetti “fork” con una propria identità; inoltre, la “varietà interna” di Fedora è percepita come un unico ecosistema, invece di tanti progetti separati (come accade per Ubuntu e le sue derivate).

Di fatto, molte iniziative che in ambiente Debian/Ubuntu o Arch si tradurrebbero in distribuzioni autonome restano sotto il cappello Fedora, riducendo il numero di prodotti Fedora-based che appaiono come progetti indipendenti.

Licenze e repository: un ecosistema più rigido

Fedora applica una politica di licenze molto restrittiva:

• Nessun software proprietario.
• Nessun pacchetto soggetto a brevetti (come codec multimediali brevettati negli USA).
• Dipendenza da repository di terze parti (RPM Fusion, ecc.) per componenti non liberi.

Questo complica la vita a chi sviluppa una derivata orientata all’utente finale, specialmente se vuole offrire supporto “out of the box” per driver, codec e software proprietario, come invece fanno molte derivate di Ubuntu.

Il marchio “Fedora”, inoltre, è tutelato da Red Hat. Chi vuole rilasciare una derivata deve rispettare linee guida specifiche e, in certi casi, rinunciare a nomi e loghi originali. La policy “Fedora Remix” è permissiva, ma richiede comunque un minimo di impegno: non è un ostacolo insormontabile, ma per i progetti hobbistici può essere un deterrente.

L’esempio Fedora Asahi Remix

Asahi Linux è un progetto open source nato con l’obiettivo di portare Linux in modo nativo e completo sui Mac con processori Apple Silicon, come M1 e M2. Si basa principalmente su Arch Linux, una distribuzione leggera e altamente personalizzabile, su cui il team Asahi integra patch e driver specifici per supportare l’hardware Apple Silicon, che fino a poco tempo fa era praticamente esclusivo di macOS.

Fedora Asahi Remix, invece, è una variante di Fedora creata per offrire un’esperienza Linux più stabile e orientata a utenti che preferiscono questa distribuzione. Pur includendo anch’essa i driver e le modifiche necessarie per Apple Silicon sviluppate da Asahi, Fedora Asahi Remix mantiene il ciclo di rilascio regolare e le caratteristiche tipiche di Fedora.

La principale differenza tra i due progetti riguarda quindi la base: Arch Linux per Asahi Linux, che punta su flessibilità e personalizzazione; Fedora per Fedora Asahi Remix, che privilegia stabilità e aggiornamenti regolari. Entrambi rappresentano soluzioni valide per utilizzare Linux su Mac Apple Silicon, ma si rivolgono a utenti con esigenze e preferenze diverse.

La concorrenza di Ubuntu e Arch: due modelli vincenti

Inutile dire, poi, che Ubuntu ha conquistato il desktop consumer, grazie a facilità d’uso, ampia compatibilità hardware e una community molto attiva. Arch si è imposto come scelta per utenti esperti e sviluppatori, grazie a un modello rolling release, pacchetti aggiornati rapidamente e documentazione eccellente. Lo script di installazione semi-automatica di Arch ha poi contribuito ad attirare anche tanti utenti che non sono disposti a configurare un sistema operativo proprio da zero.

Ubuntu e Arch hanno quindi occupato due poli opposti, lasciando Fedora in una fascia intermedia, troppo avanzata per i principianti, un po’ troppo statica per gli utenti evoluti e i professionisti.

Il nuovo paradigma: Fedora immutabile e containerizzata

Negli ultimi anni Fedora ha introdotto il modello immutabile (Silverblue, Kinoite, Sericea) e l’uso di bootc images per server e desktop. In questo scenario:

• La base di sistema è costante e atomica.
• Le applicazioni arrivano via Flatpak, Toolbox o Distrobox.
• I progetti possono basarsi su container preconfezionati senza ricompilare l’intera distribuzione.

L’approccio riduce ulteriormente il concetto classico di “fork di una distro” e sposta il valore aggiunto nello strato applicativo.

Opportunità mancate o scelta strategica?

Paradossalmente, proprio la solidità organizzativa e la stretta integrazione interna che rendono Fedora coerente e controllata come progetto comunitario, la rendono meno fertile come “piattaforma madre” per nuove distribuzioni.

A Fedora non “manca” un ecosistema di fork: semplicemente, il progetto assorbe molte varianti al suo interno e non scoraggia i remix ufficiali. Il risultato è un ecosistema coeso, ma meno diversificato in termini di branding indipendente.

In prospettiva, il modello immutabile/container potrebbe rendere i fork classici ancora meno rilevanti, favorendo invece “metadistribuzioni” come Bazzite o Universal Blue, dove il concetto di fondamenta del sistema operativo è certamente secondario rispetto all’esperienza utente finale.