Zero to One di Peter Thiel – prima parte

Zero To One book cover peter thiel
Zero To One (da Zero a Uno nell’edizione italiana) è un best seller del 2014 dove Peter Thiel parla del mondo delle  startup veramente innovative, quelle che producono qualcosa di nuovo, che non c’era prima, appunto quelle che fanno il salto da 0 a 1.

In questo articolo troverai quelli che secondo me sono i più importanti spunti di riflessione che ho trovato leggendo il libro. Se desideri saperne di più, puoi acquistare il libro su Amazon in tre versioni:

Progresso verticale e progresso orizzontale

Il titolo del libro, come anticipato, è riferito all’innovazione, a quelle startup che creano qualcosa che non esiste prima. Quando pensiamo al futuro, di solito ci immaginiamo un futuro di progresso, e questo progresso può assumere due forme:

  • progresso orizzontale, cioè la replica di qualcosa che esiste già; in pratica la globalizzazione non è altro che un esempio di questo tipo di progresso: basti vedere la Cina, che non ha fatto altro che replicare moltissimi processi industriali che esistevano già in occidente.
  • progresso verticale, cioè la creazione di cose totalmente nuove, che non esistevano prima; l’esempio non è più la globalizzazione ma il settore tecnologico, che prevede continua innovazione per stare al passo con i tempi e non essere tagliati fuori dal mercato.

