Follow the money

Prendo spunto da una serie di commenti sul caso Youtube per Windows Phone per dire con più dettaglio la mia e portare alcune ipotesi a supporto. Userò il parallelo di Office su Linux cercando di spiegare perché lo ritengo completamente valido.

Cominciamo dal fatto che se fossi in Google sinceramente di supportare Windows Phone me ne sbatterei altamente: non solo la piattaforma dal punto di vista della penetrazione di mercato è sfigata, ma se pure avessero sviluppato una app per Windows Phone 7, l'avrebbero probabilmente dovuta riscrivere per Windows Phone 8. E poi forse di nuovo per Windows Phone 8.1

Google è responsabile dello sviluppo delle app per YT sia per Android che per iPhone. Il fatto che WP sia poco interessante è completamente comprensibile nell'ottica costi/benefici. In un'azienda quotata in borsa costi/benefici vanno sempre giustificati: questo non significa che sia l'unico parametro, ma nel momento in cui bisogna giustificare una decisione nell'assemblea degli azionisti, mostrare diligenza sotto questo aspetto è sempre necessario. Da aggiungere: quando controlli sia il client che il server, dal punto di vista ingegneristico qualsiasi scorciatoia è giustificata, come l'assenza di un layer di API propriamente detto.

Dopo di che passerei a fare alcune considerazioni sulla gravità di quello che ha fatto MS quando ha rilasciato la sua "versione" del client per YT. Bypassare due vincoli di servizio d'uso di YT (permettere di scaricare e non visualizzare la pubblicità) è equivalente a rilasciare una versione di WINE per Linux che permette di scaricare Office gratuitamente e bypassare il processo di attivazione: da un'azienda che fa vagonate di soldi e pretende il rispetto dei termini di licenza ci si aspetta che faccia altrettanto. La scusa di "non avevamo le API" non regge. Non. Regge.

Una volta che gli avvocati si sono scornati e l'accordo è stato raggiunto e si è deciso che Google provvederà una API per il supporto di YT su WP (cosa che MS in passato non ha mai fatto, ad esempio lasciando lo sviluppo di Silverlight al reverse engineering amichevole di Novell), il tutto diventa "esecuzione". A questo punto non conosco altri retroscena ma immagino che la feature "creare API per YT con il supporto della pubblicità" sia finita in una lista nelle mani di qualche Program Manager. Pongo l'accento sulla parola "lista". Ogni team ha una lista della spesa di ciò che va fatto e tale lista viene ordinata per priorità, con il famoso rapporto Costo vs. Beneficio a contribuire al peso di ogni elemento.

Si aggiunga che oggi giorno, come qualcuno fa notare, ci sono decine e decine di applicazioni fatte da tabaccai che rendono la questione quasi irrilevante. Google su questi frangenti si è dimostrata abbastanza tollerante, infatti nel marketplace delle estensioni per Firefox campeggiano svariati "youtube downloader", completamente eradicati dal marketplace per Chrome (ci ha fatto caso qualcuno?).

Quanto detto finora dovrebbe essere analitico abbastanza da comprendere quello che sta accadendo: al posto di Google farei la stessa cosa, ed infatti MS ha fatto la stessissima cosa evitando di supportare piattaforme sfigate (Linux; Android ed iOS non qualificano più come sfigate).

Al posto di MS avrei fatto qualcosa di molto più intelligente: visto che su WP gira "il miglior browser mobile in circolazione" (*), avrei creato un'applicazione che - trasformando il contenuto delle pagine HTML in maniera intelligente - avesse delegato al browser il tutto. Avrebbero risparmiato tempo, energie e al tempo stesso ottenuto un prodotto migliore.

Due parole sul fatto che Google non supporta YT su WP per paura del successo di WP: ma davvero questa teoria sembra più plausibile delle famigerate scie chimiche.

-quack

(*) affermazione che mi vede in totale disaccordo; supportare Flash nativamente non è motivo né necessario né sufficiente.