Ho ottenuto risposta immediatamente da uno degli sviluppatori, Abhisek Devkota, che successivamente non ha rifiutato di continuare per un po’ la chiacchierata direttamente nel thread. Abbiamo monopolizzato un po’ l’attenzione, ma sono contento di questa “intervista” fra virgolette, dato che mi ha fornito l’opportunità di venire a contatto con un insider di un progetto che stimo moltissimo. Vi riporto lo scambio di battute in maniera integrale, a parte qualche piccolo taglio e/o correzioni varie.

Qualche notizia relativa allo sviluppo di CM9 per Nexus One?

Allo stato attuale, possiamo fare il boot ed eseguirla usando il nostro lavoro e quello di Evervolv (github.com/Evervolv). Però, e questo è un grosso PERÒ, il processo richiede delle patch che noi avvertiamo come non “pulite”, o non appropriate nei confronti degli standard di Google per l’accesso al mercato. Purtroppo quindi, fino a che non porteremo il dispositivo ad uno stage in cui non ci sono conflitti, non avremo molte notizie in merito.

Capisco. Grazie della risposta, e continuate così, sto testando il vostro lavoro e lo trovo veramente veloce. Volevo solo l’opinione di un insider sulla questione Adreno200; sono veramente fiducioso sul fatto che non dovrò ricomprarmi lo smartphone per utilizzare ICS. Congratulazioni, ancora ;)

Beh, nel caso peggiore non avrai CM9. Ma ci saranno tante altre vie per avere ICS. CyanogenMod è un “animale” [questo l'ho tradotto alla lettera, è bellissimo ndr.] differente dal resto delle ROM e degli hack, dato che Google (con un po’ di piaggeria) ci presta molta attenzione e, per assenza di termini migliori, ci tratta come un OEM.

Per mantenere questo status, operiamo come se fossimo un solo uomo, e ci assoggettiamo volontariamente a questa pratica, il che significa che dobbiamo stare attenti a non fare passi falsi, altrimenti romperemmo il CTS, od altri standard. È il prezzo da pagare per essere così popolari, ma questo d’altro canto rende il nostro lavoro ancora più duro e pulito.

Lo so, mi ricordo il problema con le GApps, dopo quel fatto Steve cominciò a distribuire la ROM come due package separati, e non come una soluzione all-in-one. È il prezzo da pagare, e non possiamo farci nulla; mi piace in ongi caso, una community con questa forza e questo tasso di crescita presenta qualche criticità ma infiniti pregi. Dopo tutto sono felice che il team di CM mantenga degli standard alti, anche se questo significa una RC in meno o un ciclo di sviluppo più restrittivo. [Mi riferivo al discorso di CyanogenMod 7.1, arrivata dopo tanto tempo; Abhisek ha capito. ndr.]

 Quella è una storia vecchia dove (ringraziando il cielo) non abbiamo dovuto effettuare grossi cambiamenti, dal momento che avevamo fatto si che CM funzionasse da sola senza i “bit” di Google. In un caso più recente, stavamo considerando di aggiungere Cornerstone per i nostri tablet, ma abbiamo avuto un pushback serio da parte degli sviluppatori Google di Android, arrivando al punto di suggerirci che tutte le varianti di CM sarebbero state bandite dal mercato (non vista come una minaccia, ma come una soluzione a un problema tecnico). Siamo lieti di avere questo tipo di feedback dalle persone che rendono possibile Android e quello che noi facciamo.

Riguardo la nota sul ciclo di sviluppo, attualmente speriamo di poterlo velocizzare in futuro. I ritardi e il ritardo sono accaduti perchè noi potessimo riallinearci al fine di  approcciare un piano più aggressivo. Poi se ne parla ;)

Fortunatamente ve l’hanno detto (di Cornerstone) prima, e non dopo un po’. Essere un coopetitor (non è un typo) così grande significa avere il giusto supporto in questo tipo di situazioni. Sul ciclo di sviluppo, la mia nota non voleva essere assolutamente offensiva ;) Ho visto i ritardi come una cosa positiva. Quando ho studiato Ingegneria del Software, ho usato una carta semplificata (fatta da me) analizzando il vostro modello di sviluppo quindi da utente sono fiero di vedere una struttura così organizzata ;)

