Che cos'è la "forcella"?

Negli ultimi due giorni probabilmente hai sentito la parola "fork" più volte di quante tu possa contare. Facebook lo ha biforcato (anche se non lo ha fatto), Amazon lo ha biforcuto, il team Chrome ha biforcuto l'intero Web, e così via e così via. Mentre tutti parlano di chi sta biforcando chi, nessuno si prende la briga di spiegare esattamente cosa sia il biforcazione e perché così tante persone abbiano un problema.

Forking, o frantumazione, ha avuto un po 'di cattiva reputazione circa 20 anni fa, poiché tendeva a dividere gli sviluppatori in fazioni separate che non condividevano il codice tra loro. Ai tempi di cose come la divisione di Gnu-Emacs / XEmacs, questo era importante perché non c'erano quasi altrettante persone in grado di lavorare su questi grandi progetti open source e avere due rami o forchette significava che ci voleva più tempo per aggiungere caratteristiche e problemi relativi ad entrambi i lati. In alcuni casi ciò accade ancora, ne sono certo, ma per la maggior parte ci sono molti sviluppatori che possono riempire il vuoto lasciato da coloro che hanno una visione separata e sbarreranno il codice per seguirlo. Ma alcune persone non dimenticano mai, e lo stigma attaccato ai forks forks viene tramandato. Detto questo, non possiamo pretendere che le forcelle cattive non accadano. Dobbiamo solo guardare oltre l'atto stesso prima di prendere le nostre decisioni.

So che alcuni di voi là fuori sanno cosa significa tutto questo e stanno solo cercando di ignorare tutto il rumore, ma per molti è confuso. Proviamo a risolverlo.

Che cos'è un software fork e in che modo influisce su Android?

Pensa ad Android un mucchio di codice. Esistono due parti: le parti open source, che è AOSP, e le parti proprietarie che Google mantiene su se stesso. Se qualcuno vuole prendere Google Android e apportare modifiche ad esso, scaricherà il codice da utilizzare come base e formerà il proprio progetto con esso. Samsung lo fa, HTC lo fa e il tuo sviluppatore ROM preferito potrebbe farlo. Ogni volta che qualcuno prende il codice esistente e avvia un progetto indipendente (che è una distinzione importante) basato su di esso, ha creato un fork. Molti sviluppatori controlleranno il codice, ne modificheranno parti, quindi invieranno le loro modifiche a monte nella loro interezza, il che non è un fork.

Amazon ha sollevato alcune sopracciglia quando ha costretto Android a costruire il sistema operativo per la linea Kindle Fire. Ma dal lato open source delle cose, non era diverso da quello che Motorola ha fatto con Cliq, o HTC ha fatto con Hero - o quello che Samsung fa ora per i dispositivi della serie Galaxy. Ecco come funzionano i grandi progetti open source. Ogni fornitore (tranne forse Amazon) lavora con le stesse nozioni di base, probabilmente segnalando bug e inviando correzioni a monte man mano che procede, per creare la propria interpretazione del prodotto finale.

Facebook non ha rovesciato Android. Ha utilizzato il sistema di intenti Android (un modo in cui le app possono lavorare tra loro e condividere su Android) e ha creato una grande app che include anche una casa sostitutiva. All'interno della loro sandbox, possono fare quello che vogliono o devono fare e, purché utilizzino gli intenti di Android, possono comunicare con il resto del sistema. Se si desidera ottenere supporto tecnico, HTC potrebbe aver forzato Android a funzionare meglio con Facebook Home nell'HTC First, poiché menziona alcune modifiche apportate per una migliore compatibilità. Sapremo di più su ciò che hanno fatto quando il telefono esce.

In ogni caso, il codice di fork non è sempre una brutta cosa e non merita tutta la negatività che senti quando qualcuno lo menziona. L'analista del settore Stephen O'Grady lo riassume bene, penso:

Vale la pena ricordare, tuttavia, che dal punto di vista del cliente, le forcelle o le varianti non sono universalmente cattive. Mentre le varie versioni di Android possono rappresentare decisioni di progettazione sfortunate da parte dei fornitori responsabili, le applicazioni sono nella stragrande maggioranza dei casi compatibili da dispositivo a dispositivo, assumendo l'equivalenza della versione.

Avere app compatibili da dispositivo a dispositivo è il motivo per cui è stato progettato Android. Il codice forking non lo rende impossibile. Ma altre cose fanno.

L'altro lato del fork di Android

In Cina puoi acquistare un telefono da un operatore che esegue Android, ma non ha servizi Google? Proprio come Kindle Fire, è costruito con il codice Android di Google (a volte non modificato) ma non è stato inviato e testato per essere compatibile con Google e include elementi come Gmail o Google Play. Quelle app e i file di sistema assortiti che devono eseguire, non sono open source e non puoi semplicemente includerli senza il permesso di Google.

Oltre a un'esperienza utente "diversa" (non ho intenzione di dire che è "peggio", solo diversa) senza queste app, possono apparire e sentire proprio come un telefono Android acquistato da Verizon o AT&T. Possono anche apparire e sentirsi molto diversi, come ha fatto Amazon. Ma nulla di tutto ciò è dovuto al fatto che hanno eliminato il codice Android di Google: è stata una decisione consapevole di non creare un dispositivo "certificato" di Google. Google presenta Android come piattaforma applicativa e set di framework di app. Non includere le applicazioni di servizio di Google non ne fa meno una piattaforma per app. Naturalmente, immaginiamo che Google preferisca che tutti i dispositivi basati su Android e Android utilizzino i servizi di Google, ma non esiste una regola rigida che dice che un fornitore deve farlo.

Realizzare dispositivi senza le app di Google non ha nulla a che fare con il fork di Android. Potrebbe rendere i dispositivi meno desiderabili o un giorno l'ultimo telefono Android potrebbe essere realizzato senza le app di Google, ma può succedere senza biforcare alcun codice. Siamo tutti colpevoli di mettere insieme le due cose, ma non dovremmo farlo.

Forking è solo una cosa

Non va bene che gli OEM distribuiscano Android e lavorino sul proprio progetto con il codice. Non è male che gli OEM distribuiscano Android e lavorino sul proprio progetto con il codice. È solo una cosa che fanno tutti.

Nexus fanclub a parte, non puoi dirmi che Samsung o HTC hanno rovinato Android digitando il codice e costruendo su di esso. Hanno aggiunto funzionalità mantenendo tutto compatibile in modo che le applicazioni create per "Android" secondo le linee guida per gli sviluppatori funzionino perfettamente. E forniscono costantemente dispositivi che le persone vogliono acquistare. Penso che questo sia esattamente ciò che Google aveva in mente per Android. Sapevano che alla fine qualcuno sarebbe andato un po 'oltre e avrebbe creato qualcosa che non era completamente "Android", ma va bene. Gli utenti di questi dispositivi sono ancora su Internet e le app Web mobili di Google sono abbastanza decenti.

Spero che ora sappiate qualcosa in più su ciò che le persone intendono quando parlano di fork di Android.