Hay una conversación que tenemos con frecuencia con clientes nuevos y que siempre nos parece reveladora. En algún punto del proceso, alguien pregunta: ¿podemos ver el código? La respuesta siempre es sí. Y la reacción a ese sí suele ser una mezcla de alivio y sorpresa.
El alivio lo entendemos. La sorpresa nos dice algo sobre cómo funciona la industria.
Por qué la opacidad tecnológica es un riesgo
Cuando una empresa externaliza el desarrollo de software, está tomando una decisión de confianza de largo alcance. No solo está contratando una funcionalidad; está generando una dependencia. Si el código es opaco —si solo el proveedor puede leerlo, entenderlo y modificarlo— esa dependencia se convierte en vulnerabilidad.
¿Qué pasa si el proveedor desaparece? ¿Si la relación se deteriora? ¿Si necesitas un auditor externo que valide la calidad del trabajo? En todos estos escenarios, la opacidad del código juega en contra del cliente.
La transparencia no es solo una cuestión ética. Es una cuestión de gestión de riesgo.
Qué significa trabajar en abierto (y qué no significa)
Trabajar con código abierto o con prácticas de desarrollo transparentes no significa publicar todo en GitHub para que cualquiera lo vea. Significa que el cliente tiene acceso completo al repositorio desde el primer día, que el historial de cambios es auditable y que el código está escrito para ser leído por humanos, no solo para ejecutarse en servidores.
Significa también que las decisiones técnicas importantes están documentadas: por qué se eligió esta arquitectura, por qué se descartó aquella librería, qué trade-offs se hicieron en cada punto relevante.
Un código que solo entiende quien lo escribió es un código que ata. Un código bien escrito y documentado es un activo transferible.
Open Source como filosofía de construcción
En KODEO usamos software open source siempre que podemos, y contribuimos cuando tiene sentido. Pero más allá de las herramientas concretas, lo que nos interesa del Open Source es la cultura que genera: la cultura de construir cosas que otros puedan entender, revisar y mejorar.
Esa cultura cambia cómo se escribe el código. Cuando sabes que alguien más va a leerlo —ya sea el cliente, un auditor, un nuevo desarrollador del equipo— escribes mejor. Nombras mejor las variables. Estructuras mejor los módulos. Documentas los casos límite.
El código que se escribe para ser auditado suele ser mejor código.
Cómo esto beneficia a nuestros clientes
La transparencia tiene consecuencias prácticas muy concretas:
Reducción de la dependencia tecnológica: si en algún momento un cliente decide cambiar de proveedor, tiene todo lo necesario para hacerlo sin fricciones. El nuevo equipo puede entender el código, continuarlo y evolucionarlo.
Auditorías sin fricción: cuando un cliente necesita que un tercero revise la seguridad o la calidad del software, no hay nada que ocultar ni que preparar. El repositorio está limpio, el historial es honesto y la documentación existe.
Incorporación de nuevos desarrolladores: los proyectos que crecen necesitan sumar personas al equipo. En un código opaco, esa incorporación es costosa y lenta. En un código transparente y bien documentado, los nuevos perfiles se ponen al día en días, no en semanas.
Confianza en el proceso: los clientes que pueden ver el repositorio en tiempo real —los commits diarios, los cambios semana a semana— tienen una relación distinta con el proyecto. No porque lo lean todo, sino porque saben que pueden hacerlo.
La pregunta que debería hacerse cualquier empresa antes de contratar desarrollo
Si mañana tuviéramos que cambiar de proveedor, ¿podríamos continuar el proyecto sin depender de quien lo construyó?
Si la respuesta honesta es no, hay un problema estructural en la relación con el proveedor actual. No necesariamente de mala fe — a veces es simplemente la consecuencia de malas prácticas no cuestionadas —, pero es un problema.
Construimos software que no te ata a nosotros. Nos parece la única forma honesta de trabajar.