Successivamente la discussione ha preso un’altra piega, essenzialmente perchè la gente si è rotta di leggere solo noi due ed ha ripreso a commentare. Mi ha fatto veramente piacere in ogni caso parlare con Abhisek, che si è dimostrato una persona preparata e soprattutto uno sviluppatore attento anche ai movimenti del mercato.

Photo courtesy of Johan Larsson

Essenzialmente, ho notato un comportamento chiave nel mercato del software: nel caso di attività multipiattaforma, si genera una sorta di onda anomala per cui all’arrivo di un software blasonato su una piattaforma concorrente, vengono disintegrate le alternative, a prescindere dalle criticità e dai pregi dell’una e delle altre. Mi spiego meglio.

The world will be mine…

Proprio con l’arrivo del problema dell’essere multipiattaforma, sono cominciate ad esistere nel settore informatico una serie di ricorrenze per cui un software, diventato leader di mercato, comincia a fare le sue belle cosine su una piattaforma sola e la portabilità viene considerata un po’ poco. D’altra parte, gli utenti di altri sistemi operativi, CMS, browser o cose simili cominciano a desiderare spasmodicamente quel software, e sperabilmente sfruttano potenziali concorrenti; nel campo dell’open source si incappa oltretutto nella creazione ex novo di altri software che facciano la stessa cosa, altrimenti dei volontari si uniranno a progetti esistenti per implementare le feature di cui c’è la necessità in qualcosa di già presente nel mondo dei programmi.

Contemporaneamente, però, in generale il motore immobile di tutto questo, ossia il software leader di mercato che è presente sull’altra piattaforma, costituisce il driver fondamentale per quanto riguarda le caratteristiche di ciò che un software di quel tipo deve avere. Una grossa minaccia per la creatività di chi, occluso dalla cecità istigata dalla voglia di quella determinata caratteristica, invece potrebbe sfornare tanto di buono che non viene a galla. Follow the leader. E gli altri?

… and you’re first in line

Il nostro ecosistema di software che essenzialmente fanno tutti un po’ la stessa cosa, capeggiati da un driver di mercato che detta feature e altro, è dispersivo. Ognuno coltiva il proprio orticello, e in genere anche se c’è un software più “corposo” degli altri comunque non è sufficientemente autonomo in campo di feature design da dare filo da torcere al competitor principale, anzi; spesso alcuni pregi non vengono capiti, e ci si concentra su delle cose magari risolvibili invece di prendere atto di alcune peculiarità che, magari, sarebbero decretatrici della fine di qualsiasi progetto concorrente.

Un giorno, il leader di mercato decide che i dati di crescita non sono più abbastanza grandi, oppure (e l’uno non esclude l’altro) vuole semplicemente un’altra fetta di utenza tutta per sé; lo squalo decide di mangiare il gattino in quattro e quattr’otto, e annuncia l’inizio dello sviluppo del software per la piattaforma concorrente a quella corrente. Leak di volontari, e disinteresse per i progetti che sinora erano stati tenuti in vita solo dalla volontà di vedere un prodotto simile al leader per la piattaforma concorrente, sono i sintomi più comuni dopo un annuncio del genere.

Il gigante del mercato così fagocita tutto il resto, inglobando quei progetti che, giustamente, non hanno saputo fare di meglio che restare nella sua scia invece che proporre alternative intelligenti e feature innovative che avrebbero potuto decretare il successo della piattaforma alternativa e il balzo in testa di un nuovo leader, almeno in alcune fette di mercato.

L’effetto Instagram

Quanto di cui sopra, mi piace formalizzarlo come “effetto Instagram”. L’intuizione infatti mi è venuta mentre osservavo il trend sempre crescente di Instagram su iOS, e quando ho visto la notizia della pianificazione dell’applicazione per Android ho potuto notare come molti avessero già deciso per lo switch da altre piattaforme, compreso il sottoscritto per vari motivi. Software come PicPlz e Lightbox hanno quindi ricevuto una poderosa ridimensionata al proprio volume di attività dal momento in cui Instagram ha fatto la propria comparsa sul Google Play Store.

