Retiro voluntario en Microsoft: lo que enseña Bun

Microsoft ofreció un programa de retiro voluntario a más o menos un cuarto de la empresa. La noticia salió en el Seattle Times. Y no pasó en una empresa en crisis. Pasó en la dueña de VS Code, TypeScript, GitHub y npm. Al mismo tiempo, Bun, un runtime JavaScript hecho por un equipo que cabe en una sala de reuniones, sigue lanzando versión tras versión. Este texto no va de chismes corporativos. La pregunta es otra: qué dicen Microsoft y Bun, uno al lado del otro, sobre cómo deberías trabajar y elegir herramientas.

Lo que anunció Microsoft

Un retiro voluntario no es lo mismo que un despido masivo. La empresa no echa a nadie de entrada. Pone un paquete sobre la mesa y deja que cada persona decida si lo acepta. En la práctica, el efecto es parecido: menos gente en la nómina, pero con menos titulares negativos.

El tamaño llama la atención. Un cuarto de una empresa con más de 200 mil empleados son decenas de miles de personas recibiendo la misma propuesta. No todos van a aceptar. Pero nadie le ofrece esto a tanta gente si no quiere achicarse de verdad.

El motivo de fondo no es un secreto para quien sigue el sector. Las big tech están metiendo miles de millones en data centers e IA. Ese dinero sale de algún lado. Y la apuesta es que un equipo más chico, con mejores herramientas, entrega lo mismo o más.

Por qué Bun entra en esta conversación

Bun es la prueba viva de la tesis que Microsoft intenta comprar con recortes.

Piensa en lo que ofrece:

• runtime JavaScript y TypeScript
• gestor de paquetes
• bundler
• test runner
• APIs nativas para SQLite, Postgres, S3 y servidor HTTP

En el ecosistema Node, cada punto de esta lista es un proyecto aparte. Lo mantiene gente distinta, con configuración distinta. En Bun, es un solo binario. Y quien lo hizo nunca fue un equipo de miles. Fue un grupo pequeño, liderado por Jarred Sumner, que a finales de 2025 terminó comprado por Anthropic justamente porque ese tipo de apalancamiento vale oro.

El tamaño del equipo nunca fue una métrica de entrega. El apalancamiento sí.

Microsoft tiene gente para mantener diez productos que hacen lo mismo. Bun no. Así que tuvo que ser opinado, recortar capas y escribir en Zig con un foco brutal en el rendimiento. La restricción se volvió estrategia.

Qué cambia en tu proyecto en la práctica

Dejemos la tesis y vamos al código. Un proyecto Node típico de 2023 tenía un package.json así:

{
  "scripts": {
    "dev": "tsx watch src/index.ts",
    "build": "tsup src/index.ts",
    "test": "vitest run"
  },
  "devDependencies": {
    "tsx": "^4.0.0",
    "tsup": "^8.0.0",
    "vitest": "^2.0.0",
    "typescript": "^5.0.0"
  }
}

Cuatro dependencias solo para ejecutar, empaquetar y testear. Cada una con sus propios mantenedores, su propio ciclo de releases y sus propios issues abiertos.

En Bun, el mismo flujo queda así:

{
  "scripts": {
    "dev": "bun --watch src/index.ts",
    "build": "bun build src/index.ts --outdir dist --target bun",
    "test": "bun test"
  }
}

Menos cosas que actualizar. Menos node_modules. Menos superficie para un ataque de supply chain, algo que en 2026 ya dejó de ser cosa de paranoicos.

No digo que migres todo mañana. Digo que la pregunta "¿cuántas herramientas necesito para hacer esto?" se volvió más importante que "¿cuál es la herramienta más popular?".

¿Y el riesgo de depender de un equipo pequeño?

Esta es la objeción honesta, y merece respuesta.

Un proyecto pequeño tiene un bus factor bajo. Si el mantenedor principal desaparece, el proyecto puede morir. Eso es real. Mucha gente miró a Bun con desconfianza por este motivo, y no estaba equivocada.

