Hoy, 13 de septiembre de 2026, el proyecto Colibri publicó su release 1.11.0. La nota que acompaña al merge lo dice sin aspavientos: "Fifty-six pull requests since v1.10.2". Cincuenta y seis. En siete días. Y ese no es ni siquiera el dato más llamativo del paquete: un motor de inferencia escrito en C puro acaba de sumar su novena familia de modelos, cerró cinco bugs reales en cuatro engines, y ahora compila en plataformas —Windows UCRT64, musl— que antes ni siquiera formaban parte de su integración continua.
Pero el número que me interesa de verdad no aparece en el changelog, y no se puede compilar. Detrás de esos 56 pull requests hay un maintainer y 138 personas que, en su enorme mayoría, jamás se han escrito un mensaje entre sí. No trabajan en la misma empresa. No viven en la misma ciudad, ni probablemente en el mismo continente. Muchos no hablan el mismo idioma. Y sin embargo, esa semana, 56 de sus aportes convergieron en el mismo repositorio, compilaron juntos, y salieron al mundo como un motor capaz de correr modelos de frontera en el hardware que ya tienes.
Este artículo no es sobre los 56 pull requests. Es sobre lo que los hace posibles — y sobre por qué ese mecanismo, invisible, es la noticia más importante de la semana para quien todavía cree que la inteligencia artificial es un club privado.
Un proyecto open source no avanza rápido por dinero, ni por tamaño de equipo, ni por tener una marca detrás. Avanza rápido cuando existe una misión lo bastante clara para que gente que no se conoce trabaje como si se conociera. Y se sostiene cuando existe una persona dispuesta a mantener el estándar mientras todos los demás entran y salen.
Colibri es la prueba viva de las dos cosas a la vez: 74 días de vida, 138 contribuidores, cero presupuesto, 17 releases — y la frontera de la IA un paso más cerca de quien no puede pagarla.
1. La velocidad, medida
Antes de la teoría, los números. Verificados hoy contra la API del repositorio, sin redondear a favor:
| Métrica | Valor |
|---|---|
| Vida del proyecto | 74 días (primer commit el 1 de julio de 2026) |
| Estrellas | 29.202 — unas 395 por día, desde el principio |
| Forks | 3.190 |
| Commits | 2.228 — unos 30 por día |
| Pull requests mergeados | 799 (de 975 abiertos) — unos 11 por día |
| Contribuidores | 138 |
| Releases publicadas | 17 — una cada ~4,4 días |
| Familias de modelos soportadas | 9 (la última, DeepSeek V4.1 Flash) |
| Este release | 56 PRs en 7 días — unos 8 por día, solo en la última semana |
Frena un segundo en la fila de las releases. Diecisiete versiones en setenta y cuatro días. Una cada cuatro días y medio. Para dimensionarlo: hay proyectos corporativos, con decenas de ingenieros pagados a tiempo completo, que consideran un logro razonable sacar una release estable por trimestre. Colibri publica una por semana corta — y sin nadie a quien facturarle las horas.
Y no son releases vacías, de esas que solo suben un número. La 1.11.0 agregó un motor nuevo completo —DeepSeek V4.1 Flash, 552 mil millones de parámetros corriendo desde un SSD en una máquina sin GPU dedicada—, arregló cinco bugs reales repartidos en cuatro engines, y —esto es lo que más importa— sumó plataformas a su integración continua: ahora los tests compilan contra musl y contra Windows UCRT64. No marcó casillas. Entregó capacidad.
Hay un último dato que ordena todo lo que viene, porque es casi absurdo: el archivo comprimido de este release para Linux pesa 2,1 megabytes. Dos megabytes —menos que una foto de teléfono— para un motor que corre modelos de billones de parámetros. Colibri parte de una idea que está escrita en su propio README y que resume su tesis mejor que cualquier explicación de marketing:
Es decir: la capacidad no se guarda en memoria cara que hay que comprar; se prepara y se trae desde donde ya está —el disco— en el momento exacto en que se necesita. De esa idea nace todo: del hecho de que un modelo gigantesco puede correr en el hardware que ya tienes si el motor es lo bastante inteligente. Y de esa idea nace, también, la comunidad que la sostiene.
Casi todos los artículos sobre proyectos como este celebran los números y siguen de largo. La pregunta interesante es la contraria: ¿cómo es posible que esto funcione? No hay una empresa detrás. No hay una ronda de inversión. No hay un equipo contratado. ¿Qué sostiene una cadencia de 56 pull requests por semana en un proyecto que nació hace dos meses y medio? La respuesta no está en el dinero. Está en dos cosas que casi nunca se combinan.
2. El motor detrás del motor: una persona
Detrás de Colibri hay un nombre, y conviene ponerle rostro, porque hace comprensible todo lo demás: Vincenzo Fornaro, en GitHub @JustVugg. Su propia biografía lo resume mejor que cualquier nota de prensa:
Los números cuentan de él: 1.193 commits. Es decir, poco más de la mitad de todo el proyecto —un 54%— pasó por sus manos. Revisó y mergeó casi todos los pull requests de los otros 137. Respondió los issues. Cortó los releases. Y, sobre todo, sostuvo el estándar.
Porque hay un detalle que revela algo mucho más importante que la cantidad de commits: la calidad con la que se decidió cada merge. Ese release de 56 PRs no se publicó porque "ya andaba". El propio texto del PR lo deja explícito: se mergeó solo después de verificar token-exactness contra una referencia en CPU, comprobar que cada engine compila, y hacer pasar una suite de 883 tests de Python más los tests en C. Y el proceso tiene disciplina de quirófano:
» make test-c → verde
» pytest (suite Python) → verde (883 tests)
» cada engine → compila
» CHANGELOG → cita exactamente los 56 merges
de la ventana, ninguno de antes
» main → protegido: el release se mergea con --admin
» tag v1.11.0 → se pushea solo despuésEso no es entusiasmo. Es rigor. Y es la diferencia entre un proyecto que crece rápido y uno que crece rápido y no se rompe. Cualquiera puede abrir issues y mandar PRs; sostener la vara alta mientras 138 personas distintas empujan en direcciones distintas es un trabajo que casi nadie hace, y que no se ve en ninguna métrica de vanidad.
Lo fácil, con 56 PRs esperando, sería bajar el estándar para ir más rápido. Vincenzo hace lo contrario: exige más a medida que el proyecto crece. En este release hay un ejemplo perfecto — construyeron dos formas distintas de esconder las lecturas de expertos para acelerar el motor, las midieron, dieron peor, y las borraron. Y lo dejaron escrito con los números: "Two ways… were built, measured worse, and removed; both are documented with the numbers." Un proyecto que documenta sus fracasos no está vendiendo: está construyendo. Y eso, para los otros 137, es una invitación a confiar.
3. La parte que no se ve: la comunidad invisible
Y acá llega la parte que más me gusta, y que en este proyecto es literalmente cierta. Aquellos ~1.000 commits que no firmó Vincenzo —la otra mitad del proyecto— vienen de 137 personas. Nadie las contrató. Nadie les pagó. La gran mayoría nunca le escribió un mensaje a las otras.
Mira la forma que tiene esa comunidad:
| Contribuidor | Commits | Quién es |
|---|---|---|
| @JustVugg | 1.193 | El maintainer. El centro gravitacional. |
| @ZacharyZcR | 164 | Segundo en el ranking — y probablemente jamás habló con el primero. |
| @monotophic | 114 | Un desconocido para todos los demás. |
| @steve-m | 60 | Idem. |
| @woolcoxm | 55 | Idem. |
| @terrizoaguimor | 40 | Idem. |
| @kreuzzelg | 36 | Coautor del tier de GPU para qwen36. |
| …y 131 más | … | La cola es mucho más larga que la cabeza. |
Y esto no es un dato de vanidad: es la prueba de un mecanismo. Cuando un proyecto logra que casi la mitad de su trabajo provenga de gente no remunerada, no está haciendo caridad ni marketing. Está aprovechando algo que ninguna nómina puede comprar: el deseo genuino de muchísimas personas de que las cosas existan. Nadie te paga por arreglar un bug en un motor de inferencia a las 2 de la mañana. Lo hacés porque querés que ese motor sea mejor.
Este release lo muestra en miniatura. En las notas de la 1.11.0 aparecen quince handles distintos, cada uno dueño de una pieza:
- @crichalchemist — cerró una fuga en el tier de GPU de qwen36, donde los expertos liberados seguían subiéndose a la placa.
- @njloof — encontró y arregló un segfault de Metal al cargar pesos crudos en f32.
- @trigger2k20 — aportó un camino opcional a Metal para los expertos ruteados de GLM-5.3 en Apple Silicon.
- @kreuzzelg — hizo que el trunk denso de qwen36 se coloque solo, y documentó la primera calibración.
- @iiEliJas — agregó compatibilidad con musl, para que el motor compile también fuera de glibc.
- @texasich — reparó recipes de build que se habían quedado sin mantenedor.
- @dmoraesrs — sumó un selector de profundidad de razonamiento para GLM en la interfaz web.
- …y sí: @SebaWag — ese es nuestro propio PR #1399, el trunk streaming, que también entró en esta release.
Piensa lo que eso significa. Quince personas que probablemente nunca cruzaron un mensaje entre sí, cada una resolviendo un problema distinto, en máquinas distintas, en husos horarios distintos — y todo eso convergió el mismo domingo en un único paquete que se descarga en dos megabytes y corre un modelo de 2,8 billones de parámetros en tu computadora. No hubo una reunión. No hubo un proyecto en Jira. No hubo una empresa. Hubo un repo abierto y una misión compartida.
Vale la pena hacerse la pregunta incómoda para cualquier manual de gestión: ¿por qué lo hacen? Nadie les paga una hora. Nadie les va a ascender por un commit en un repo ajeno. Y sin embargo, semana tras semana, vuelven. Después de mirar este proyecto de cerca, las razones se ordenan en tres —y ninguna de las tres es "altruismo abstracto":
- Propósito inmediato. Muchos contribuidores corren modelos en hardware limitado y sienten la barrera en carne propia. No están arreglando el software de otro: están desbloqueando su propia máquina. El bug que arreglan es, literalmente, el que les impide trabajar.
- El mejor gimnasio de ingeniería que existe. Un motor en C puro, sin dependencias, con oráculos de exactitud y CI en cinco plataformas, es un entorno donde se aprende más en un trimestre que en un año de tutoriales. Contribuir a él es, de facto, la formación más dura y más real que un ingeniero puede darse hoy.
- Reputación que no se compra. Un commit mergeado en un proyecto de 29.000 estrellas es una credencial legible en cualquier lugar del mundo, que ningún título universitario ni curso online replica. Es, en el mercado global, una de las pocas señales que no se puede fingir.
Cuando esas tres cosas se alinean, el trabajo gratis deja de ser un misterio y se vuelve una consecuencia predecible. La pregunta de gestión correcta no es "cómo consigo gente que trabaje gratis", sino "cómo diseño un proyecto donde contribuir sea, al mismo tiempo, útil, formativo y visible". Colibri hizo las tres, casi sin proponérselo — y ese, más que el código, es el artefacto que vale la pena copiar.
No nos conocemos. No compartimos país, ni idioma, ni empleador, ni nivel de ingresos. La mayoría no tiene idea de quién es la otra persona al otro lado de un pull request.
Lo único que compartimos es un deseo genuino: que bajar las barreras de entrada a la inteligencia artificial deje de ser una idea bonita y se convierta en un archivo que cualquiera pueda descargar y correr. Eso, y nada más, es lo que sostiene este proyecto. Y alcanza.
4. Por qué funciona: el proyecto está diseñado para que cualquiera entre
Acá es donde conviene resistir la tentación del romanticismo y mirar la ingeniería, porque una comunidad no aparece por generación espontánea. Aparece porque el proyecto la hizo posible. Y eso fue, en Colibri, una decisión de diseño repetida cientos de veces.
Piensa en lo que normalmente te impide contribuir a un motor de inferencia:
| La barrera típica | La decisión de Colibri |
|---|---|
| Un infierno de dependencias: CUDA, PyTorch, un entorno que no compila en tu máquina | C puro, cero dependencias. Clonás y compilás. |
| "Necesitas 8 GPUs para probar cualquier cambio" | Corre en lo que tienes: desde CPU, streamando expertos desde el disco. |
| Una licencia que te cierra el paso | Apache-2.0. Úsalo, modifícalo, contribúyelo. |
| Una integración continua que solo prueba Linux x86 | CI en macOS, Windows (UCRT64), musl y ARM64. Contribuís desde donde estés. |
| Documentación que oculta lo que no funciona | Documentan lo que midieron y lo que desecharon, con los números. |
Fíjate en la última fila. Es la que distingue un proyecto en el que se puede confiar de uno en el que se puede participar. Las notas de la 1.11.0 no esconden los callejones sin salida: los nombran. Cuando un maintainer escribe abiertamente "esto lo construimos, lo medimos, dio peor, y lo borramos", le está diciendo a cada contribuidor nuevo dos cosas: acá los experimentos no se castigan, y la evidencia manda sobre la opinión. Ese es el clima exacto en el que alguien se anima a mandar su primer PR sin miedo a que se lo rechacen por deporte.
Y cuando las barreras bajan, pasa algo predecible y hermoso: la gente entra. No entra a consumir —entra a construir. Deja de ser audiencia y se vuelve coautora. Ese es el salto conceptual que casi todos los proyectos open source no logran dar: confunden tener usuarios con tener comunidad. Colibri tiene 138 coautores. La diferencia entre un usuario y un coautor es, literalmente, la diferencia entre alguien que descarga tu software y alguien que lo mejora.
5. Qué significa para LATAM (y la parte honesta)
Paro acá, porque no quiero venderte humo, y este proyecto tiene una tentación obvia: contarlo como una utopía horizontal donde todos somos iguales y no hay líderes. No es cierto, y decir lo contrario debilitaría el argumento.
Hay un centro. Vincenzo escribió el 54% del código, revisó la mayoría de los pull requests y tomó todas las decisiones de merge. No es una anarquía horizontal: es un líder con una cola larguísima de gente trabajando a su alrededor. Si él desapareciera mañana, el proyecto tendría un problema serio, y fingir que no es así sería mentirte.
Pero —y esta es la diferencia que lo cambia todo— sus puertas están abiertas de par en par, y cualquiera puede caminar por ellas. El poder está concentrado; el acceso, no. Y eso es exactamente lo opuesto a un club privado.
Piensa en el contraste. Durante décadas te dijeron que para participar de la frontera tecnológica necesitabas las credenciales correctas, el país correcto y el presupuesto correcto. Colibri es la refutación empírica de esa idea: un maintainer italiano y 138 desconocidos —sin oficina, sin inversores, sin Silicon Valley— construyeron en dos meses y medio un motor que hace correr modelos de miles de millones de parámetros en hardware de consumo. La barrera que cae no es la del conocimiento. Es la del permiso.
Para LATAM, la lectura es directa y, me atrevo a decir, esperanzadora. La brecha no es de talento. Los 138 contribuidores de este proyecto no son genios excepcionales venidos de otro planeta: son personas con criterio que encontraron un lugar donde su trabajo importaba y donde las reglas eran claras. La brecha no es de dinero, tampoco: el presupuesto total de este proyecto es, aproximadamente, cero. La brecha es de participación. Y la participación no se pide ni se compra: se ejerce. Entras a un repositorio, lees un issue, arreglas un bug, mandas un pull request. El resto —el idioma, la distancia, el que nadie te conozca— es ruido que internet ya volvió irrelevante.
Lo decíamos en un artículo anterior de esta serie: la brecha de acceso a la IA no se cierra consumiendo open source, se cierra contribuyendo. Consumir te da acceso mientras el proyecto viva; contribuir te da la capacidad de sostenerlo y dirigir su rumbo. Colibri, con sus 138 coautores que no se conocen, es la demostración más grande que hemos visto de que ese camino no solo existe: está lleno de gente recorriéndolo ahora mismo.
Y hay un beneficio que no es colectivo, sino individual —y que quizás te toque más de cerca. Para un desarrollador en LATAM, contribuir a un proyecto así no es solo un gesto de solidaridad: es la construcción de un portafolio que no depende de tu título, tu universidad ni tu país. Un historial público de pull requests mergeados en un motor que miles de personas usan es una credencial que viaja sola, que ningún reclutador puede ignorar y que ninguna crisis económica te puede quitar. En un continente donde las credenciales locales suelen valer menos de lo que deberían, esa es una forma concreta —y gratuita— de nivelar la cancha.
¿Consumes tecnología abierta, o la construyes?
La diferencia se siente el día que tu nombre aparece en un release que usan miles de personas —y que corre en hardware que tú ya tienes. No hace falta un PhD ni una visa de trabajo. Hace falta elegir un proyecto, entender qué le falta, y aportar la primera pieza. Te ayudamos a identificar dónde tu equipo puede contribuir de verdad a los proyectos que sostienen tu stack —y a diseñar la infraestructura propia que haga que eso sea posible.
Hablemos 30 minutos →6. Cierre: lo que de verdad es escaso
Volvamos al número con el que empezamos. 56 pull requests en 7 días. En la superficie es una estadística de velocidad. Debajo, es la prueba de una cosa que se repite cada vez que la miramos de cerca: lo escaso nunca fue el talento, ni el dinero, ni la infraestructura. Todo eso abunda, distribuido por el mundo, esperando en 138 laptops de personas que quizás nunca se crucen.
Lo escaso es una misión clara —bajar las barreras, reducir la brecha, democratizar la tecnología— y alguien dispuesto a sostener el estándar mientras un desconocido tras otro aporta su pieza. Junta esas dos cosas y pasa lo que pasó en Colibri esta semana: una release nueva cada cuatro días y medio, con la frontera de la IA un paso más cerca de quien no puede pagarla.
Por eso, la próxima vez que alguien te diga que la inteligencia artificial es un juego para unos pocos, muéstrale el release de hoy: 56 pull requests, 138 desconocidos, un maintainer, cero presupuesto — y un motor de frontera que ya corre en tu máquina. No es una utopía. Es un repositorio abierto. Y vos también podés caminar por esa puerta.
Lo dijo uno de los propios contribuidores, y lo repetimos porque resume todo: la mayoría no nos conocemos. Lo único que nos une es el deseo de bajar las barreras. Eso, resulta, es todo lo que hace falta.