È solo un caso, ma ce ne sono a decine di simili, come GIMP o LMMS, softare assolutamente buoni ma che crollerebbero se un market driver come Adobe decidesse per qualche motivo di fare il grande passo verso Linux. Rimarrebbero software per hobbisti, gratuiti e nient’altro, non in grado di offrire niente di più.

Nel caso specifico, PicPlz ha puntato semplicemente ad essere un’alternativa ad Instagram per Android senza minimamente calcolare che il fattore che ha determinato il successo di Instagram non è stato qualcosa come la presenza di filtri (dato che quelli di Instagram fanno alquanto cagare, e scusate il francese) o la possibilità di modificare le foto, bensì la sua componente hipster (io ho Instagram → io ho un iPhone → io mi posso permettere un device da 700 euro) e la comunità su cui l’applicazione scala parecchio bene, che si è formata e adesso conta veramente tantissimi membri attivi. L’aspetto social è sempre stato sottovalutato da applicazioni come PicPlz che oltre a fare la stessa cosa che faceva Instagram la facevano pure maluccio, per quanto riguarda l’aspetto community, e infatti adesso sono state fagocitate e buttate nel calderone di quelle cose che ormai non servono più. Fine del bel sogno di gloria.

Evitare l’effetto Instagram

La parola d’ordine è solo una: differenziarsi. Fare l’Instagram dei poveri o il Photoshop aggratis è un conto, iniziare ad introdurre qualche feature degna è un altro paio di maniche. E se il tuo progetto non deve morire, deve differenziare la propria offerta da quella dei competitor, non importa quale piattaforma si prenda come riferimento.

Magari lavorare secondo la Teoria delle Nicchie di Simone ;)

Succede che in questi giorni mi sto dilettando con Android e lo sviluppo per il sistema di casa Google. Ho scaricato Eclipse, il plugin dedicato, l’SDK. Al suo primo avvio, mi scarica tutte le API di questo mondo e le relative piattaforme con emulatori annessi per test e APK building; succesivamente, vado a scrivere un po’ di robaccia tanto per testare. Noto che funziona tutto al primo colpo (e quando io programmo nulla funziona mai al primo colpo, quindi questo è un grandissimo evento), tuttavia una volta cominciato il viaggio nelle profondità degli abissi androidiani, mi ha colpito il fatto che anche senza aver modificato una beata mazza il mio software non compilasse più. Figo. E come mai?

'default' is not a best match for any device/locale combination.
Displaying it with 'Locale Language ___Region __, sw320dp, w320dp, h533dp, Normal Screen, Long screen aspect ratio, Portrait Orientation, Normal, Day time, High Density, Finger-based touchscreen, Soft keyboard, No keyboard, Exposed navigation, Trackball navigation, Screen resolution 800x480, API Level 10' which is compatible, but will actually be displayed with another more specific version of the layout.

Error in an XML file: aborting build.

Continuo a non capirci una mazza finché, sconsolato, non chiudo l’SDK e mi metto a fare altro. (Nello specifico, seguire la lezione. Si, stavo programmando mentre il prof spiegava – e per inciso dopo è anche venuto a dirmi “oh ma stai programmando Android! Fighissimo!”)

Il giorno dopo, un po’ insonnolito, riapro Eclipse e lancio il build dell’APK, con conseguente esecuzione in emulazione. Tutto liscio. Allora comincio a cercare su Google, smaliziato, e trovo effettivamente dei risultati; nessuno che si applichi al mi caso però: dopo un po’ il problema di ripresenta identico e non serve a niente fare Clean, o chiudere e riaprire. Poi mi coglie l’ispirazione.

E decido di riaprire Eclipse, e lanciare la sequenza di build dal file principale che contiene la Main Activity: boom, tutto funziona alla grande. Cambio file, di nuovo stesso errore.

Conclusione? Beh, lesson learned: non fate gli idioti come me. Lanciate l’applicazione dal file principale.

Vai con le diapositive.

Non è un dual-boot