Si può dire quindi che mentre il progresso verticale è un passo da zero ad uno in quanto si passa da qualcosa che non esiste a qualcosa che esiste (es. da una macchina da scrivere a un computer con word processor), il progresso orizzontale è solo un passo da uno ad n in quanto non si fa altro che moltiplicare un oggetto esistente (es. ho una macchina da scrivere e ne produco altre 100.

Come si fa il progresso zero to one?

Si cerca di dare una risposta a questa domanda per l’intera lunghezza del libro… tanto per cominciare, serve un piccolo gruppo di persone, ecco perchè le startup giocano un ruolo chiave nell’innovazione.

Una persona da sola non è sufficiente, un genio solitario può riuscire a creare un’opera d’arte quale un quadro o un libro, ma per rivoluzionare un intero settore industriale servono più persone, che si occupino di tutte le sfaccettature che la creazione di un’impresa di successo richiede, dalla realizzazione del prodotto alla sua definizione dal punto di vista commerciale e promozionale.

Anche in una grande azienda è difficile fare innovazione, poichè esistono burocrazie ed interessi contrastanti (per fare carriera spesso è necessario apparire che si stia facendo cose più che farle: con una premessa del genere è ovvio che si produca innovazione col freno a mano tirato rispetto ad una startup dove questo discorso non esiste).

L’eredità della bolla dot com

Prima della bolla

La prima azienda tecnologica di Peter Thiel, PayPal, nasce prima della bolla dot com del 2000, che caratterizza un punto di svolta nell’approccio al fare startup in Silicon Valley. Nel libro viene raccontato come prima della bolla c’era un aria di indefinito ottimismo, tutti pensavano che le cose sarebbero andate bene in qualche modo, nessuna perdita sembrava troppo grande ma era soltanto vista come un investimento: con questa logica si era diffuso l’anti business model che prevedeva che un’azienda perdesse sempre più denaro mano a mano che l’azienda cresceva.

Dopo la bolla

Inevitabilmente l’insostenibile situazione collassò, e la bolla esplose. Moltissime società fallirono. Nell’ambiente presero corpo nuovi dogmi, che le startup superstiti e quelle che sarebbero nate dopo la bolla avrebbero dovuto tenere in forte considerazione se desideravano attrarre investimenti, che non cadevano più a pioggia come prima:

  • Crescere un pò alla volta, fare passi incrementali ben definiti piuttosto che puntare molto in grande fin dall’inizio
  • Essere lean, capaci di reagire agli imprevisti, iterare continuamente procedendo in modo pressoché sperimentale, fondamentalmente senza un piano definito troppo nel dettaglio
  • Assicurarsi che il mercato esista prima di buttarcisi
  • Concentrarsi sul prodotto in modo che questo sia in grado di farsi pubblicità da solo: buona parte degli insostenibili costi che hanno portato alla bolla erano infatti legati al pubblicizzare in modo costosissimo mediocri prodotti

I nuovi dogmi e l’innovazione da zero a uno (zero to one) dopo la bolla

Purtroppo i nuovi dogmi erano abbastanza conservativi da prevenire il verificarsi di una nuova bolla, ma allo stesso tempo non aiutavano di certo l’innovazione, la creazione di prodotti completamente nuovi, il passare da zero a uno. Per fare innovazione è necessario agire in modo quasi completamente opposto a quanto espresso dai dogmi:

  • Meglio rischiare un prodotto ambizioso che uno che potrebbe verificarsi fondamentalmente inutile
  • Un piano sbagliato è meglio di nessun piano, improvvisare è sempre sbagliato
  • Un mercato con molta competizione distrugge i profitti (si veda il mercato delle compagnie aeree)
  • Le vendite contano quanto lo sviluppo del prodotto

E allora? Come fare? Nel libro viene detto di non credere a quello che ci viene detto, ma pensare con la nostra testa, ragionando nello specifico caso della nostra azienda. I dogmi introdotti dopo la bolla sono eccessivamente difensivi: riducono il rischio di aziende campate in aria senza solide basi sottostanti, ma allo stesso tempo tagliano fuori molte aziende innovative o che potrebbero portare a grandi profitti in quanto orientate a mercati senza competizione, quindi che aspirano ad un monopolio nel loro settore.

Per scoprire che cosa intende Peter Thiel con “pensare con la nostra testa”, leggi l’articolo Zero to One di Peter Thiel – seconda parte (presto disponibile)

Android AsyncTask, DeepBeliefSDK e SISSEGV

Lately I have been playing with the DeepBeliefSDK released by JetPac, a startup acquired by Google in 2014.

I have encountered a lot of problems when I have tried to bring the usage of the library from the main application thread (as it is used in the provided examples) to a background thread (called Worker in many different lnaguages and named AsyncTask in Android).

The library has a huge CPU usage, so I guess it HAS TO be used on a background thread, or the application will experience lag (on a Galaxy S5 it keeps 650ms to classify an image, on my device much more). During my tests with the AsyncTask, the application was costantly crashing, with a nice Segmentation Fault (SISSEGV error on the LogCat window) and no useful stacktrace (as expected from native C++ code).

When all seemed lost, I found this article. DeepBeliefSDK is using Open MP (from wikipedia:
OpenMP (Open Multi-Processing) is an API that supports multi-platform shared memory multiprocessing programming in C, C++, and Fortran, on most processor architectures and operating systems […] It consists of a set of compiler directives, library routines, and environment variables that influence run-time behavior.), but there’s currently a bug in the way GOMP (GCC’s implementation of the OpenMP specification) handles data when thread-local storage isn’t available.

So when a non-main thread (the AsyncTask) attempts to use the Thread Local Storage, it crashes. There is a workaround, you should recompile the DeepBeliefSDK with a patched GCC toolchain.

Here you can find the recompiled SDK ready for the use on AsyncTasks. Enjoy! 🙂

Android AsyncTask e DeepBelief SDK ( SISSEGV )

Ultimamente sto giochicchiando col DeepBeliefSDK rilasciato da JetPac, una startup acquisita da Google.

Ho avuto molti problemi quando ho provato a portare l’utilizzo della libreria, dal thread principale in cui si trova all’interno degli esempi forniti, ad un thread in background, quello che in tanti linguaggi di programmazione è chiamato Worker o qualcosa del genere, e che in Android prende il nome di AsyncTask.

La libreria fa un pesante uso della CPU, quindi va utilizzata assolutamente in un thread in background, o l’applicazione stenterà decisamente (su un Galaxy S5 ci vogliono 650ms per classificare un’immagine, sul mio terminale di più). Durante le mie prove con il thread in background l’applicazione crashava sempre, con un bel Segmentation Fault (SISSEGV error recitava la riga di errore che compariva sul LogCat se non sbaglio) e nessuno stacktrace utile (si tratta pur sempre di codice nativo C++).

Quando tutto sembrava ormai perduto ho trovato questo articolo. Per farla breve, DeepBelief usa Open MP (da wikipedia:
OpenMP (Open Multiprocessing) è un API multipiattaforma per la creazione di applicazioni parallele su sistemi a memoria condivisa.).
Ma esiste un bug nel modo in cui GOMP (implementazione GCC delle specifiche OpenMP) gestisce la memoria quando non è possibile accedere alla memoria locale del thread.

Morale della favola, quando il thread su cui è eseguita una funzione della libreria (l’AsyncTask) cerca di accedere alla memoria locale del Thread si ha un bel crash. La soluzione suggerita è ricompilare l’intero DeepBeliefSDK con una toolchain GCC a cui è stata applicata una patch particolare, che in qualche modo (non chiedetemi come) risolve il problema.

Qua trovate l’SDK ricompilato, pronto all’uso anche all’interno del thread in background.