Netflix ya no necesita ayuda: cierra su API pública a desarrolladores

House of cards

Netflix, que lleva años pasando por ser una de las compañías más innovadoras en varias facetas, incluida la de ofrecer un API pública a terceros, anuncia el cierre de esta a nuevos desarrolladores.

Al menos han tenido el detalle de mantener el uso a los actuales terceros que han construido sobre el API, pero el anuncio es claro: no quieren a más terceros accediendo a las funcionalidades de su plataforma y ofreciendo servicios al usuario final.

Con esta noticia volvemos al debate de Api cerrada o api abierta y de cómo en diferentes etapas de una compañía le beneficia un modelo u otro. Al igual que a Twitter, en la etapa de crecimiento inicial el tener a muchos desarrolladores construyendo sobre la plataforma ha permitido a Netflix llegar a muchos más usuario y «externalizar parte de la innovación».

Cuando el negocio está maduro y tienen el modelo claro, tanto Twitter como Netflix han preferido tener mucho más control de quién hace qué y cómo se lo ofrece al usuario final.

Para los terceros que construyen sobre una plataforma que no es propia, no me canso de enlazar este artículo de 2007. Esta vez Netflix ha tenido el detalle de no cortar el grifo a los que ya habían invertido tiempo y dinero utilizando su Api (en esto son más elegantes que Twitter), pero la pregunta sigue siendo la misma ¿cuánto de valor obtengo frente al riesgo que corro dependiendo de quien me ofrece el Api mientras su modelo y negocio no estén claros?

Sobre Bluevia y las APIs de telecos

BlueviaEl tema de las APIs de telecos probablemente no sea el más sexy del sector de la tecnología, pero creo que es tan interesante como el marco en el que se inscribe: la búsqueda de las operadoras de negocio alternativo a voz y datos y su necesidad de cambio de modelo para ello.

En Xataka Móvil publiqué ayer «Un pequeño paso para Bluevia, ¿un gran paso para las APIs de telecos?«, sobre la iniciativa de Telefónica, su avance al incorporar a Telenor y las piedras que todavía le quedan en el camino para demostrar que hay futuro para las APIs de telecos.

Relacionada: APIs de red de las teleco, ¿tienen sentido? Un debate con José Vallés de Bluevia

API cerrada, API abierta

TweetDeck
El valor de que un servicio en internet ofrezca un API para que terceros se integren con él está casi fuera de cualquier duda, aunque los modelos de negocio sobre estas APIs y la apertura de la misma sí que son objeto de un continuo debate.

En los últimos días un anuncio de Twitter por el que daban por finalizada la integración que su API posibilitaba a Linkedin sirve de ejemplo del paso de una filosofía «API céntrica» como apuntaba Dalton Caldwell a establecer un control más férreo que ya anticiparon en varias ocasiones (1, 2) y tras el que se encuentra el deseo de controlar la experiencia de usuario y la generación de ingresos.

Las ventajas de un API cerrada, las ventajas de un API abierta

Twitter ha sido estos años el paradigma de los beneficios de un API abierta, miles de desarrolladores en todo el mundo construyendo servicios y enriqueciendo la experiencia Twitter, multitud de mejoras que su propio equipo nunca podría haber siquiera ideado. ¿Qué precio se paga por ello? la experiencia de los usuarios empieza a estar controlada por terceros, que intermedian y quieren desarrollar su propio negocio, a veces en conflicto con la plataforma que ofrece el API. Incluso puede llegar un día en que uno de esos servicios acapara tanto protagonismo que acabas comprándolo como en el caso de Tweetdeck por varias decenas de millones.


Por otro lado, un API cerrada cuyo uso se acuerda de forma privada entre plataforma y cliente ofrece un control mucho más estricto de quién puede hacer qué, con condiciones, fechas y precio. Dos ejemplos de esta filosofía lo tenemos en Google Plus y su integración con Flipboard o Path con Nike. En ambos casos cuidan muy mucho el no «estropear la experiencia», algo que podría darse si cualquier aplicación empieza a escribir en los muros de sus usuarios, replicando contenidos de otros sitios, metiendo ruido… en su lugar han preferido ir con un cliente con el que tienen una gran relación de confianza y darle acceso exclusivo