Innanzi tutto Ubuntu per Android non è assolutamente un dual-boot; appena lo infili in maniera molto lussuriosa dentro la dock, il telefono magicamente prende vita, ruota la visuale e sul tuo monitor viene mostrato un workspace Ubuntu completo, il tempo di dare l’avvio al framework grafico (presumo che il server sia sempre Xorg) e qualche altra cosuccia. Questo mi lascia molto perplesso, perchè significa che Android lavora con Ubuntu, e Ubuntu con Android. C’è sinergia, dato che la Dalvik Virtual Machine può eseguire applicazioni in finestra, e non sono due ambienti separati; da Ubuntu hai accesso a tutto l’ecosistema telefonico-messaggistico vario, più le app.

Strano modo.

RISC VS CISC, ossia Davide contro Golia

È inutile che ci stiamo a prendere in giro, per operazioni massicce di I/O un RISC come un ARMv7 non va bene. Ho le mie perplessità sul fatto che fare operazioni un pelo più complesse dell’editing di un documento di testo possa essere meno facile e indolore come scolarsi sei litri di grappa a garganella. Sicuramente mettersi su un piccolo client torrent con più di una cosina a scaricare in contemporanea renderà la macchina inservibile. Come? Dici che non è pensato per quello? E ho capito, ma io mica posso fomentarmi per Ubuntu su Android se poi il massimo che posso farci è guardarmi un film. Se devo usare il computer per lavorare, con il futuro prossimo fatto tutto di cloud, sincronizzazione e indicizzazione, è inutile che mi fornisci la pietanza senza piatto su cui mangiarla.

Insomma, una roba figa. Chissà se magari con i nuovi Atom di Intel per smartphone (magari sono pazzi questi di Intel, magari no) che sono dei CISC riusciremo a vedere qualcosa di più performante da questo punto di vista. Quello che è sicuro è che sarei curioso di provare la soluzione di Canonical su uno smartphone quad-core. ;)

L’assolo

Effettivamente un assolo ci sta tutto.

Magari qualcosa di estremamente cervellotico di Tosin Abasi, perchè è quello che mi ha attraversato il cervello quando ho visto per la prima volta Ubuntu per Android. O forse… meglio questa. ;)

Nonostante io non sia un fan di Windows Phone 7, credo che Microsoft con Nokia stia facendo un buon lavoro, anche se in compenso disprezzo parecchio il fatto che Nokia, entrando in questo accordo a strozzo come al solito di Microsoft, abbia cestinato tutto il proprio comparto open per dedicarsi ai soli Lumia con Windows. È così che mi sono imbattuto in questo articolo di Jonathan Muhin che la pensa esattamente come me su questo e sulla figura, a mio parere barbina, che Nokia sta facendo a Barcellona; eh si, perchè è successo che mentre Samsung e HTC hanno tirato fuori delle intere lineup di dispositivi Android, rafforzando ancora di più quello che è ormai l’accordo bilaterale tra produttore di hardware e produttore di software, Nokia ha “sderazzato”, è andata fuori dai binari incensando si la propria lineup di Lumia, ma facendosi forte col suo annuncio più grande: il Nokia 808, un “coso”, perchè altro non è, che ha una fotocamera assolutamente inutile da 41 megapixel, Symbian (WTF?), e un hardware povero come al “solito”. Questo è il grande annuncio di Nokia al MWC 2012: un cellulare preistorico con una fotocamera che sgrana in scala 1:1000. No, dico.

The phone boasts of a 41 mega pixel sensor which to an experience photographer doesn’t make any sense. What makes sense for good images is a good glass (lens) and amount of light that enters the lens. Beyond the 41 mega-pixel sensor everything in this camera belongs to Flintstones era.

Ora, io non sono il tipo che inneggia al licenziamento della gente, e visto il lavoro fatto fino a adesso, nonostante la chiusura in termini di sviluppo dell’azienda, penso che Stephen Elop dovrebbe rimanere lì dov’è, sulla sua bella poltrona in pelle umana a godersi il suo Lumia aziendale preso aggratis, però non nascondo che, alla lettura della notizia, mi sono spanciato dalle risate.

Pensare che in fondo bastava poco: presentare qualche altro telefono, spingere su Tango… roba che persino Mozilla è riuscita a fare un intervento figo, con Boot 2 Gecko. Vabbeh vah, vado a divertirmi con Fedora 17 Alpha.