La revolta contra la «Runtime Fee» d'Unity: lliçons sobre risc de plataforma i confiança dels developers
El 12 de setembre de 2023, Unity Technologies va anunciar una nova «Runtime Fee»: un cobrament per cada instal·lació de joc — i retroactiu, aplicable a jocs ja desenvolupats i publicats. Els developers que havien triat Unity anys enrere, amb unes altres condicions, ara passarien a deure diners per cada instal·lació nova dels seus jocs.
La reacció va ser immediata. Els estudis van amenaçar de marxar. Godot va registrar pics de descàrregues i de finançament sense precedents. L'acció d'Unity va caure. Les amenaces van arribar a ser prou greus perquè l'empresa tanqués temporalment oficines. En pocs dies, Unity va fer marxa enrere parcialment, però la confiança, un cop trencada, no es repara amb una actualització de preus.
Jo no llegeixo aquesta història com una notícia de videojocs. La llegeixo des del seient de qui construeix: un cas d'estudi sobre dependència de plataforma, confiança en el proveïdor i les decisions que determinen si un canvi de preus és una molèstia o una amenaça existencial.
Deu dies de l'anunci a la disculpa
12 de setembre: Unity anuncia la Runtime Fee: un cobrament per instal·lació a partir de certs llindars (200.000 per a Personal, 1 milió per a Pro), aplicat a jocs ja publicats. Com recollia The Verge, els developers van fer notar que un joc free-to-play amb milions d'instal·lacions podia acabar devent a Unity més del que havia guanyat.
12-14 de setembre: La reacció esclata. La tarifa era retroactiva, es basava en instal·lacions que els developers no controlen (reinstal·lacions, dispositius nous, frau) i el mecanisme de recompte era opac.
13-15 de setembre: Godot, el motor de joc de codi obert de referència, viu un pic d'interès massiu. El Godot Development Fund va rebre una onada de donacions sense precedents. Els developers votaven amb els peus.
18-22 de setembre: Unity demana disculpes i anuncia revisions: res de retroactivitat per als subscriptors existents, possibilitat de triar entre un percentatge d'ingressos o la tarifa per instal·lació, i l'eliminació futura de la tarifa per a Unity Personal.
Però aleshores les converses de migració ja havien començat arreu del món. La pregunta ja no era el preu: era si es podia continuar confiant en Unity com a soci de plataforma.
Lliçó 1: els canvis retroactius destrueixen la confiança
El més perjudicial de l'anunci d'Unity no era la tarifa en si. Era que s'apliqués a projectes existents, construïts sota unes altres condicions.
Quan un developer va triar Unity fa tres anys, va prendre un compromís arquitectònic basat en les condicions d'aleshores. Base de codi, expertesa de l'equip, eines, pipeline de desplegament: tot específic d'Unity. La decisió ja era irreversible, i Unity ho sabia. Canviar les condicions retroactivament és explotar el lock-in.
La lliçó: quan avaluïs un proveïdor, les condicions actuals només són una part de l'equació. Analitza'n l'estructura d'incentius i la governança. Una empresa cotitzada que respon davant dels accionistes pot prendre decisions que perjudiquen els developers per quadrar els resultats trimestrals. Pregunta't: si aquest proveïdor canviés els preus demà, què ens costaria marxar?
Lliçó 2: el lock-in és un espectre, i has de saber on ets
No totes les dependències de proveïdor són iguals. Hi ha un espectre:
Lock-in baix: APIs estàndard, on canviar demana retocar la configuració però no reescriure codi. Canviar de proveïdor de correu, de CDN o d'eina de monitoratge.
Lock-in mitjà: APIs propietàries que obliguen a tocar codi per substituir-les. Serveis específics d'AWS com DynamoDB o Lambda. Setmanes o mesos de feina per migrar.
Lock-in alt: la teva aplicació està construïda sobre el runtime o el framework d'una plataforma. Canviar vol dir reescriure de zero. Un joc fet amb Unity, una aplicació de negoci sobre Salesforce.
Unity és a l'extrem de l'espectre. Un joc fet amb Unity no es pot portar a Unreal ni a Godot sense una reescriptura gairebé completa: física, renderitzat, scripting, pipeline d'assets — tot és específic d'Unity.
La lliçó per al lideratge d'enginyeria: fes el mapa de les teves dependències de proveïdor per nivell de lock-in. Per a les de lock-in alt, necessites proteccions contractuals sòlides o una estratègia de sortida creïble. «Ja ho resoldrem si passa» no és una estratègia.
Lliçó 3: el cost de sortida ha de pesar en les decisions d'arquitectura
Quan els arquitectes i els CTO avaluen una tecnologia, solen mirar el rendiment, l'experiència de developer, la maduresa de l'ecosistema, el mercat de talent i el cost. El que gairebé mai no avaluen és el cost de sortida.
El cost de sortida inclou l'esforç de reescriptura, la migració de dades, la formació de l'equip, la substitució d'eines i els terminis. Per als developers d'Unity, el cost de sortida era «reconstruir-ho de zero». Això no és una migració: és un projecte nou. I és exactament per això que Unity es va veure amb cor d'anunciar canvis retroactius.
L'acció pràctica: per a cada dependència crítica, documenta el cost de sortida. No cal un pla de migració detallat; n'hi ha prou amb una estimació aproximada. Si la resposta és «no podem marxar», això ha de constar al teu registre de riscos.
Lliçó 4: el codi obert no és gratuït, però capgira la dinàmica de poder
El pic d'interès per Godot després de l'anunci d'Unity no va ser casual. Els developers van fugir cap a Godot perquè és de codi obert: cap empresa no en pot canviar les condicions perquè cap empresa no el controla.
El codi obert no elimina tot el risc de plataforma — els projectes es poden abandonar i les comunitats es poden fragmentar —, però canvia de soca-rel la dinàmica de poder. Amb Unity: «accepta les nostres condicions o marxa». Amb Godot: «la comunitat manté la plataforma, qualsevol en pot fer un fork i cap entitat no en controla les condicions».
Per als components on el lock-in és alt i el cost de sortida és extrem, el model de governança és un criteri d'avaluació de primer ordre, no un detall que es mira al final.
Lliçó 5: els canvis de preus revelen com una empresa veu els seus developers
La manera com una empresa gestiona els preus et diu com entén la relació amb els seus developers. Són socis, l'èxit dels quals impulsa l'èxit de la plataforma? O són un públic captiu per monetitzar?
L'anunci inicial d'Unity els tractava com un públic captiu. La rectificació, tot i que benvinguda, no va canviar el senyal. Que Unity ho arribés a intentar vol dir que algú de la direcció va aprovar cobrar retroactivament per jocs ja publicats. Aquella decisió no va ser cap accident: era una estratègia, i només es va revertir per la pressió de la comunitat.
Vigila aquests senyals dels teus proveïdors:
- Canvis de preus anunciats amb terminis d'implantació molt curts
- Condicions que traslladen risc del proveïdor al client
- Supressió de plans gratuïts o d'ofertes de codi obert
- Adquisició per part d'un fons de capital privat (que sovint precedeix una monetització agressiva)
- Relleus a la direcció: d'executius orientats a producte a executius orientats a finances
Què haurien de fer els CTO ara mateix
Tant si et dediques als videojocs com si no, l'incident d'Unity és una invitació a auditar les teves pròpies dependències de plataforma.
- Llista les dependències crítiques. Totes les plataformes, frameworks, serveis al núvol i eines de què depèn el teu producte.
- Classifica-les per nivell de lock-in. Baix, mitjà o alt, segons el cost de sortida.
- Per a les de lock-in alt, avalua el risc de governança. Qui controla les condicions? Quins incentius té? Hi ha alternativa de codi obert?
- Documenta els costos de sortida. Fins i tot una estimació grollera és millor que res.
- Vigila els canvis dels teus proveïdors. Segueix-ne els blogs, les pàgines de preus i les condicions de servei. Que no t'agafin per sorpresa.
He vist què passa quan el risc de plataforma no es gestiona: projectes de migració que es mengen trimestres sencers d'enginyeria perquè ningú no havia avaluat el cost de sortida a temps. L'auditoria de dalt costa una tarda. Saltar-te-la és la manera com l'actualització de preus d'un proveïdor es converteix en el teu roadmap de l'any que ve.
Vols enginyers que pensin en el risc arquitectònic a llarg termini, i no només en les funcionalitats d'avui? Parla amb un CTO: els nostres enginyers sèniors de LATAM t'ajuden a construir sistemes que no et lliguin a decisions de què et penediràs.