Quienes apuestan por este enfoque de «API privada» también pagan un precio, claro. No están integrados en los clientes más populares utilizados por los usuarios, las herramientas de monitorización no las indexan, no se pueden integrar en servicios de terceros que podrían darles una gran visibilidad. Un caso interesante a seguir va a ser el de Instagram, que nació con un modelo claro de API abierta, pero que en manos de Facebook es posible que no siga demasiado tiempo con esa filosofía.

Lo peor de ambos mundos

Hace poco Versvs apuntaba a que el movimiento de Twitter se podía resumir en «muera la plataforma y viva el medio». De hecho el cambio de rumbo no hace sino confirmar los temores que comentamos por aquí en ¡2007! cuando despegaba la tendencia de construir mashups a partir de APIs de otros: la relación de poder que establece la plataforma con respecto a los clientes.

Y esto es lo peor de ambos mundos, cuando se pasa de API abierta, muchos desarrolladores han creado su servicio sobre tu plataforma y empiezas a virar hacia un API cerrada. Es entonces cuando se crea la desconfianza, la rebelión y las críticas por deslealtad con respecto al ecosistema que te empujó cuando estabas naciendo. En esas está Twitter, que al final está virando hacia una experiencia completa con más control en su web y clientes, depurando el uso de su API que entra en conflicto con este plan y con su modelo de negocio.

Y Nike empezó a ofrecer un API

Una de las novedades más interesantes del pasado SXSW las ha protagonizado una de las empresas de tecnología más interesantes de los últimos años, Nike. Y sí, servidor considera que Nike es una empresa de tecnología, con algunos de las iniciativas más innovadoras en la involucración de esta con el deporte.

Un ejemplo de ello es la Nike+ Fuelband, una pulsera que registrara todas tus movimientos, mide gastos de calorías, metros recorridos, velocidad… y permite establecer retos y «recompensas» en función del cumplimiento. El lanzamiento de su API está muy enfocado a la integración de servicios musicales: imaginemos un Spotify o Pandora que te pinchen una música en función del contexto del ejercicio que estés haciendo.

Es una idea inicial, si unimos los datos que puede medir una pulsera de este tipo sobre nuestro organismo y el ejercicio que hacemos, las posibilidades que abre de integración para terceros son muy amplias: un servicio que recomiende qué alimentación seguir que encaje con el ejercicio que hacemos y con los objetivos de peso y forma que nos pongamos.

¿Qué aporta un API a una marca como Nike? Casi habría que dar varios pasos atrás para responder a esa pregunta. Por un lado, podemos preguntarnos qué aporta una aplicación a una marca y comparar con el potencial que tiene ofrecer un API para que muchos desarrolladores hagan que muchas aplicaciones se integren con nuestro servicio. Yendo más allá, para Nike tiene sentido desde el momento en que quieren salir del «deportista intenso» que mide pulso, distancias y velocidad con algo como esta Nike+ Fuelband (página oficial, no se vende en España), quiere aumentar el uso y valor de este servicio, y, de manera indirecta, ganar relación e interacciones con sus usuarios.

¿Cuánto le cuesta a Nike impactar a un usuario y cuantas veces lo puede hacer gracias a iniciativas como esta? ¿es rentable la acción? Es fácil aplaudir la innovación de Nike, pero habría que hacer la salvedad de que estas son el tipo de cosas que se puede permitir una compañía con un presupuesto de marketing que supera los 2400 millones de dólares (Ad Contrarian). En cualquier caso, creo que el caso de Nike merece la pena analizarlo, por ejemplo con diez puntos que compartía hace poco Albert

Más de economía de las APIs: la de Google Maps se pasa al «freemium»

Vivienda en Google Maps
Google sigue reconduciendo su políticas de APIs. Si hace poco le tocó a la de Google Translate, ahora anuncia que el API de Google Maps pasa a modelo freemium: gratis bajo un límite de uso, de pago por encima de ese nivel. La medida tendrá efecto el año que viene y para grandes volumenes aconsejan pasarse a la opción Premier en lugar de pagar precio por petición adicional.

La política de APIs parece haber sido guiada por la confianza de que «ya vendrá el negocio de alguna manera sin tener que cobrar por ellas» y en el caso de Google Maps parecía que esto podía estar con la publicidad integrada en los mapas. Los números no salen a Google y un modelo freemium parece lo más razonable para asegurar que el API es sostenible, que tiene un amplio uso / adopción y que hay un modelo de negocio para las próximas. Curiosamente, sigue vigente lo que comentábamos en 2007 sobre construir tu aplicación sobre APIs de terceros.

