Nell’era dell’informazione e dell’informatizzazione a dominare è, manco a dirlo, il software. Quello che permette di risolvere i vari problemi che ci si presentano, migliorando la qualità della nostra vita (risparmiando tempo e/o risorse nell’espletamento del nostro lavoro).
Verrebbe quindi quasi naturale pensare che più software esiste, e meglio è. Coi problemi abbiamo a che fare sempre, e se ne presentano continuamente di nuovi, quindi una maggior quantità potrebbe, sulla carta, permettere di soddisfare maggiori esigenze.
E la qualità? E’ anch’essa importante, ma fra un software anche di scarsa fattura e uno inesistente, la bilancia ovviamente penderebbe a favore del primo. Ma è veramente così importante il fattore “quantità“? Non sempre.
La quantità anche nel campo dell’informatica può rivelarsi addirittura controproducente. Basti pensare a una ricerca su web: se ci sono troppi risultati, individuare l’informazione che ci serve può diventare molto difficile o addirittura impossibile. Allo stesso modo, avere a disposizioni tanti software che fanno più o meno la stessa cosa può quanto meno disorientare, specialmente se si trovano sparsi in mezzo a tante altre applicazioni.
Con l’abbondanza la selezione della corretta informazione o, similmente, del corretto strumento da utilizzare diventa sempre più, a sua volta, un problema da risolvere. A maggior ragione quando di mezzo ci sono dei “cloni”, cioé dei duplicati (in genere leggermente diversi) generati da una pratica ormai molto comune che corrisponde al nome di forking.
Tecnicamente con questo termine s’intende la “biforcazione” di un progetto. In pratica, di un progetto esistente se ne fa una copia (per qualche motivo) e si lavora a delle sue modifiche. I due diventano a tutti gli effetti progetti indipendenti (che ovviamente avranno anche un nome diverso, e quasi sempre anche un repository diverso).
Molto simile a questo (ma con finalità completamente diverse) è, invece, il branching. Con ciò s’intende la creazione di un “sottoprogetto” (in gergo ramo) o, più semplicemente, di una “variazione” di un progetto, che condivide con esso buona parte del codice.
Nasce per poter sperimentare nuove soluzioni che, eventualmente, rientreranno nel ramo principale (questo è il gergo usato per indicare il progetto originale nonché “ufficiale”), se i risultati dovessero essere positivi. Infatti spesso il branch si trova nello stesso repository, proprio perché non si tratta di una nuova applicazione (“derivata”), ma è strettamente legato al progetto stesso.
Distinguere fra fork e branch è importante perché, come dicevo prima, nascono con scopi diversi. In particolare il fork genera nuovi progetti, ed è questo che interessa sottolineare: aumenta la proliferazione di soluzioni simili per uno stesso problema, andando quindi ad aumentare la “quantità”, che a sua volta è responsabile della maggior difficoltà di scelta.
Perché nascono i fork? Le motivazioni possono essere diverse: problemi di licenza, adattamento a particolari contesti / esigenze, riscrittura del codice (per obsolescenza o perché difficile da mantenere), ecc. Ma a tener banco sono sostanzialmente due cose: le discordie e le differenti visioni su come si dovrebbe andare avanti (ci sono sempre dei programmatori che sono in possesso della verità assoluta, pensano che le idee migliori sono le loro, e che ovviamente le si debba seguire, anche a costo di andare avanti da soli).
Che si possa biforcare un progetto per “discordia” fa ridere. Sembra incredibile e, soprattutto, infantile, ma non si tratta di casi isolati. L’ultima, in ordine di tempo, è stata l’accesa diatriba fra gli sviluppatori di Debian e il maintainer della libreria glibc, che si è rifiutato di accettare una patch per farla funzionare con le architetture ARM (definite “crap“, sposando in pieno lo stile di Torvalds), e che ha costretto i primi a crearne un clone.
Per tutta risposta Drepper (il maintainer) ha annunciato un fork di Debian, basato su una variante di OpenSolaris che gira sfruttando XFree86 (il vecchio gestore dell’interfaccia grafica, che è stato soppiantato qualche anno fa da X.Org per un’altra lite, questa volta per questioni di licenze). Sembra una zuffa fra scolaretti delle elementari, ma è la triste realtà.
Tutto ciò porta a un’evidente ed inutile spreco di risorse, che rappresenta la causa prima (a mio avviso) dei problemi che il forking crea all’open source. Un quantità enorme di “forza lavoro” che potrebbe, invece, essere impiegata in maniera molto più utile migliorando la qualità del codice esistente o realizzando le applicazioni che mancano alla comunità open source e, in particolare, a certe piattaforme / sistemi operativi.
Faccio un esempio pratico: le interfacce grafiche. Quanti conoscono lo stato dell’arte di quelle (perché sono tante) disponibili per s.o. open source? Sono paragonabili a quella che Apple ha realizzato per MacOS X? Eppure, ironia della sorte, OS X si fonda su due progetti open source: il microkernel Mach e FreeBSD, che concorrono alla realizzazione del kernel Darwin (anch’esso rilasciato come open source).
La migliore e più evoluta interfaccia grafica è closed, ma gira su un s.o. open source: sembra quasi uno scherzo di natura. Ma anche questa è la (non troppo triste per gli utenti Apple) realtà. Unire le forze degli sviluppatori open source per fornire i s.o. open source di un’interfaccia simile non sarebbe meglio?
Ricordiamoci, infine, che il software rimane la carta vincente per un qualunque s.o., ed è questo il motivo per cui Windows continua a dominare il mercato: la disponibilità di una multitudine di applicazioni che coprono campi vastissimi.
E allora, ha senso che gli stessi sviluppatori di Debian abbiano addirittura “forkato” ben quattro progetti (FireFox, Thunderbird, SeaMonkey, e Sunbird) per una banalissima questione di nomi e loghi? O che esistano una miriade di browser alternativi, editor di testo, IDE per lo sviluppo di applicazioni, package manager, ecc. ecc. ecc.?
Unire le forze per realizzare singole applicazioni (magari modulari per renderle più flessibili e “personalizzabili”) per coprire le stesse esigenze risulta così difficile? Evidentemente, dato il proliferare di applicazioni, librerie, distro et similia, è proprio così…
