React y la lección de mantener a alguien durante 10 años

Un dev publicó en Hacker News que paga la educación de una persona en la zona rural de Tanzania desde hace 10 años. No fue una sola donación, ni una campaña viral. Fue un pago mensual, durante una década. Leí el Tell HN y pensé en algo que parece no tener ninguna relación: el node_modules de mi último proyecto React.

Tranquilo, ya lo explico. Esto no es un post de autoayuda. Tiene que ver con la forma en que consumimos el trabajo de otros sin pensar en el largo plazo.

Qué cuenta el Tell HN, al final

La idea es simple. Una persona decidió pagar los estudios de alguien que no podía costearlos. Lo mantuvo durante 10 años. En los comentarios, la discusión fue a donde siempre va en HN: si vale la pena ayudar a alguien directamente o donar a una institución, cómo medir el impacto, el riesgo de crear dependencia, si la dinámica de poder se vuelve rara.

No voy a entrar en ese debate. Quien es dev y lee eso suele fijarse en otra cosa: lo que cuenta es la duración, no el monto. Una donación grande una sola vez no paga diez años de escuela. Lo que los paga es un compromiso pequeño, aburrido y constante.

Y ahí entra React.

Por qué esto tiene que ver con React

Tu app React depende de cientos de paquetes. Corre esto:

npm ls --all | wc -l

En un proyecto Next.js recién creado, ese número ya pasa fácil de unos cientos de líneas. En una app de verdad, con formularios, data fetching, i18n, tests y lint, llega a miles.

React en sí tiene a Meta detrás. Pero el resto no. La lib de formularios, el parser de fechas, el plugin de Babel que alguien escribió en 2017, el polyfill que ni sabes que existe. Mucho de eso lo mantiene una persona o dos, en su tiempo libre.

Ya vimos lo que pasa cuando ese compromiso se rompe:

• left-pad (2016): un dev quitó 11 líneas de npm y media internet dejó de buildear, incluidos proyectos con React y Babel.
• colors.js y faker.js (2022): el mantenedor, cansado de trabajar gratis para grandes empresas, saboteó sus propios paquetes.
• core-js: el autor pasó años contando en público que el proyecto, usado por una porción enorme de la web, apenas le pagaba las cuentas.

Ninguno de estos casos fue por falta de buen código. Fue por falta de alguien sosteniendo el otro extremo durante el tiempo suficiente.

El software no muere por un bug. Muere cuando la última persona a la que le importaba se cansa.

Qué cambia en tu flujo de trabajo

No te voy a pedir que patrocines a todo el mundo. No se puede, y no resuelve nada. Pero sí se puede cambiar el modo "consumo infinito" por algo más adulto. En la práctica, hago tres cosas.

1. Descubrir a quién llevas a cuestas.

npx npm-fund
# o simplemente
npm fund

El npm fund lista los paquetes de tu proyecto que tienen link de financiamiento (GitHub Sponsors, Open Collective). La primera vez que lo corrí en un proyecto React de un cliente, aparecieron decenas de nombres. De muchos nunca había oído hablar. Todos estaban en producción.

2. Elegir pocos y mantenerlos por mucho tiempo.

La lección del Tell HN es exactamente esa. Mejor 5 dólares al mes para un mantenedor durante años que 100 dólares una vez en un momento de culpa. Un mantenedor planifica su vida con ingresos predecibles, igual que nosotros. Un patrocinio recurrente pequeño vale más que un pico aislado.

Si trabajas en una empresa, la conversación es otra. Toma la lista del npm fund, filtra las libs críticas (las que, si desaparecieran, trabarían el deploy) y llévasela a tu jefe. Un monto fijo al mes para tres o cuatro proyectos cuesta menos que una hora de incidente.

3. Pagar con tiempo cuando no se puede pagar con dinero.

Contribuir no es solo hacer PRs de features. Responder issues repetidas, mejorar un ejemplo en la documentación, reproducir un bug con un CodeSandbox mínimo. Para quien mantiene una lib React con 2 mil issues abiertas, un bug bien reproducido vale oro.

