El 21 de junio de 2026, Mitchell Hashimoto publicó en su blog personal un texto de menos de 500 palabras: él y su esposa volvían a donar 400.000 dólares a la Zig Software Foundation (ZSF), acumulando 700.000. Sin nota de prensa, sin comunicado conjunto, sin pancarta de «alianza estratégica». Un cheque personal, un blog personal, un juicio personal.
Esto no se parece en nada al modelo de flujo de dinero al que el mundo open source se ha acostumbrado.
El patrocinio empresarial al open source tiene un guion estándar: asiento en la junta directiva, derecho a voto en el comité técnico directivo, influencia sobre la hoja de ruta, co-branding, comunicado de prensa conjunto. El dinero viene con condiciones — a veces escritas en el contrato, a veces enterradas en las actas de las reuniones de «alineación estratégica». Google patrocina Kubernetes, Microsoft patrocina la Rust Foundation, Meta patrocina la PyTorch Foundation — ese dinero mantiene infraestructura crítica, pero también introduce juegos de gobernanza complejos. La relación de poder entre patrocinador y proyecto nunca es unidireccional.
Pero una gran donación personal es otra cosa.
El dinero que Hashimoto dio a Zig no le compró un asiento en la junta, ni un derecho de veto sobre la dirección del lenguaje, ni ninguna forma de control. De hecho, escribió explícitamente en su blog que él usa mucho la programación asistida por IA, mientras que la ZSF es conocida por su estricta política de «prohibir commits de código generado por LLM» — su opinión no coincide del todo con la de la fundación. Y eso no afecta a su decisión de donar. «Solo tengo respeto por la ZSF: respeto por la gente, las políticas y el proyecto en sí», dijo. «Internet y el open source son grandes en parte porque los proyectos pueden ser raros, diferentes.»
Ahí reside precisamente el valor único de la donación personal — «no estar de acuerdo no me impide poner dinero» — eso es en sí mismo una declaración de profundidad de confianza. Una confianza cuya dirección es inequívoca: la dirección del otro.
No pretendemos romantizar la donación personal. Los grandes donantes individuales son en sí mismos un producto de la desigualdad de riqueza. Hashimoto, como cofundador de HashiCorp, posee un patrimonio considerable tras la adquisición de la empresa por parte de IBM por 6.400 millones de dólares. El mero hecho de que una persona pueda extender un cheque de 400.000 dólares ya indica que este modelo no es replicable ni escalable. Un comentarista de la comunidad Zig, colindean, acertó en Lobsters: «Cada dólar cuenta. Quizá empieces donando 5 dólares al mes a la fundación de tu lenguaje favorito.» La agregación de pequeñas donaciones individuales y la donación única de un gran patrimonio son niveles distintos del mismo ecosistema — una proporciona resiliencia de base, la otra proporciona empuje estratégico.
Pero el papel del empuje estratégico casi nadie lo ha analizado en serio en el debate actual.
Cuando una empresa dona 250.000 dólares a una fundación open source (el umbral habitual para ser «patrocinador platino»), lo que obtiene es participación en la gobernanza. Ese dinero es esencialmente una compra — compra influencia, compra acceso temprano, compra visibilidad de marca en el canal de contratación. En cambio, cuando una persona, a título individual, dona una cantidad igual o mayor sin reclamar ningún derecho de gobernanza, ese dinero es esencialmente una apuesta. Apuesta por la dirección, no por el retorno.
La diferencia entre ambas se ve con especial nitidez en el caso de Zig. Comparemos la estructura de financiación de la Rust Foundation y la Zig Foundation: la lista de patrocinadores platino de Rust incluye Google, Microsoft, Amazon, Huawei, Meta — cada uno con alguien sentado en la junta directiva de la fundación. Esto es describir hechos. Rust se beneficia de un fuerte respaldo de recursos empresariales, pero también necesita equilibrar la gobernanza entre múltiples partes interesadas de forma continua. En cambio, la Zig Foundation ingresó en el año fiscal 2024 alrededor de 670.000 dólares, de los cuales unos 170.000 provinieron de pequeñas donaciones comunitarias a través de GitHub Sponsors y 150.000 de la donación personal de Hashimoto. El 92% del gasto fue directamente a la remuneración de los contribuyentes.
Ninguno de los dos caminos es mejor o peor; resuelven problemas distintos. Pero la discusión sobre gobernanza open source se ha centrado casi por completo en el modelo de patrocinio empresarial — cómo gestionar los conflictos de interés, cómo equilibrar la influencia corporativa, cómo prevenir la «captura». La gran donación personal como fuente de financiación alternativa está gravemente infravalorada.
¿Por qué Hashimoto eligió Zig?
La pregunta en sí merece ser desarrollada. No es que no tuviera capacidad para elegir Rust. Escribió Vagrant, Packer, Consul, Terraform, Vault — herramientas que constituyen la mitad de la infraestructura cloud moderna. Su criterio de ingeniería merece ser tomado en serio.
La cronología de su elección de Zig: empezó a seguir el proyecto Zig en 2019, expresó públicamente su entusiasmo en 2021, a principios de 2022 empezó a contribuir código al compilador de Zig (su primer PR fue un cambio de tres líneas que le llevó cuatro o cinco horas), y ese mismo año arrancó el proyecto del emulador de terminal Ghostty — íntegramente en Zig. A día de hoy, acumula decenas de commits en el compilador de Zig y Ghostty ha lanzado su versión 1.0 constituyéndose como organización sin ánimo de lucro independiente.
Lo que le atrae de Zig no es la cuota de mercado (está muy por detrás de Rust), ni la madurez del ecosistema (la librería estándar aún cambia rápido), ni el respaldo empresarial (prácticamente ninguna gran empresa lo ha adoptado oficialmente). Sus razones para elegir Zig son técnicas:
Sin asignación implícita. Uno de los principios de diseño de la librería estándar de Zig es que toda asignación de memoria debe recibir explícitamente un parámetro allocator. Ninguna función llama a malloc sin que tú lo sepas. En programación de sistemas, ¿qué significa esto? Significa que, al escribir un emulador de terminal, el bucle de renderizado no va a sufrir de repente una pausa de GC, ni un jitter porque una operación de concatenación de cadenas haya reservado 4KB de heap por detrás. El rendimiento de renderizado de Ghostty se beneficia directamente de este diseño.
C ABI como ciudadano de primera clase. @cImport de Zig puede importar directamente cabeceras de C; un binario compilado con Zig puede llamar a librerías C sin fisuras y ser llamado desde código C. Para un ingeniero como Hashimoto, que construye sistemas desde abajo hacia arriba, esta característica trasciende con mucho la categoría de «funcionalidad de compatibilidad» — es un requisito de supervivencia. Ghostty necesita interactuar en profundidad con CoreGraphics en macOS, GTK en Linux y las librerías de renderizado de fuentes de cada plataforma — todas esas interfaces son C. El tratamiento que Zig da a la interoperabilidad con C es directo: convierte C en parte del lenguaje, sin añadir una capa de abstracción FFI.
comptime. La computación en tiempo de compilación de Zig no es un sistema de macros, ni metaprogramación con plantillas: es un subconjunto del mismo lenguaje que se ejecuta en fase de compilación. El propio Hashimoto escribió un recorrido por casos de uso de comptime, mostrando escenarios reales que van desde el filtrado de subconjuntos de uniones etiquetadas hasta la generación de código por compilación condicional. Para construir un emulador de terminal multiplataforma — donde necesitas decidir en tiempo de compilación el backend de renderizado, la ruta de procesamiento de fuentes y el método de integración con el método de entrada según la plataforma objetivo — comptime vale como un arma arquitectónica de verdad, mucho más que «azúcar sintáctico».
Estas elecciones de diseño comparten una filosofía común: no tomar decisiones por el programador. El sistema de propiedad de Rust gestiona la seguridad de memoria por ti; esa es su propuesta de valor central. Zig no gestiona nada por ti — te pone el asignador en la mano, te despliega el flujo de control delante y te expone la ABI. Confía en tu criterio.
Esa filosofía explica precisamente por qué la donación de Hashimoto y sus diferencias con las políticas de la ZSF pueden coexistir. Hashimoto usa mucho la IA para escribir código; la ZSF prohíbe que el código generado por IA entre en el repositorio principal. Ambas posturas nacen de la misma premisa: hacerte responsable de tus herramientas y de lo que produces. Hashimoto usa la IA para acelerar el desarrollo, pero revisa cada línea que la IA produce — él mismo ha escrito sobre cómo usó la IA para implementar funcionalidades no triviales de Ghostty, insistiendo precisamente en que «tienes que tener suficiente criterio para verificar la salida de la IA». La ZSF prohíbe las contribuciones de IA con la misma lógica de responsabilidad por la calidad — en contextos donde no se puede verificar cada línea de código generado por IA, rechazar las contribuciones de IA es la garantía de menor coste. Ninguno se equivoca; ambos se toman en serio lo de «ser responsable del código».
Volviendo a la discusión de Lobsters, el comentario que más merece la pena rumiar es el de kristoff — contribuyente principal de Zig, 63 votos, el más votado. Dijo: «Mitchell ha sido increíblemente generoso con el proyecto y la comunidad Zig. Pero, curiosamente, su apoyo financiero, aunque impresionante, no es su contribución más valiosa a Zig.»
La fuerza de esta frase está en que proviene de alguien de dentro del proyecto, no de un observador externo. Que un contribuyente principal de un proyecto que ha recibido 700.000 dólares en donaciones diga que «el dinero no es lo más valioso que nos ha dado» — está redefiniendo el valor.
¿Qué es más valioso que el dinero? kristoff no lo desarrolla, pero la respuesta está dispersa a lo largo de la trayectoria de Hashimoto en los últimos años: el código que ha subido al compilador de Zig, la serie de artículos que escribió sobre la estructura interna del compilador de Zig (Tokenizer → Parser → AstGen → Sema), sus charlas técnicas en Zig Showtime, el haber demostrado con Ghostty que Zig es viable en proyectos de nivel producción. El efecto palanca de estas contribuciones supera con creces los 700.000 dólares — reducen la barrera de entrada para otros desarrolladores, proporcionan casos de validación en el mundo real y atraen a más contribuyentes.
La comparación entre el valor del dinero y el valor del código en el open source no es un dilema binario. El dinero permite a los desarrolladores trabajar a tiempo completo; el código hace que el proyecto avance. La ZSF gasta el 92% de su presupuesto en pagar directamente a los contribuyentes — esa cifra demuestra que el dinero se transforma en código. Pero la premisa de esa transformación es que haya alguien dispuesto a escribir ese código, alguien dispuesto a revisarlo y alguien dispuesto a responsabilizarse de su calidad. Hashimoto aparece en ambos extremos de esa cadena de transformación.
Es un camino poco transitado. La mayoría de los fundadores tecnológicos ricos eligen ser business angels, buscando retorno financiero. Unos pocos eligen la filantropía, donando a educación, sanidad o clima — todas ellas causas razonables e importantes. Pero extender un cheque de 400.000 dólares a la fundación de un lenguaje de programación, sin pedir un asiento en la junta, sin pedir intervenir en la hoja de ruta y sin siquiera estar completamente de acuerdo con todas las políticas de la fundación — eso va más allá de la caridad, es algo más raro: puro «creo que estáis haciendo lo correcto».
El open source necesita patrocinio empresarial. Pero también necesita personas así: con dinero, que entienden la tecnología, con criterio sobre la dirección y que respetan la independencia del proyecto. El debate actual sobre gobernanza open source se centra casi por completo en cómo gestionar la influencia empresarial, pero quizá haya otra pregunta más simple que merezca atención: cómo lograr que más personas con recursos participen al estilo Hashimoto.
La respuesta no va a salir de ningún marco de gobernanza ni documento de buenas prácticas. Sale de la difusión de una cultura: personas que escriben código, que ganan dinero con ello y que luego miran hacia atrás, hacia las herramientas y los lenguajes que les permitieron escribir buen código, y dicen — de igual a igual —: esta dirección es la correcta, quiero que siga adelante.
Esa es la parte más pesada de los 700.000 dólares: la postura que hay detrás de la cifra.