Twitter modifica su API… ¿y ahora qué?
La red de microblogging acaba de publicar una nueva versión de su interfaz de programación de aplicaciones, entre las críticas de los desarrolladores y la incertidumbre de los usuarios.
Más autenticación, más certificaciones, mayor control. Así se pueden resumir las líneas maestras de la polémica interfaz de programación de aplicaciones (API) de la red de microblogging por excelencia, que acaba de ser actualizada a la versión 1.1. ¿El objetivo? Según Twitter, “ofrecer una experiencia consistente”, primando la calidad sobre la cantidad de los programas existentes, fomentando la innovación y previniendo posibles usos maliciosos. Según los desarrolladores, fortalecer la creciente red de publicidad y mimar la monetización de la famosa firma del pajarito azul. Pero, sobre todo, extraer un conocimiento profundo acerca del tipo de aplicaciones que tienen acceso a los contenidos de la plataforma y ejercer un control férreo sobre sus intenciones.
Así, por ejemplo, la nueva interfaz aplica restricciones en el número de usuarios que pueden acceder a Twitter a través de determinado servicio web o aplicación de terceros, y alienta hacia una mayor interacción entre los creadores de estos trampolines y la empresa de Jack Dorsey. Los desarrolladores que de ahora en adelante necesiten sobrepasar la barrera de las 100.000 personas deberán solicitar permiso explícito para ello; mientras que las apps que ya cuentan en su haber con tal cantidad de miembros serán capaces de seguir aumentando su base de participación en un 200%. Esto implica que los dueños de apps de grandes dimensiones tendrán que trabajar directamente con la empresa, sin intermediarios que valgan.
Otro número que se limita es el de llamadas que es posible realizar a la API en el plazo de una hora, con un tope de 60. ¿Si se necesitan más margen de maniobra? La respuesta es que seguramente haya que pagar algún tipo de cuota. Bajo esta normativa también se requiere una identificación clara en cada petición individual, para obtener datos de la API, y se ponen cortapisas a la posibilidad de compartir tuits en otros servicios, eliminado la reproducción de mensajes por partes, prohibiendo la mezcla de este material con el de otras redes sociales, enlazando los nombres de usuario a sus perfiles en la red de los 140 caracteres y manteniendo los botones de acción originales tipo “retuitear”, “responder” y “favorito”.
En resumidas cuentas, si alguien quiere construir un cliente de Twitter para una plataforma móvil o cualquier dispositivo electrónico alternativo, como bien puede ser un televisor inteligente, necesitará tramitar una solicitud y que ésta sea certificada por Twitter. Tanto es así que se ha llegado a modificar la terminología para reflejar una postura más dura con los programadores: las “directrices” ya no son recomendaciones, ahora son “requisitos”. Se ha actualizado el contenido de las Developer Rules of the Road con consejos sobre cómo absorber los cambios de forma correcta. Y se contemplan reprimendas a quienes no cumplan con lo establecido so pena de revocación de sus claves, cortando el grifo a los contenidos generados por los usuarios y la interacción con su red.
El objetivo es la calidad, el resultado es el bloqueo
El problema es que algunas de estas aplicaciones de terceros se han convertido con el tiempo en modelos de referencia para muchos internautas y corren incluso el riesgo de desaparecer como final extremo, o de volverse de pago como mal menor. Sus responsables critican que a estas alturas se les cierren puertas cuando han estado contribuyendo desde un principio al propio crecimiento de la red social con sede en San Francisco. Y tachan las prohibiciones de Twitter como una forma desesperada de frenar la creatividad de la competencia y un ataque directo a quien amenace con hacerle sombra.
Lo cierto es que la compañía de Dorsey compró el cliente Tweetdeck en mayo de 2011 y ahora parece deseosa de reorientar el desarrollo de sus antiguos colaboradores hacia otra categoría de aplicaciones más allá de las profusamente utilizadas Tweetbot y Echofon o, en otras palabras, que no repliquen su experiencia original. Sino que se ocupen de campos alternativos como el análisis de negocios (caso de DataMinr), la integración de plataformas con mediciones (a lo Klout) y todo el componente empresarial asociado (tipo HootSuite). Lo que también deja en el disparadero a propuestas como Instapaper, EmbedTree y MentionMachine, por no hablar de Tweetcaster, UberSocial, Plume o Twitterrific.
Por otra parte, el descontento de la comunidad se dirige hacia la misma redacción de las normas en tanto que se acogen a un lenguaje demasiado ambiguo y, en consecuencia, podrían llegar a legitimar a Twitter para la aplicación de condiciones aún más duras. Al margen de esta hipótesis de futuro, la red de microblogging ha dejado claro que su ultimátum no tiene carácter inmediato. Los desarrolladores cuentan con alrededor de seis meses para acometer todas las migraciones necesarias y adaptar sus servicios a la nueva API. Esto es, de aquí al 5 de marzo de 2013.
¿Es tiempo suficiente? ¿Se quedarán muchas aplicaciones sin pasar la criba? ¿O alcanzarán un acuerdo con Twitter para salvaguardar su vía de negocio? ¿Y los usuarios? ¿Se rebelarán contra los cambios en el ecosistema?