La crisis de la «Runtime Fee» de Unity: lecciones de riesgo de plataforma y confianza del desarrollador
El 12 de septiembre de 2023, Unity Technologies anunció una nueva «Runtime Fee»: un cobro por cada instalación de juego — y con carácter retroactivo, para juegos ya construidos y publicados. Quienes eligieron Unity hace años, bajo otras condiciones, pasarían a deber dinero por cada nueva instalación de sus juegos existentes.
La reacción fue inmediata. Los estudios amenazaron con marcharse. Godot registró picos sin precedentes de descargas y financiación. La acción de Unity cayó. Las amenazas llegaron a ser tan graves que la empresa cerró oficinas temporalmente. Unity dio marcha atrás parcialmente en cuestión de días, pero la confianza, una vez rota, no se parchea con una actualización de precios.
No leo esto como una historia de videojuegos. Lo leo desde el asiento del que construye: un caso de estudio sobre dependencia de plataforma, confianza en el proveedor y las decisiones que determinan si un cambio de precios es una molestia o una amenaza existencial.
Diez días del anuncio a la disculpa
12 de septiembre: Unity anuncia la Runtime Fee — cobros por instalación a partir de ciertos umbrales (200K para Personal, 1M para Pro), aplicados a juegos ya publicados. Como recogió The Verge, los desarrolladores señalaron que un juego free-to-play con millones de instalaciones podía acabar debiéndole a Unity más de lo que había ingresado.
12-14 de septiembre: Estalla la reacción. La tarifa era retroactiva, se basaba en instalaciones que el desarrollador no controla (reinstalaciones, dispositivos nuevos, fraude), y el mecanismo de medición era opaco.
13-15 de septiembre: Godot, el motor de juegos open source de referencia, ve dispararse el interés. El Godot Development Fund recibió una ola de donaciones sin precedentes. Los desarrolladores estaban votando con los pies.
18-22 de septiembre: Unity pide disculpas y anuncia revisiones: nada de aplicación retroactiva para los suscriptores existentes, posibilidad de elegir entre reparto de ingresos o tarifa por instalación, y eliminación definitiva de la tarifa para Unity Personal.
Pero para entonces las conversaciones de migración ya estaban en marcha en todo el mundo. La pregunta ya no era de precios: era si se podía confiar en Unity como socio de plataforma.
Lección 1: los cambios retroactivos destruyen la confianza
Lo más dañino del anuncio de Unity no fue la tarifa en sí. Fue que se aplicaba a proyectos existentes, construidos bajo otras condiciones.
Cuando un desarrollador eligió Unity hace tres años, asumió un compromiso arquitectónico basado en las condiciones vigentes. Código, experiencia del equipo, herramientas, pipeline de despliegue — todo específico de Unity. La decisión ya era irreversible, y Unity lo sabía. Cambiar las condiciones de forma retroactiva es explotar el lock-in.
La lección: al evaluar un proveedor, las condiciones actuales son solo una parte de la ecuación. Evalúa la estructura de incentivos y la gobernanza. Una empresa cotizada que responde ante sus accionistas puede tomar decisiones que perjudican a los desarrolladores con tal de cuadrar los resultados trimestrales. Pregúntate: si este proveedor cambiara los precios mañana, ¿cuánto nos costaría irnos?
Lección 2: el lock-in es un espectro, y conviene saber dónde estás
No todas las dependencias de proveedor son iguales. Hay un espectro:
Lock-in bajo: APIs estándar donde cambiar exige tocar configuración, no reescribir código. Cambiar de proveedor de email, de CDN o de herramienta de monitorización.
Lock-in medio: APIs propietarias que obligan a cambiar código para sustituirlas. Servicios específicos de AWS como DynamoDB o Lambda. Semanas o meses de trabajo de migración.
Lock-in alto: tu aplicación está construida sobre el runtime o el framework de una plataforma. Cambiar significa reescribir desde cero. Un juego en Unity, una aplicación de negocio sobre Salesforce.
Unity está en el extremo del espectro. Un juego hecho en Unity no se puede portar a Unreal o a Godot sin una reescritura casi total — física, renderizado, scripting, pipeline de assets: todo es específico de Unity.
La lección para quien lidera ingeniería: mapea tus dependencias de proveedor por nivel de lock-in. Para las de lock-in alto necesitas protecciones contractuales sólidas o una estrategia de salida creíble. «Ya lo gestionaremos si pasa» no es una estrategia.
Lección 3: el coste de salida debería pesar en tus decisiones de arquitectura
Cuando arquitectos y CTOs evalúan una tecnología, suelen mirar: rendimiento, experiencia de desarrollo, madurez del ecosistema, mercado de contratación y coste. Lo que casi nunca miran es el coste de salida.
El coste de salida incluye: esfuerzo de reescritura, migración de datos, reciclaje del equipo, sustitución de herramientas y plazos. Para los desarrolladores de Unity, el coste de salida era «reconstruir desde cero». Eso no es una migración — es un proyecto nuevo. Y precisamente por eso Unity se sintió lo bastante segura como para anunciar cambios retroactivos.
La acción práctica: documenta el coste de salida de cada dependencia crítica. No hace falta un plan de migración detallado — basta una estimación aproximada. Si la respuesta es «no podemos irnos», eso va directo a tu registro de riesgos.
Lección 4: el open source no es gratis, pero cambia la dinámica de poder
El auge del interés por Godot tras el anuncio de Unity no fue casual. Los desarrolladores huyeron hacia Godot porque es open source — ninguna empresa puede cambiar sus condiciones porque ninguna empresa lo controla.
El open source no elimina todo el riesgo de plataforma — los proyectos se abandonan y las comunidades se fragmentan. Pero cambia de raíz la dinámica de poder. Con Unity: «acepta nuestras condiciones o vete». Con Godot: «la comunidad mantiene la plataforma, cualquiera puede hacer un fork, ninguna entidad controla las condiciones».
Para los componentes donde el lock-in es alto y el coste de salida extremo, el modelo de gobernanza es un criterio de evaluación de primer orden, no una nota al pie.
Lección 5: los cambios de precios revelan cómo ve una empresa a sus desarrolladores
Cómo gestiona una empresa sus precios te dice cómo entiende su relación con los desarrolladores. ¿Son socios cuyo éxito impulsa el de la plataforma? ¿O una audiencia cautiva a la que monetizar?
El anuncio inicial de Unity trató a los desarrolladores como audiencia cautiva. La rectificación, bienvenida, no cambió la señal. Que Unity siquiera lo intentara significa que alguien en la dirección aprobó cobrar retroactivamente por juegos ya publicados. Esa decisión no fue un accidente — fue una estrategia, revertida solo por la magnitud de la reacción.
Vigila estas señales en tus proveedores:
- Cambios de precios anunciados con plazos de aplicación muy cortos
- Condiciones que trasladan el riesgo del proveedor al cliente
- Eliminación de niveles gratuitos o de la oferta open source
- Adquisición por capital riesgo (que suele preceder a una monetización agresiva)
- Relevos en la dirección de perfiles de producto a perfiles financieros
Qué debería hacer un CTO ahora mismo
Estés o no en el sector del videojuego, el incidente de Unity es una invitación a auditar tus propias dependencias de plataforma.
- Lista tus dependencias críticas. Cada plataforma, framework, servicio en la nube y herramienta de la que depende tu producto.
- Clasifica cada una por nivel de lock-in. Bajo, medio o alto, según el coste de salida.
- Para las de lock-in alto, evalúa el riesgo de gobernanza. ¿Quién controla las condiciones? ¿Qué incentivos tiene? ¿Existe una alternativa open source?
- Documenta los costes de salida. Incluso una estimación gruesa es mejor que nada.
- Monitoriza los cambios de tus proveedores. Sigue sus blogs, sus páginas de precios y sus términos de servicio. Que no te pillen por sorpresa.
He visto lo que pasa cuando el riesgo de plataforma no se gestiona: proyectos de migración que se comen trimestres enteros de ingeniería porque nadie estimó el coste de salida a tiempo. La auditoría de arriba cuesta una tarde. Saltártela es la manera de que la actualización de precios de un proveedor se convierta en tu roadmap del año que viene.
¿Quieres ingenieros que piensen en el riesgo arquitectónico a largo plazo, no solo en las funcionalidades de hoy? Habla con un CTO — nuestros ingenieros senior de LATAM te ayudan a construir sistemas que no te encierran en decisiones de las que te arrepentirás.
