8 de septiembre de 2026 EN ES
The Startup Record Vol. 1 · N.º 37

Startup stories: launches, pivots, comebacks, and the shutdowns that teach

Illustration: AnkiDroid Postmortem: Keep Open-Source Apps Fundable
Análisis posteriores

Postmortem de AnkiDroid: Mantén las apps de código abierto financiables

La eliminación forzada de un enlace de donación es un fallo de la infraestructura de financiamiento, no un debate sobre política; aquí está la lista de verificación de la autopsia.

El dictamen del forense

Cuando una plataforma elimina un enlace de donación, la lesión inmediata parece una disputa sobre política. La lesión más profunda es la infraestructura de financiamiento. Un proyecto puede sobrevivir a una mala reseña, a una apelación lenta o a un cambio de política hostil. No puede sobrevivir a un corte silencioso a la única cuenta que paga el mantenimiento.

AnkiDroid es una app gratuita de tarjetas de estudio para Android, de código abierto, con más de 10 millones de instalaciones, utilizada en todo el mundo para diversos fines, principalmente en educación médica y aprendizaje de idiomas. Las donaciones de la app van a Open Source Collective, una organización sin fines de lucro de EE. UU. que actúa como su anfitrión fiscal y cuenta con una carta de determinación de la IRS que establece que está exenta de impuestos bajo 501(c)(6). No se vende nada en la app, y su Open Collective es la única fuente de financiamiento para el mantenimiento y el desarrollo.

Google rechazó las actualizaciones de AnkiDroid en Play Store a partir del 28 de agosto de 2026, y advirtió que AnkiDroid sería eliminada de Google Play el 11 de septiembre de 2026 en todas las regiones, excepto India y Rusia, si el problema no se resolvía. El soporte de Google le dijo a AnkiDroid que, tras revisar la documentación presentada, la app seguía violando la política de Pagos de Google. El proyecto dijo que se vio obligado a eliminar los enlaces de donación de su compilación de Play Store en la versión 2.24.X bajo protesta para continuar la distribución a la mayoría de los usuarios.

Esa secuencia es la autopsia. La causa de la muerte no fue que la app pidiera dinero. La causa de la muerte fue que el soporte vital de la app estaba conectado a una plataforma de distribución cuyas reglas de pago pueden cambiar sin el consentimiento del mantenedor.

Por qué importa la herida

El financiamiento de código abierto a menudo parece una elección moral: los usuarios donan porque valoran el trabajo. En la práctica, es un problema de fontanería. El enlace de donación es una tubería. La ficha de la tienda es una válvula. El anfitrión de pago es un reservorio. Si la válvula se cierra, el reservorio no ayuda a menos que la tubería pueda ser redirigida.

El problema del mantenedor no es que a los usuarios les haya dejado de importar. El problema del mantenedor es que el lugar más visible donde los usuarios pueden donar está controlado por una parte externa que puede decidir, en cualquier momento, que el enlace es una violación de la política. Ese es el riesgo de plataforma. No es un caso límite raro. Es la condición ordinaria de publicar en una plataforma cuyas reglas no son contratos que puedas leer, negociar o hacer cumplir de antemano.

Una app gratuita puede estar más expuesta que una app de pago. Una app gratuita con un enlace de donación externo no tiene una transacción que gravar, pero tampoco tiene un canal protegido. La plataforma puede tratar el enlace externo como un intento de eludir su sistema de pago, incluso cuando la app no vende nada. Esa asimetría es la trampa: la app es gratuita, por lo que la plataforma no tiene una participación de ingresos; la app se financia externamente, por lo que la plataforma aún puede decidir que el mecanismo de financiamiento está fuera de los límites.

La interpretación generosa es que la plataforma intenta mantener su ecosistema ordenado. La interpretación sin sentimentalismo es que el orden no es lo mismo que la justicia. Un mantenedor no debería tener que elegir entre perder la distribución y perder el financiamiento. Si un proyecto debe hacer esa elección, la arquitectura de financiamiento ya era frágil.

Lista de verificación de autopsia del enlace de financiamiento

Cada mantenedor de código abierto debería tratar la infraestructura de donaciones como equipo de emergencia. No basta con tener un enlace. Necesitas saber dónde está el enlace, quién puede desactivarlo y qué pasa cuando se desactiva.

  1. Inventario cada punto de donación. Lista cada lugar donde un usuario puede donar: ficha de la app en la tienda, pantalla de la app, sitio web, página del repositorio, perfil social, pie de correo electrónico, notas de versión y cualquier página de un socio. Marca cada punto como controlado por la plataforma o controlado por ti. Un enlace en la descripción de la tienda está controlado por la plataforma. Un enlace en tu propio sitio web está controlado por ti. Si el único punto controlado por ti está oculto, no es un respaldo; es una nota al pie.
  2. Marca la plataforma que puede revocarlo. Para cada punto controlado por la plataforma, escribe la regla que podría hacer desaparecer el enlace. No asumas que la regla es estable. No asumas que una apelación será rápida. La pregunta no es si la plataforma es razonable. La pregunta es si tu financiamiento sobrevive si no lo es.
  3. Prueba un respaldo independiente de la plataforma. El respaldo debe ser alcanzable sin el permiso de la plataforma. Una página del sitio web, una página de financiamiento del repositorio, un enlace de pago directo o una página alojada por la comunidad pueden funcionar. Pruébalo desde el punto de vista de un usuario: ¿puede un donante encontrarlo, entender qué financia y completar la donación sin pedir ayuda a la plataforma? Si el respaldo requiere que la plataforma lo muestre, no es un respaldo.
  4. Rehearsa la respuesta al retiro. Escribe la respuesta antes del incidente. Incluye el mensaje a los usuarios, el mensaje a la plataforma, el mensaje al anfitrión de pago y el mensaje a la comunidad. Decide quién lo publica, dónde se publica y cuál es la primera acción. Una respuesta ensayada no es una admisión de culpa. Es una manera de mantener vivo el proyecto mientras la disputa no se resuelve.
  5. Separa la distribución en la tienda de la infraestructura de financiamiento. La tienda puede ser la puerta principal. El proyecto debe mantener una manera para que los usuarios apoyen el mantenimiento fuera de la tienda, en lugar de depender de la tienda como el único lugar para explicar cómo se mantiene el trabajo.

La regla final es simple: si tu financiamiento depende del permiso de una plataforma para mostrar un enlace, no controlas tu financiamiento. Controlas tu código, tu documentación, tu comunidad y tus propias páginas. Construye la ruta de financiamiento allí, y trata la tienda como uno de muchos canales.

Publicidad