El estrecho digital: OpenAI y la captura de la infraestructura Python
analisisEn el Golfo Pérsico existe un paso de agua de 33 kilómetros de ancho por donde circula una quinta parte del petróleo mundial. Se llama Ormuz. Quien controla ese estrecho controla el flujo energético de media humanidad sin necesidad de producir una sola gota de crudo. No necesita ser productor. Le basta con ser portero.
La infraestructura digital tiene sus propios estrechos. Pasos angostos por donde circula, sin que nadie los note, casi todo lo que se construye con una tecnología dada. No son cables submarinos ni centros de datos. Son las herramientas que usás todos los días para hacer tu trabajo: el gestor de entornos, el linter, el verificador de tipos. Las piezas que instalás una vez y que después usás como si fueran parte del lenguaje mismo. Pocos las cuestionan. Nadie las vota. Pero quien las controla, controla indirectamente lo que se construye con ellas.
Astral: las tuberías que nadie ve
Astral es una startup fundada por Charlie Marsh —el mismo creador de Ruff— que en tres años construyó tres herramientas que se convirtieron en el estándar de facto del desarrollo Python. Se llaman uv, ruff y ty. Las tres están escritas en Rust, compiladas como binarios nativos, y se publican como paquetes Python en PyPI. Cuando hacés pip install uv, no estás instalando una dependencia Python con su árbol de subdependencias. Estás descargando un binario Rust que no arrastra absolutamente nada.
uv reemplaza a pip, venv, poetry y pip-tools. Gestiona entornos virtuales, resuelve dependencias y instala paquetes en una fracción del tiempo que tardaba el ecosistema tradicional. ruff reemplaza a flake8, black, isort y medio centenar de herramientas más: linting, formatting y organización de imports en un solo binario. ty, el más reciente, apunta a reemplazar mypy como verificador de tipos estáticos.
La tripleta no tiene dependencias Python (cero forward dependencies). No dependen de nadie. Pero el ecosistema Python depende de ellas.
Los números: de herramienta a infraestructura
El paso de “herramienta útil” a “infraestructura indispensable” no se anuncia. Se mide en descargas. La siguiente gráfica muestra la evolución mensual de las descargas de las tres herramientas Astral —uv, ruff y ty (líneas sólidas gruesas)— frente a sus competidores directos (líneas punteadas finas): poetry, pipenv y pdm como gestores de entornos; flake8, pylint, black e isort como linters/formatters; y mypy y pyright como verificadores de tipos. Los datos provienen del dataset público de BigQuery PyPI y cubren de septiembre de 2024 a marzo de 2026. La escala importa: no estamos hablando de miles ni de cientos de miles. Estamos hablando de decenas y hasta centenas de millones de descargas mensuales.
uv arrancó septiembre de 2024 con ~80 millones de descargas mensuales y cerró el periodo cerca de ~130 millones. ruff pasó de ~140 a ~185 millones en el mismo lapso. ty, más reciente, muestra una curva de adopción más baja pero con pendiente ascendente. Frente a ellos, poetry se mantiene estable alrededor de ~25M, black cerca de ~40M, y el resto de competidores fluctúa entre ~2 y ~15M —números que palidecen ante el volumen de Astral. La tendencia es inequívoca: crecimiento exponencial con desaceleración, el perfil clásico de una tecnología que entra en fase de consolidación.
Para ponerlo en perspectiva: uv supera en descargas a la suma de poetry, pipenv y pdm. ruff duplica a black y triplica a flake8. La gráfica lo hace visible: las líneas sólidas de Astral corren en una banda superior propia, mientras las punteadas de los competidores se quedan abajo, relativamente planas. Cuando una herramienta nueva desplaza a toda una categoría de herramientas establecidas, dejás de hablar de adopción y empezás a hablar de captura de infraestructura.
El grafo de influencia: poder sin depender
El análisis de supply chain clásico te diría que para medir el poder de un paquete hay que mirar qué depende de él. Cuántos paquetes tienen tu nombre en su requires.txt. Más dependientes, más poder. Es la lógica de numpy, de requests, de las librerías que todos importan porque todos dependen de ellas.
Astral no juega en ese tablero. uv, ruff y ty tienen cero dependencias Python forward. Su grafo de dependencias está vacío. Si las medís por la métrica tradicional, son irrelevantes. Pero la métrica tradicional mide dependencia de runtime, no influencia de desarrollo. El poder de Astral no viene de quién depende de sus paquetes. Viene de quién los adopta como herramientas de desarrollo.
Para visualizar esto construí un grafo de influencia basado en dependencias inversas: no quién depende de uv, sino quién lo usa como herramienta de desarrollo. Usando GitHub Code Search, busqué repositorios que contienen configuraciones de ruff en .pre-commit-config.yaml, referencias a uv en pyproject.toml y configuraciones de ty. Los nodos violeta son los paquetes de Astral. Los grises son los adoptantes.
Lo que muestra el grafo es la inversión del patrón habitual de poder en un ecosistema de software. Los nodos más centrales no son los que más dependencias tienen, sino los que más adoptantes concentran. Ruff emerge como el nodo con mayor centralidad: proyectos de primer nivel del ecosistema —FastAPI, Flask, PyTorch, scikit-learn, Pydantic y Transformers, entre muchos otros— lo usan como herramienta de desarrollo. uv, por su parte, aparece en un número creciente de proyectos como gestor de entornos, desplazando a poetry y a pip-tools.
La forma del grafo cuenta una historia precisa: Astral es un nodo distribuidor. No está conectado a las ramas del árbol de dependencias, sino a su tronco. No necesita que nadie dependa de él en producción. Le basta con que todos lo usen para construir. Es la diferencia entre ser una pieza del motor y ser la llave que arranca el auto. La llave no se mueve con el vehículo, pero sin ella el vehículo no arranca.
La compra: consolidación vertical sin necesidad de prohibir
El 19 de marzo de 2026, OpenAI anunció un acuerdo para adquirir Astral —pendiente de aprobación regulatoria—. La reacción en la comunidad Python fue mixta: alivio por los recursos de OpenAI y la promesa de mantener uv gratuito, pero preocupación por la gobernanza del proyecto y el precedente de concentración vertical. Las licencias permisivas (MIT) mitigaron parcialmente el temor. Pero el alivio confunde la pregunta. La pregunta relevante no es si OpenAI va a hacer que uv deje de ser gratuito. Es qué significa que una empresa que construye los modelos de IA más influyentes del mercado también controle las herramientas con las que los desarrolladores construyen todo lo demás.
Es consolidación vertical pura. OpenAI no busca adquirir Astral por su tecnología. Busca consolidar la posición de Astral en el ecosistema. Una empresa que ya provee la capa de modelos (GPT, o1, o3) ahora provee también la capa de herramientas de desarrollo. No necesita prohibir que uses herramientas de la competencia. No necesita cambiar las APIs. No necesita hacer nada hostil. Le basta con optimizar la integración entre sus modelos y sus herramientas. Que uv funcione un poco mejor con los servicios de OpenAI. Que ruff tenga reglas que favorezcan los patrones de código que sus modelos generan. Que ty integre verificación de tipos con sugerencias del asistente de código. Nada de eso es malicioso por sí mismo. Cada paso individual es una mejora legítima. La suma de todos los pasos es un estrecho.
El poder, en este caso, no desciende desde arriba —como lo describía Foucault cuando analizaba las instituciones disciplinarias—. Emerge desde la base misma del flujo de trabajo. No es el poder de prohibir. Es el poder de hacer que ciertos caminos sean más fáciles que otros sin que nadie perciba la desviación. Es lo que Deleuze llamaba la sociedad de control: no hay muros ni encierros, solo ajustes imperceptibles que canalizan el comportamiento en una dirección.
Licencias: lo que sabemos y lo que no
Las tres herramientas usan licencias permissivas: MIT para ruff y ty; dual MIT/Apache-2.0 para uv. La licencia MIT es la más abierta que existe en el software. Permite uso comercial, modificación, distribución y sublicenciamiento con prácticamente ninguna restricción. Apache-2.0 añade protección contra patentes, lo cual es relevante pero no restrictivo.
Astral es el primer proyecto open source prominente que OpenAI busca adquirir, de modo que no hay precedente sobre cómo gestionará licencias de código abierto. Su patrón ha sido otro: no cerrar el código, sino cerrar los modelos. Progresivamente, versiones tras versión, los modelos que alguna vez fueron open-source se volvieron closed-source o se publicaron con licencias restrictivas. El código de Astral probablemente siga siendo MIT por años. Pero el riesgo no reside en la licencia. Reside en la posición.
La historia reciente del software libre ofrece un mapa de lo que pasa cuando una empresa cambia las reglas: Elasticsearch pasó de Apache 2.0 a dual SSPL + Elastic License y AWS impulsó el fork OpenSearch. Redis migró de BSD 3-clause a dual SSPL + licencia propietaria y la comunidad creó Valkey. Terraform migró de MPL a BSL y nació OpenTofu. En cada caso, el código fue libre lo suficiente para que la comunidad pudiera bifurcarlo. Pero bifurcar uv o ruff significaría competir contra una versión respaldada por OpenAI, integrada con sus modelos, optimizada para sus servicios. La licencia permite la bifurcación. La posición hace que la bifurcación sea, en la práctica, irrelevante.
El estrecho
El Estrecho de Ormuz tiene 33 kilómetros de ancho. El estrecho digital que Astral representa no tiene una medida física, pero su efecto es análogo: concentra el flujo de toda una actividad —el desarrollo Python— en un punto de paso único. Quien controla Ormuz no produce petróleo, pero decide si el petróleo circula. Quien controla las herramientas base del desarrollo Python no escribe la mayoría del código que se produce, pero decide con qué se escribe, cómo se valida y qué formas se normalizan.
La infraestructura no necesita ser visible para ser poderosa. De hecho, funciona mejor cuando es invisible. Cuando nadie piensa en ella. Cuando pip install uv es tan automático como respirar. Ahí, en ese punto exacto de invisibilidad, es donde se produce la captura.
La disputa por la infraestructura no es exclusiva del plano digital. Se replica dondequiera que exista un sistema vital cuyo control determine lo que se puede o no se puede hacer. En el Golfo Pérsico, se disputa con destructores y misiles. En las clínicas de zonas marginadas de México, se disputa con vacunas que no llegan y desinformación que sí.
Sarampión en México: cuando la infraestructura se colapsa →
Fuentes y metodología
Datos de descargas: Google BigQuery, dataset bigquery-public-data.pypi.file_downloads. Consulta de 18 meses (septiembre 2024 - marzo 2026), filtrando por file.project para 12 paquetes: uv, ruff, ty (Astral) y poetry, pipenv, pdm, flake8, pylint, black, isort, mypy, pyright (competidores). Proyecto GCP: opencode-491200. Las cifras reflejan variación mensual: uv ~80-130M, ruff ~140-185M.
Dependencias inversas: GitHub Code Search, consultando referencias a ruff en .pre-commit-config.yaml, uv en [tool.uv] de pyproject.toml, y ty en configuraciones de pyproject.toml. Nota: GitHub Code Search requiere autenticación para resultados completos; los datos usados incluyen un fallback hardcodeado validado contra los resultados disponibles.
Licencias: Repositorios oficiales de Astral en GitHub (astral-sh/uv, astral-sh/ruff, astral-sh/ty).
Grafo de influencia: Construido con NetworkX, combinando datos de dependencias directas (PyPI JSON API, requires_dist) con datos de adopción (GitHub Code Search). Los nodos violeta representan paquetes Astral; los grises, adoptantes del ecosistema.
Análisis de adopción: Propio, basado en datos de BigQuery PyPI. Los notebooks de investigación están disponibles en el repositorio del proyecto.