Codigo

Una pregunta que me hacen ocasionalmente es por qué no tengo repositorios públicos en GitHub o por qué no comparto más código fuente en mis proyectos. La respuesta no es simple, pero tiene razones muy sólidas que van más allá de las preferencias personales.

Contexto de lenguajes.

Me pagan por programar desde 1991. Desde el 98 soy lo que ahora se le llama Devops. Mezcla de administrador de servidores, DBA y programador. He utilizado entre otros C , C ++, Basic, Turbo Pascal 3 – 7, CLipper (5.2e era maravilloso), Visual Basic, C# .net, Ruby, Python, Php , Rust y Angular Stack MEAN. Por lo general he implementado soluciones usando dos o tres tecnologías. En 2015 me encontraba con Ruby, Php, y MEAN con variantes. Debido a que la mayor parte de las personas que conozco usan solo poco de #asp o php sobre frameworks, me di cuenta que la base era como siempre usar lo que funciona. En contabilidad se le llama filosofía de «Negocio en marcha»

La forma mas estable de hacer un sistema ligero para entornos Web, es con PHP con pocos frameworks.  La mayor parte de los desarrollos que me piden desde el 2007 son cosas que pueden hacerse mas rápido y mejor en PHP. Cumple su cometido. Es simple, funcional e incluye funciones nativas de UNICODE , que simplifican el trabajo para proyectos que se publican en diversos idiomas. y es simple de balancear o replicar entorno operativo.

Pero por ejemplo, las soluciones que uso en marzo de 2025 llevan PHP, C# , y algunas cosas en Java. Para que meter typescript o Rust si necesitas un sitio con 600 usuarios simultáneos ? Los desarrollos de celular parecen buena idea pero hay tres problemas. Uno, el usuario tiene que usar datos (se necesita tiempo aire), dos, los sistemas de publicación en play store y en la tienda de apple hace muy difícil migración o traspaso de credenciales, 3 Luego salen problemas de deployment por los que aprueban las apps. He podido solucionar mucho usando PHP o rust con interfaces graficas amigables, pero a la larga la gran ventaja de PHP es para el cliente. Resulta mas fácil para el saber que puede contratar con ese perfil. No necesita un experto en node.js, angular 2, Javafaces, alguna rara versión de Java.

En resumen, Clipper permitía mezclar asm, lenguaje C y clipper. Muchas veces la realidad te lleva a hacer implantaciones mixtas, y depende del cliente, sus servidores o como me ha pasado recientemente (2023 a 2025) sus puertos están cerrados, los WAF mal implementados, su red colpasa y haces lo que puedes para dar la solución.

Contexto Profesional y de Seguridad

Durante más de tres décadas trabajando en DevOps y sistemas, he manejado información clasificada bajo acuerdos de confidencialidad (NDA). Esto incluye datos personales de estudiantes, gestión de hospitales(que implican confidencialidad y vidas humanas), configuraciones de infraestructura crítica, optimizaciones específicas de costos para AWS/Azure, y soluciones para vulnerabilidades de seguridad que, de hacerse públicas, podrían ser explotadas maliciosamente. En lo personal uso otro tipo de soluciones intermedias de costo fijo como Vultr y Linode siempre que me es posible.

Mi trabajo también ha involucrado casos donde he tenido que enviar personas a prisión por actividades criminales detectadas por sistemas informáticos. En este contexto, hacer público mi código sería como dejar un mapa detallado de mis métodos y herramientas para detectar fraudes o anomalías, y en general cualquiera que tenga intenciones hostiles.

Una parte significativa de mi trabajo involucra sistemas de tiempo real donde las fallas no son inconvenientes menores – son pérdidas de vidas humanas o daños materiales que pueden alcanzar decenas de miles de dólares en minutos.

Cuando estás controlando el pH de una tina de pintura industrial o la temperatura de procesos de manufactura de queso, un error de código no significa que tu aplicación web se caiga – significa que se tiran toneladas de material y se pierden meses de trabajo.

La Realidad de los Sistemas Air-Gapped

Trabajo frecuentemente con sistemas air-gapped por diseño – sistemas de control o información sensible que DEBEN estar completamente aislados de internet por seguridad (o porque los administradores de la red no dan una). En este entorno:

• No puedo usar Composer, npm, pip o gestores de dependencias que requieran conexión a internet
• El código debe ser completamente autónomo y funcionar sin dependencias externas
• Cada línea debe ser verificable sin depender de repositorios de terceros

Además, muchas de estas instalaciones están en ubicaciones remotas donde la conectividad es tan limitada que el paso del señor de los tamales es literalmente el evento social de la semana. Tu código debe funcionar perfectamente sin internet.

«La Nube» No Existe

Una realidad que muchos desarrolladores modernos olvidan es que «la nube» no existe – son los servidores de Amazon, Microsoft o Google. Para sistemas críticos, entregar el control de tu infraestructura a terceros introduce vectores de riesgo innecesarios:

• Personal de proveedores con acceso a tus sistemas
• Jurisdicciones múltiples con leyes diferentes sobre privacidad, etc
• Órdenes judiciales y solicitudes gubernamentales
• Vulnerabilidades en la infraestructura del proveedor
• A veces lo pones en una instancia cercana o en las instalaciones del cliente por problemas de conectividad. Sin internet fiable no hay nube
• y si el proveedor desaparece que ?

Responsabilidad Profesional

No es paranoia – es ingeniería responsable. Un desarrollador que diseña sistemas industriales críticos que dependan de internet para funcionar es un desarrollador irresponsable.

Los sistemas SCADA, controladores PLC y equipos de control industrial están air-gapped por razones muy específicas. Cuando tus sistemas controlan procesos donde una falla puede costar vidas o millones de dólares, la conectividad constante a internet no es una característica – es una vulnerabilidad.

Soy alguien que entiende que:

• Los sistemas de producción tienen restricciones reales (air-gapped, sin internet, hardware específico)
• El cliente necesita soluciones que funcionen a largo plazo, no demos impresionantes
• La responsabilidad profesional incluye mantener y arreglar lo que construyes
• A veces PHP «aburrido» es mejor que React/Node.js brillante si el primero resuelve el problema de manera confiable

Un ejemplo es el comentario sobre que prefiero tecnologías donde es más fácil encontrar desarrolladores para el cliente también muestra madurez profesional. No se trata de lucirse con la última framework, sino de construir algo sostenible. La continuidad de negocio tiene que ver con usar tecnología probada.

Es la diferencia entre ser un desarrollador y ser un ingeniero de software. El primero programa, el segundo resuelve problemas del mundo real considerando todas las variables: técnicas, económicas, humanas y de negocio.

Conclusión

Mi enfoque de mantener el código fuente privado, trabajar con sistemas autónomos y evitar dependencias externas no es una limitación tecnológica – es profesionalismo en sistemas donde las fallas tienen consecuencias reales. A veces el entorno restrictivo es por problemas del lugar. Te piden trabajar con puertos cerrados , y te encuentras por los puertos cerrados de manera similar a tener un refrigerador cerrado. No solo son las necesidades del desarrollo en sí sino de redes obsoletas o mal configuradas. Muchas veces no puedes decir nada.

Cada desarrollador debe evaluar su contexto específico. Para aplicaciones web convencionales, GitHub público y dependencias npm pueden ser perfectamente apropiadas. Para sistemas de misión crítica con requisitos de seguridad estrictos, el enfoque debe ser completamente diferente.

La tecnología debe servir a los requisitos del sistema, no al revés.

Relacionado: