Actualizado al 5 de junio 2025
Por cuestiones varias, principalmente confidencialidad, uso de entornos airgapped y fallas de seguridad en proveedores de terceros, Github requiere de manera directa dos requisitos: que puedas arriesgar que tu código sea copiado por terceros (incluyendo el dueño en turno de github y competidores) y dos que tengas una buena conexion de internet. Considerando que mucho del trabajo real tiene que ver con servidores con puertos cerrados, la continuidad de negocio no puede depender de github, y las limitaciones de puerttos cerrados que impidan el uso de composer (en php) crean un punto debil o cuello de botella.
Si, estoy de acuerdo en usar git en ciertos entornos en servidores hosteados, y ocasionalmente uso GIST de github para código libre, pero por lo anteriormente explicado n, hay razones para no poner de lo que comes en github.
La pérdida de datos es una preocupación constante, y la continuidad de operaciones es el objetivo real de github, pero hoy quiero profundizar en las razones por las que, a lo largo de mi trabajo, he optado por no depender de plataformas como GitHub…
Empecé a programar en 1991. Tenía copia de código fuente en dos lugares, y en el año 2000 por junio un disco duro de 17 gb se dañó y perdí una de las copias.
Pero no es eso de lo que se trata. Al final explico porque no uso Git pero antes un poco de prehistoria e historia.
Por fechas simplemente Git empieza como un derivado de el sistema de control de código fuente de Linux en 2005. Que yo recuerde en 2007 aprox se forma Github, y años después es parte de Microsoft.
Soy devops y programo desde hace Muchos años para vivir de manera comercial. Desde Mayo de 1991. Eso significa que llevo cobrando en empresas por programar desde hace TREINTA Y DOS AÑOS.
Los desarrollos que hice en 1991-1992 Fueron principalmente scripts para calcular nóminas importables a Quattro Pro, Lotus 123 y Visicalc, así como unos archivos bat y de texto para editar memorandums de envío de documentación.
1992-1995 Un sistema completo de 200 pantallas Hecho en Turbo Pascal 5.5 (razones varias de rendimiento además de existir ya el 6.0 ), con una versión en C de Borland, que era usado por unas 400 sucursales de un supermercado. Por las limitaciones de la época y lugar 1 ) No era posible tener versiones anteriores o regresar a otras ya que las reglas de negocio cambiaban de una semana a otra, (los archivos de registros binarios cambiaban al meter mas campos, no se usaban base de datos asi que eran incompatibles entre versiones) y se actualizaba por diskettes enviados por valija 2 ) eran unos 80 ejecutables. trabajábamos con 286 con 640kb de ram.3 ) Internet apenas empezaba en Fido. Los últimos dos años usábamos en algunas sucursales sobre blancos de spin para bajar por FTP el archivo Lharc encriptado. Simplemente 1993 es el año en que salieron las primeras versiones de PKZIP y tuvo varias fallas así que usábamos LHA y LHZ por iniciativa mía. No hubiera podido hacer deployment desde repositorios por no existir internet en esa época y mayor conocimiento técnico requerido. Se guardaba en formatos Trunk. Literalmente era control de versiones estilo https://trunkbaseddevelopment.com/ y se usaban pantallas especificas para configurar.
1995-2000 Trabajé en una empresa particular. Se usaban Proyectos de control de dinero, relacionados algunas cosas con vida humana. Asi que se tomaban varias medidas de seguridad por iniciativa mía. Finalmente era código Clipper / Visual Objects 1.0 / Visual Basic 4/5/6 con TRES personas que saboteaban si podían. Uno murió acuchillado por la esposa ala que le puso los cuernos, el otro tenía ulcera alcohólica desde los 22 (es al que saqué de un restaurante jalándolo de la corbata por estar haciendo chiste s de homosexuales y al que no corrieron a pesar de tener antecedentes de fraude conjunto con una dama vendiendo computadoras que no servían y nadie los podía ver, incluyendo la persona de contabilidad la que le plantó sexo explicito de homosexuales y nadie hizo nada), y el tercero se aventó ocho años en la cárcel por sabotaje industrial por varios años de decir que el software no cumplía la funcionalidad y probamos ante notario que no era así. Básicamente el tipo nos hizo gastar millones de pesos en Casas Alatriste porque lo contrataron para QA de mi código después que yo lo corrí por cambiar contraseñas de red novell y no querer darlas. En ese lugar usamos códigos trunk en lo que funcionó (todo hecho por mi) por dos razones. a ) Centralicé el código de 18 sistemas en uno solo, luego fueron 29 b ) Como alteraban código y otras cosas, siempre empezaba de cero en cambios. Tuve que borrar información de una planta y en ocasiones BORRAR PREVIO ACUERDO el código que funcionaba para uqe nuevos programadores hicieran algo que no servía y NO PUDIERAN DESPUES decir que era mi código. Muchas anécdotas pero trunk me daba seguridad física de que mis datos estaban bien y que no hubieran leaks. el que hubo fue darle el código del proyecto principal al que fue a carcel por sabotaje , y en otra ocasión ir a recuperar código del «jefe» del nuevo equipo de dos personas de Visual Basic que hacia el 10% del mio, porque se negaba a entregar el código. Recuerdo que mi planteamiento en el 2000 fue… si no sirve no tiene caso y a el explicarle como podría ir a dar a la cárcel por fraude ya que teníamos ademas el antecedente del de sabotaje industrial. En esa epoca yo usaba VSS (Visual Source safe) para Visual basic y Trunks de archivos consecutivos en tres lugares para el código de las tres ramas, Visual basic, Visual Objects y Clipper. Lo estúpido es que tuve ue borrar todo un sistema de Visual Basic ya probado y funcional, para que pusieron algo de menos de 10% de capacidad que lo habian hecho en tres años. Al final el código que entregué fue Clipper en trunk FINAL y los dos trunks del sabotaje, antes y comparado… de los 5600 Trunks existentes. Después entre Subversion , bitbucket y demás uso solo GIT cuando no me queda de otra y siempre hosteado.
En esa época hice los primeros sistemas para hospitales, y por su nivel de seguridad, y la importancia de la información nada de Github. Reglas SIRES hace mala idea volverlo código libre, y mas si alguien cambia LPGL de 2.0 a 3.0 por implicaciones HIPAA.
Considerando que después use Git / bitbucket / Subversion y los problemas de estructura, o requerimientos de seguridad de dependencias de gobierno, inclusive el cliente de los monolitos que tiene que seguirlas :
- Y algunas cosas anterior o lenguajes de plano no existia Github. Soruce Safe quizá.
- Deployments en entornos como lenguaje ensamblador se de un super click. Entornos SCADA por ejemplo.
- usas ancho de banda en servidor de entrada y de salida, que son cuello de botella si tu programa es bueno y te piden mas cambios o mejoras, en lugar de estar abandonado
- Microsoft es No no para muchos. Yo uso unos cuantos git en servidores propios pero no github, y uso bitbucket para proyectos privados y solo algunos
- Hardening de Kubernetes o de Docker no es rapido. Y tener ue hacerlo seguido es trabajo de tiempo completo. Muchos ingresos que tengo son por arreglar desastres como lo de capistrano del 2015
- Puede haber mala conexión a internet que pone en riesgo vida humana, control o perdidas materiales de dos millones de pesos por la acidez de tinas de pintura. O puedes estar en el cerro con ovejas en Puebla sin señal de celular
- Caso del Cliente en época de covid, Admin muerto con acceso al github privado y que no podían acceder al código real de la empresa del histórico, solo a las maquinas locales de desarrolladores y proyectos vigentes. Diez años perdidos de codigo.
- Caso de DMCA sobre la imagen de un software de git que les aplicaron en github un DMCA y adiós 45 días. Basicamente alguien se quejo de un copyright, de una imagen y les suspendieron todos los repositorios de la cuenta
- Los chinos y rusos . Hay casos de software chino o ruso que ya no pueden entrar a sus repositorios por sanciones comerciales de USA. Incluso ciertos paises ya no pueden usarlo por sanciones comerciales.
- Tu información puede ser confidencial o que el cliente no quiera que el código lo vea la competencia.
- A veces encuentras certificaciones necesarias para vender un producto informático. Ejemplo, certificaciones para HL7 o estándares de salud en México. Otro son cosas de factura electrónica. Los que pagan el software deciden, y lo normal es proteger confidencialidad y a veces hay casos como una fábrica de Jabones que puso mucho código fuente de factura electrónica, y al volverse PAC lo quitó porque estaba obligado a evitar confusiones … y era la única fuente confiable.
- Dar soporte a personas que no tienen ni idea, te quita mucho tiempo. Oye, necesito que esto sea compatible con VGA y no HDMI (la respuesta es cómprate un adaptador, estás hablando de hardware que ya tiene valor contable de 0 por depreciación)
- aceptar y manejar merge/pull requests se vuelve trabajo de tiempo completo. No, no puedo dar merge porque no consideras que la dirección IP puede ser Ip6 y no puedes dividir por puntos simples la IP.
- Problemas de versiones tipo MPDF de php 5 a 7, o de laravel y su universo de estupidez.
Es un tema largo, pero en mi estilo de trabajo no hay razón para usar Git cuando tienes mala conexión Y el mundo real es otro. Los costos y la confidencialidad deben considerarse. Usar composer usa muchos recursos cuando se actualiza, y en ciertos casos legacy es fatal para el servidor. Y en casos air gapped no se diga.