Pero la noticia de Microsoft muestra el otro lado: una empresa grande tampoco es garantía. Cuando una big tech le ofrece la salida a un cuarto de su equipo, equipos enteros cambian de dueño. Un producto que tenía cinco personas dedicadas pasa a tener una, repartida entre otras tres prioridades. No te enteras por el blog oficial. Te enteras cuando el issue que abriste pasa seis meses sin respuesta.

Ya vi esto pasar con herramientas de empresas grandes que todos creían eternas. ¿Te acuerdas de Atom? Era de GitHub, que era de Microsoft. Lo archivaron en 2022. El argumento "es de una empresa grande, así que es seguro" nunca fue tan sólido como parecía.

El criterio que uso hoy es más simple:

1. ¿El proyecto tiene licencia abierta y un código que alguien pueda forkear?
2. ¿Sigue estándares de la web (Fetch, Request, Response, Web Streams) o inventa su propia API?
3. Si muere mañana, ¿cuánto de mi código tiene que cambiar?

Bun sale bien parado en el punto 2. Buena parte de lo que escribes en él corre en Node, Deno o en un Worker con poca adaptación. Ese es el seguro de verdad. La razón social del mantenedor no lo es.

El mensaje para quien escribe código

Hay un lado de esta noticia que incomoda, y no sirve fingir que no. Si Microsoft cree que puede funcionar con bastante menos gente, otras empresas van a copiarla. Algunas lo harán sin tener las herramientas para eso, y el resultado será un equipo sobrecargado y un producto peor. Pero la dirección ya está marcada.

El dev al que le va bien en este escenario es el que genera apalancamiento. No es quien teclea más rápido. Es quien:

• elimina herramientas que no necesitan existir
• automatiza lo repetitivo, con o sin IA
• entiende el sistema completo, de la base de datos al front, en lugar de una sola capa
• puede poner algo en producción solo cuando hace falta

Bun es un gran ejemplo justamente porque nadie ahí intentó ser enorme. Intentaron ser eficientes. La diferencia parece pequeña, pero lo cambia todo a la hora de decidir qué construir.

Y vale el recordatorio: la productividad no es excusa para que una empresa recorte gente y le cargue el trabajo de tres a una sola persona. Una cosa es una herramienta mejor que te libera tiempo. Otra es una planilla que decide que ahora haces el trabajo del compañero que se fue. Lo primero es progreso. Lo segundo es solo un recorte con nombre bonito.

Mi opinión

Microsoft no se equivoca al apostar a que los equipos más pequeños pueden rendir más. Bun lo demuestra todos los días. El error sería creer que basta con sacar gente y listo. Bun no se volvió rápido por tener poca gente. Se volvió rápido porque esa poca gente eligió muy bien qué no hacer.

Para ti, el mensaje práctico es parecido. Mira tu package.json hoy. Cuenta cuántas herramientas hay ahí solo porque "siempre fue así". Probablemente puedas recortar un par. Y si quieres ver cómo vengo aplicando esta idea en proyectos reales, échale un vistazo a mis proyectos.

---

No pude abrir la nota del Seattle Times (se denegó el permiso de WebFetch). Así que el texto usa solo lo que dice el título: la oferta a cerca de un cuarto del equipo. No incluye plazos, montos del paquete ni citas. "Más de 200 mil empleados", Atom archivado en 2022 y la compra de Bun por Anthropic salieron de mi memoria. Conviene verificar estos datos antes de publicar.

Microsoft ofreció retiro voluntario a cerca de un cuarto de la empresa. Y no está en crisis.

Mientras tanto, Bun sigue lanzando versión tras versión con un equipo que cabe en una sala de reuniones.

La lección que saco de esto: lo que define la entrega es el apalancamiento, no el tamaño del equipo.

Ser de una empresa grande tampoco garantiza nada. Atom era de GitHub y lo archivaron igual.

Hoy me pregunto: ¿cuántas herramientas hay en mi package.json solo porque "siempre fue así"?

Escribí sobre esto en el blog. Si quieres conversar, escríbeme.

#JavaScript #Bun #DesarrolloDeSoftware #Productividad #Tecnología