El API de Google Translate pasa a ser de pago

Hace unos cuatro años hablábamos de los problemas y precauciones a tomar a la hora de montar un negocio sobre el API o plataforma de un tercero y mucho de lo comentado allí sigue siendo aplicable. El caso del API de Google Translate ejemplifica las debilidades del modelo de API gratuita y abierta al uso de cualquiera: tras años de puesta a disposición de cualquiera, en Google se cansan de pagar los recursos que el uso masivo de la misma requería y deciden dejar de ofrecerla. Las quejas y demandas parecen hacer recapacitar a Google y ahora afirma que ofrecerá una versión de pago para la API.

La historia tiene moralejas para las dos parte de la historia. En la del cliente, más vale API de pago con modelo sostenible que servicio gratis para todos pero sin futuro. Hasta que no sepas cuál es el negocio sobre el que estás construyendo tu servicio, no puedes estar seguro de que vaya a continuar (o de que incluso ese negocio acabe siendo lo que tú has desarrollado). En el lado de Google, el «todo gratis» para obtener un beneficio indirecto en forma de mayor apego de un tercero con su ecosistema no tiene sentido con las APIs y más de esta forma abierta en la que un montón de granjas de contenido spam utilizan la de Google Translate para generar páginas. Después de todo, puede que hayan acabado encontrando un negocio interesante para su área de servicios a empresas: APIs de pago sobre su excelente infraestructura y oferta de servicios

Twitter a terceros: que nadie manche nuestro timeline (y gane dinero con ello)

TweetDeck

Twitter vuelve a dar una vuelta de tuerca en lo que a su relación con los terceros que utilizan su API, anuncia que pasa a prohibir explícitamente que cualquier cliente introduzca publicidad en el timeline. Sólo podrán aparecer los twits promocionados que gestionará el propio Twitter y no se verá afectada aquella publicidad fuera del timeline, como la que aparece en algunos clientes móviles gratuitos.

Aquí Twitter se ha cargado a más de una empresa que planteaba un sistema publicitario para clientes sin pasar por ellos. Curiosamente han vuelto a poner encima de la mesa el debate de la relación con su ecosistema, cuando ya habían provocado una crisis hace apenas un mes y podían haber aprovechado para liquidar el asunto en un paso. Se acerca la hora para Twitter de buscar la rentabilidad y están soltando amarras: van a perder la relación y la confianza de parte de su ecosistema (¿cuál será el próximo cambio de condiciones? ¿merece la pena invertir más en integrarse con Twitter?), van a ganar en control sobre la «monetización» (si me permitís la expresión). Un modelo de negocio más claro, pero perdiendo ese perfil de «protocolo neutral» que algunos hace tiempo que le atribuían.

Economía de las APIs: Youtube y el negocio de la integración en hardware

youtube XL

Los set-top boxes de Popcorn no integrarán el acceso a los vídeos de Youtube, y como ellos, serán muchos los dispositivos que aspiran a articular la convergencia televisión-internet que se quedarán sin el servicio para compartir vídeos de Google. Lo denunciaba el COO de Syabas – la empresa que hace los Popcorn – y entran en detalles en este artículo de Wired: Youtube exige inversión publicitaria multi millonaria a cambio de que fabricantes puedan integrar su plataforma vía API.

Por aquí hemos comentado más de una vez los riesgos que implican la «economía de las APIs» (véase Servicios como una plataforma o tu aplicación sobre APIs de terceros y Los problemas de negocios sobre APIs de terceros, el caso Twitter), que este caso ejemplifica a la perfección. Mientras Youtube necesitaba crecimiento en tráfico, para ellos era una ventaja ofrecer un API sin límites de uso y gratuita; una vez que el tráfico y la marca ya está construida, el objetivo es maximizar ingresos y un mercado importante son los terceros que han construido su servicio sobre el tuyo. A esa lógica sumas que Google se reservaba el derecho a cambiar los términos de servicio del API de Youtube, y tienes la situación actual: en hardware integrarán los grandes fabricantes capaces de invertir x millones de dólares al año en publicidad. Queda ver qué pasará con los que basen en soluciones XBMC y similares, como es el caso de Boxee.

Relacionado: Facebook cobrando por las aplicaciones, Youtube y el negocio con la cabeza de la larga cola