Episode Details

Traduzione in italiano di Maurizio Ghisolfi dall’essay originale di Paul Graham "Apple's Mistake" [Novembre 2009].

Non credo che Apple si renda conto di quanto il processo di approvazione dell'App Store sia difettoso. O meglio, non credo che si renda conto di quanto sia grave che non funzioni.

Il modo in cui Apple gestisce l'App Store ha danneggiato la sua reputazione con i programmatori più di qualsiasi altra cosa abbia mai fatto. La loro reputazione presso i programmatori era ottima. Una volta la lamentela più comune che si sentiva su Apple era che i suoi fan la ammiravano troppo in modo acritico. L'App Store ha cambiato le cose. Ora molti programmatori hanno iniziato a vedere Apple come il male.

Quanta della buona reputazione che Apple aveva un tempo nei confronti dei programmatori ha perso a causa dell'App Store? Un terzo? La metà? E questo solo fino ad ora. L'App Store è una continua perdita di consenso.

Come ha fatto Apple a finire in questo pasticcio? Il loro problema fondamentale è che non capiscono di software.

Trattano le app per iPhone come trattano la musica che vendono attraverso iTunes. Apple è il canale; l'utente è di sua proprietà; se si vogliono raggiungere gli utenti, lo si fa alle loro condizioni. Le etichette discografiche hanno accettato, con riluttanza. Ma questo modello non funziona per il software. Non funziona per un intermediario che possiede l'utente. Il settore del software lo ha capito all'inizio degli anni '80, quando aziende come VisiCorp hanno dimostrato che, sebbene le parole "software" ed "editore" vadano bene insieme, i concetti sottostanti non lo sono. Il software non è come la musica o i libri. È troppo complicato perché una terza parte possa fungere da intermediario tra lo sviluppatore e l'utente. Eppure è proprio questo che Apple sta cercando di fare con l'App Store: un editore di software. Un editore di software, per di più particolarmente invadente, con gusti pignoli e uno stile di casa rigidamente imposto.

Se la pubblicazione di software non funzionava nel 1980, funziona ancora meno ora che lo sviluppo di software si è evoluto da un numero ridotto di grandi release a un flusso costante di piccole release. Ma Apple non capisce nemmeno questo. Il loro modello di sviluppo del prodotto deriva dall'hardware. Lavorano su qualcosa finché non pensano che sia finito, poi lo rilasciano. Con l'hardware bisogna fare così, ma poiché il software è così facile da cambiare, il suo design può beneficiare dell'evoluzione. Il modo standard di sviluppare applicazioni oggi è lanciare velocemente e iterare. Ciò significa che è un disastro avere ritardi lunghi e casuali ogni volta che si rilascia una nuova versione.

A quanto pare l'atteggiamento di Apple consiste nel dire che gli sviluppatori dovrebbero fare più attenzione quando inviano una nuova versione all'App Store. Questo lo dicono loro. Ma per quanto potenti siano, non sono abbastanza potenti da far tornare indietro l'evoluzione della tecnologia. I programmatori non usano launch-fast-and-iterate per pigrizia. Lo usano perché produce i risultati migliori. Ostacolando questo processo, Apple li costringe a fare un cattivo lavoro, e i programmatori lo detestano tanto quanto detestano Apple.

Cosa direbbe Apple se quando scopre un grave bug in OS X, invece di rilasciare immediatamente un aggiornamento del software, dovesse sottoporre il codice a un intermediario che lo tiene in sospeso per un mese e poi lo rifiuta perché contiene un'icona che non gli piace?

Interrompendo lo sviluppo del software, Apple ottiene l'opposto di ciò che sperava: la versione di un'applicazione attualmente disponibile sull'App Store tende a essere vecchia e piena di bug. 

Uno sviluppatore me l'ha detto:

Come risultato del loro p