"Pero yo no gano en dólares"

Esa objeción es justa y la escucho siempre. La mayoría de los devs en Brasil cobra en reales, y 5 dólares al mes duelen más aquí que en San Francisco.

Tres respuestas honestas:

• No necesitas empezar por el dinero. El tiempo y el cuidado cuentan, como dije antes.
• Si eres freelancer o tienes empresa, agrega una línea en el presupuesto del proyecto. Un pequeño porcentaje para las dependencias críticas. El cliente ni lo nota, y su proyecto queda más seguro.
• Patrocinar a mantenedores de tu propio país también vale. Hay mucha gente buena manteniendo herramientas usadas en el ecosistema React.

Y hay un lado egoísta que no me da vergüenza admitir: una lib financiada es una lib que no te deja tirado en medio de una migración a React 19.

Lo que pienso de verdad

Mi opinión fuerte: el ecosistema JavaScript creó la cultura de tratar las dependencias como un recurso natural. Como el agua que sale del grifo. Instalas, usas, olvidas. Cuando se rompe, abres una issue enojado exigiéndole algo a un desconocido que nunca te cobró nada.

El Tell HN me incomodó de una buena manera porque muestra lo contrario. Una persona miró un problema largo y aceptó que la solución también sería larga. Sin fotos, sin anuncios, sin hype. Diez años de constancia.

Nos gusta hablar de arquitectura que escala. Poca gente habla de compromiso que escala en el tiempo. Y el tiempo es justamente la variable que más proyectos open source tumba. La versión 1.0 sale con entusiasmo. La 4.2.7, que corrige un edge case en Safari, sale con terquedad.

Parte del humor involuntario de todo esto: pasamos una tarde decidiendo entre Zustand y Jotai, comparamos el bundle size en kilobytes, leemos benchmarks de tres blogs. Y nunca dedicamos ni un minuto a ver si la lib elegida tiene a alguien que va a seguir ahí dentro de dos años. Ese debería ser el primer criterio.

Un checklist corto antes de instalar la próxima lib

Antes de hacer npm install de algo que va a producción, reviso:

• Cuántos mantenedores activos tiene el repositorio (pestaña Contributors, últimos 12 meses).
• Si las issues reciben respuesta, aunque sea un "no lo voy a hacer".
• Si existe algún financiamiento, aunque sea pequeño.
• Si la lib depende de otras diez libs de una sola persona.

No es ciencia. Es solo no ser ingenuo.

Para cerrar

No estoy diciendo que patrocinar una lib React sea igual a pagar la escuela de alguien. Son cosas de pesos muy distintos, y compararlas sería una falta de respeto con la historia del post. Lo que ambas tienen en común es más simple: las cosas que importan necesitan a alguien dispuesto a aparecer todos los meses, incluso cuando nadie está mirando.

Elige un proyecto. Solo uno. Apóyalo durante un año y mira qué cambia. Si quieres ver lo que ando construyendo con estas mismas libs, échale un vistazo a mis proyectos.

Un dev paga la escuela de una persona en Tanzania desde hace 10 años. Todos los meses, sin fotos y sin anuncios.

Lo leí en Hacker News y pensé en el node_modules de mi último proyecto React.

Cientos de paquetes en producción, muchos mantenidos por una o dos personas en su tiempo libre. left-pad, colors.js y core-js mostraron lo que pasa cuando ese extremo se suelta.

El software no muere por un bug. Muere cuando la última persona a la que le importaba se cansa.

La lección que saqué: la constancia vale más que el monto. 5 dólares al mes durante años ayudan más que 100 en un momento de culpa.

Corre un npm fund en tu proyecto, elige una lib y apóyala durante un año. Escribí más sobre esto en el blog, el link está en los comentarios.

#CodigoAbierto #React #JavaScript #DesarrolloDeSoftware #Comunidad