Documentar software en español y crear mecanismos de descubrimiento local reduce la fricción para aprender, evaluar herramientas y conectar a quienes construyen en la región. No reemplaza el inglés ni la distribución global; añade contexto y una puerta de entrada cercana.
Cuando un desarrollador latinoamericano termina un proyecto, suele hacer tres cosas: escribe el README en inglés, lo comparte en comunidades globales y espera que alguien del otro lado del mundo lo descubra.
No hay nada malo en buscar alcance internacional. El problema aparece cuando nuestro trabajo necesita salir de la región para que nosotros mismos lo consideremos valioso.
No nos falta talento exportable. Nos faltan mejores mecanismos para descubrirnos entre nosotros.
Esa idea está detrás de madeinchile.tech, un directorio abierto para encontrar software, SaaS, herramientas y proyectos creados por personas de la comunidad tecnológica chilena.
¿Por qué la presencia tecnológica del español no refleja a su comunidad?
El Anuario 2025 del Instituto Cervantes estima más de 630 millones de hablantes potenciales de español y alrededor de 520 millones con dominio nativo.
Sin embargo, el español aparece en cerca del 6 % de los sitios cuyo idioma puede identificar W3Techs, mientras el inglés ronda la mitad. La cifra cambia con la metodología y no mide a todas las personas que usan internet, pero sí muestra una asimetría: la presencia editorial del español es mucho menor que su comunidad de hablantes. Los datos actualizados pueden consultarse en W3Techs.
En tecnología, esa diferencia se nota todavía más. Muchas discusiones profundas, documentación temprana y lanzamientos ocurren primero —o únicamente— en inglés.
¿Escribir en español significa rechazar el inglés?
El inglés es una herramienta fundamental para colaborar, investigar y distribuir software. No propongo abandonarlo. Propongo dejar de tratar el español como una versión secundaria que solo aparece después de que un proyecto “funcionó”.
Documentar también en nuestro idioma produce efectos concretos:
- reduce la fricción de entrada para quien todavía está aprendiendo inglés técnico;
- crea vocabulario compartido para discutir arquitectura y producto;
- permite explicar problemas locales sin traducir su contexto;
- facilita que empresas y usuarios de la región encuentren soluciones cercanas;
- forma referentes con experiencias comparables a las nuestras.
Una API puede tener documentación bilingüe. Un proyecto puede lanzarse globalmente y conversar con su comunidad local. No es una elección binaria.
¿Qué ventaja práctica ofrece la visibilidad local?
Un producto desarrollado en Chile puede entender restricciones que una solución global considera marginales: medios de pago, lenguaje legal, conectividad, geografía, instituciones o hábitos de pequeñas empresas.
Eso no lo vuelve automáticamente mejor. Lo vuelve más fácil de evaluar desde el contexto correcto.
Cuando los builders locales se encuentran, pasan cosas que una métrica de visitas no refleja:
- un primer usuario detecta un caso que el creador no vio;
- otro desarrollador abre un issue o propone una integración;
- una empresa encuentra una herramienta que puede probar sin una diferencia horaria de doce horas;
- un estudiante descubre que el software que admira también puede construirse desde su ciudad.
La comunidad deja de ser una audiencia y se convierte en infraestructura.
¿Qué intenta resolver madeinchile.tech?
El primer objetivo es simple: que un buen proyecto chileno sea más fácil de descubrir.
La plataforma permite buscar y filtrar proyectos, visitar una ficha propia, enviar una nueva propuesta y reconocer trabajos destacados. Está construida con Astro, React, Supabase y Tailwind CSS; usa renderizado en servidor y validación estructurada para que el directorio pueda crecer sin transformarse en una lista manual de enlaces.
Pero un directorio puede fallar aunque el código funcione. Si solo acumula tarjetas, no construye comunidad. Por eso las preguntas importantes no son técnicas:
- ¿Los proyectos reciben usuarios útiles?
- ¿Los creadores actualizan sus fichas?
- ¿La selección evita convertirse en publicidad sin criterio?
- ¿Una persona encuentra algo que no habría descubierto por su cuenta?
¿Por qué un directorio no debería lanzarse vacío?
La primera versión priorizaba la plataforma: filtros, likes, formularios, pagos para destacar y detalles visuales. Era tentador seguir agregando funciones porque cada una hacía que el producto pareciera más completo.
El valor, sin embargo, depende del contenido. Diez proyectos bien presentados, con contexto y creadores activos, valen más que cien enlaces importados sin revisión.
Eso cambió mis prioridades:
- mejorar cada ficha antes de ampliar el catálogo;
- definir criterios de aceptación visibles;
- pedir a los creadores que expliquen el problema, no solo el stack;
- destacar aprendizajes además de productos terminados;
- medir clics hacia los proyectos y envíos de calidad, no solo visitas al directorio.
¿Qué debería explicar una ficha de proyecto?
“Aplicación hecha con React y Supabase” no ayuda a decidir si vale la pena abrirla. Cada proyecto debería responder:
- Problema: ¿qué situación intenta cambiar?
- Persona: ¿para quién existe?
- Decisión: ¿qué elección técnica o de producto fue importante?
- Estado: ¿es una idea, una beta o un producto activo?
- Puerta de entrada: ¿se puede probar, leer o contribuir?
Es la misma regla que intento aplicar a mi portafolio. El stack es evidencia de implementación, no la historia completa.
¿Qué límites necesita una comunidad tecnológica?
Dar visibilidad no significa aceptar cualquier envío. Un catálogo útil necesita moderación, atribución y reglas contra contenido engañoso. También debe distinguir entre proyecto chileno, empresa que opera en Chile y producto que solo usa una bandera como estrategia de marketing.
Esos límites deberían quedar documentados y evolucionar con la comunidad. Si dependen únicamente de mi criterio privado, el directorio no es realmente abierto.
¿Qué quiero conseguir con madeinchile.tech?
No espero que madeinchile.tech reemplace GitHub, Product Hunt ni las comunidades internacionales. Quiero que cubra el espacio anterior: el momento en que un proyecto todavía necesita sus primeros usuarios, comentarios y conexiones cercanas.
La meta no es demostrar que el software chileno puede competir “afuera”. Ya lo hace.
La meta es que dejemos de enterarnos tarde de lo que se construyó al lado.