- Una historia basada en hechos reales sobre los riesgos del vendor lock-in y las prácticas comerciales agresivas
- Organismos públicos intentan migrar sus sistemas de correo a una base de código abierto, pero se enfrentan a contratos injustos y sospechas de vigilancia por parte del proveedor
- Cláusulas ocultas en el contrato y cambios unilaterales bloquean la salida libre de los clientes y disparan los costos de administración
- Incluso cuando salen a la luz indicios de vigilancia y lectura de correos electrónicos, las organizaciones se enfocan más en el aumento de costos que en una respuesta legal y ética
- Incluso empresas que enarbolan el espíritu del código abierto terminan incurriendo en casos de abuso, dejando solo daño a la confianza y una imagen negativa para toda la industria
Prólogo del autor
- Esta historia se basa en experiencias reales, pero se modificaron y mezclaron tecnologías, detalles y parte del contexto para proteger la identidad de personas y empresas
- Se recomienda leerla como un caso típico para abordar dos problemas muy extendidos en la industria de TI: el vendor lock-in y las prácticas de negocio agresivas
Proceso – adopción de un nuevo sistema de correo
- Hace algunos años, una importante institución pública (Agency A) seguía usando un servidor de correo Exchange obsoleto
- Hacía mucho que no recibía actualizaciones de seguridad, por lo que el riesgo de exposición era alto, y además aparecieron lineamientos que recomendaban adoptar código abierto
- Un contratista externo propuso un servicio administrado basado en un stack de correo open source, ampliado por ellos mismos y con soporte empresarial
- El precio estaba en un rango similar al que se ve normalmente en el mercado, pero en relación con el servicio real ofrecido era excesivamente alto
- Agency A ya contaba con infraestructura confiable como múltiples centros de datos y bloques IP sólidos
- La solicitud de la institución era: "evaluar esta solución y migrar si resulta adecuada" (alcance: alrededor de 500 buzones y alias)
Piloto y migración exitosa
- El autor aplicó ese stack open source en un entorno no crítico y con algunos clientes de prueba a precio reducido, y lo validó durante un año sin problemas
- Satisfecho con la flexibilidad del diseño, recomendó a Agency A una migración piloto
- Se montaron nuevos servidores, se configuró el dominio para participantes tempranos y se realizó una migración gradual
- Tras cambiar los registros MX, la transición se estabilizó sin problemas, y el equipo interno de la organización mantuvo la operación sin incidentes importantes
Se corre la voz y aparece una segunda institución
- Agency B ya era cliente del mismo proveedor de servicios administrados
- Al ver ventajas como reducir el costo total a una décima parte, ganar autonomía sobre los datos y mejorar la estabilidad, mostró interés en migrar
- Sin embargo, aún le quedaban dos años de un contrato con renovación automática a cinco años, aunque había margen por una cláusula de aviso previo de seis meses
- Por temor a la política comercial agresiva del proveedor y posibles represalias, los preparativos se realizaron con total confidencialidad
- Tras completar la configuración de cuentas, alias y el set de pruebas, se planeó la migración real para coincidir con el momento de notificar la cancelación del contrato
Surge una tercera institución y una mala señal
- Agency C también usaba el mismo proveedor y quería migrar al mismo stack open source
- El autor presentó una cotización por separado a Agency C, sin mencionar su relación con Agency B
- Todo parecía ir bien, hasta que llegó un contacto inesperado por SMS con el mensaje: "no puedo enviar correos"
Obstáculos a la cancelación e indicios de filtración de información interna
- El responsable de TI de Agency B informó que "hubo problemas con la cancelación y el proveedor se enteró de los preparativos internos para irse"
- El proveedor obtuvo acceso tanto a los planes internos de la institución como a la cotización del autor para Agency C
- Desde el lado del proveedor, a Agency C incluso le dijeron que ellos eran "el único instalador autorizado de ese software", y llegaron a lanzar amenazas legales y acusaciones de competencia desleal
- Por temor a un conflicto potencial, la institución abandonó el plan de migración
Sospecha de espionaje de correo y prueba
- En Agency C se confirmó que la cuenta con autenticación por token de un ex administrador contractual externo tenía permiso para acceder a todos los correos
- Esa persona admitió que había "informado" al proveedor, aunque negó haber mencionado al autor
- Para confirmar la sospecha de espionaje, se envió una cotización falsa a través de un conocido en el extranjero, y luego el proveedor mencionó esa información de inmediato
- Con eso, quedó muy claro que la posibilidad de lectura de correos electrónicos era extremadamente alta
Cláusulas contractuales alarmantes y respuesta del proveedor
- Cuando el equipo de TI presentó una protesta formal, el proveedor respondió que "era posible según las cláusulas del contrato", señalando cambios unilaterales aceptados dos años antes
- Ejemplos de las cláusulas modificadas:
- el período de aviso se extendió de 6 meses a 12 meses
- servicios antes gratuitos podían pasar a ser de pago
- con el pretexto de "motivos de seguridad", se podía bloquear el acceso fuera del webmail (y de hecho lo aplicaron de inmediato)
- Eran prácticas posibles en una época anterior a la entrada de GDPR, cuando la regulación todavía no era suficiente
Respuesta tibia y daños adicionales
- El autor intentó aclarar directamente la controversia sobre la competencia leal y el tema del instalador no reconocido, pero el proveedor no respondió a ningún intento de contacto
- Recomendó a las dos instituciones que realizaran una investigación legal y ética, pero en la práctica solo se fijaron en el aumento de costos (funciones antes gratuitas convertidas en pagas, más un 30% adicional)
- Las organizaciones terminaron tratando el tema únicamente como una carga presupuestaria, en lugar de abordar la posible corrupción interna o la violación de datos personales
Desenlace e implicaciones
- Años después, todos los directores responsables fueron reemplazados, y solo el equipo técnico permaneció, con arrepentimiento y mayor cautela
- Al final, todo terminó con una migración hacia un proveedor más seguro, aunque menos innovador
- El autor no logró resolver el problema de raíz
- Cuando una empresa que presume de "soporte a código abierto" incurre en vendor lock-in o conductas poco éticas como estas, toda la industria termina pagando el precio
- El problema central no es el software, sino la actitud de quienes lo manejan
1 comentarios
Comentarios en Hacker News
En algún momento, una persona que había sido gerente interino de TI siguió conectada al cliente de correo mediante autenticación por token y tenía acceso a todos los mensajes. Esta persona había sido originalmente quien firmó el contrato con el proveedor en el pasado. Al preguntarle informalmente, dijo que se había comunicado "para advertir" y que no había ningún problema. Este tipo de conducta realmente deja muy mala sensación. Es por gente que filtra algo o incumple normas y luego dice "no fue nada". Un Director con el que trabajo ha hecho cosas parecidas varias veces. Si descubre software en una conferencia, de inmediato agenda una demo y propone un contrato. Y primero promete trabajo a una consultora externa que conoce. Como en realidad no tiene autoridad para contratar, recién entonces me contacta a mí. Incluso después de que me encargaran la selección de productos, esto pasó dos veces más. Cada vez trabajaba bajo un gerente distinto, pero ambos solo decían que "no había ningún problema". Al final, le señalaron al Director que prometer trabajo y preparar contratos de esa forma violaba gravemente la política de la empresa. Al Director ni le importó, diciendo que era un asunto interno y que nadie podía sancionarlo. Más tarde, cuando revisamos el producto, este prometía que "mejoraría con el tiempo", y todos los datos de la empresa estaban entrando sin más a la IA. No le importaban para nada las reglas de seguridad de datos corporativos. En ese momento también el Director respondió con indiferencia: "¿Cuál es el problema? Todos leen los datos de los demás". Al final intervino el equipo legal y desactivó la función de IA. Es realmente difícil enfrentarse a colegas malintencionados o imprudentes así, y todavía más incómodo cuando esa persona está por encima de uno. Simplemente lo hacen pasar por un error y siguen adelante, y nadie puede sancionarlos
Trabajé en dos empresas Fortune 100. Vi repetidas veces, y de forma bastante abierta, a gerentes recibiendo reembolsos personales de proveedores. Después de señalarlo públicamente, dejaron de invitarme a varias reuniones
Lo que hizo ese Director se parece muchísimo a lo que he visto hacer normalmente a directores de RR. HH. A estas personas les encanta cambiar cada 2 o 3 años todo tipo de software carísimo de evaluación de desempeño sin consultar a nadie. Al menos Lattice, que es su favorito últimamente, tiene una UX decente; PeopleSoft, que usaban antes, sí era terrible
La solicitud era simple: "evaluemos esta solución y, si encaja, migremos". Pero tuve que leerlo varias veces para entenderlo bien. La solución de la que se hablaba aquí se refería solo al stack open source, sin el proveedor mencionado en el párrafo anterior. Al principio pensé que incluía también al proveedor, pero luego empezaron a comparar cosas y me confundí
Yo también entendí ese punto solo después de leer varios párrafos
Qué interesante. Yo dejé de leer justo en esa parte
Me da la impresión de que están hablando de Oracle. Claro que Oracle maneja estas cosas mucho más sutilmente, pero yo siempre le recomiendo a la gente mantenerse lo más lejos posible de los productos de Oracle
Ojalá llegue el día en que esta historia se cuente con nombres reales
Según el autor, la empresa en cuestión demanda muchísimo. Es totalmente comprensible querer evitar una situación en la que te demanden personalmente. Ni siquiera sus propios directores querrían pelearse con esa empresa
Alguien dijo: "ojalá algún día se revele con nombres reales". Pero la respuesta fue que se escribió en anonimato para "proteger la privacidad de los involucrados y de la empresa". Me hace pensar si ahora las empresas también tienen derecho a la privacidad, aunque entiendo el sentimiento. Yo trabajé en una empresa que hizo algo absolutamente imperdonable durante un desastre natural. Cuando planteé el problema, fui el único sancionado, mientras mis colegas simplemente lo soportaban en silencio. Al final renuncié en la primera oportunidad. Ya pasaron 20 años, pero aun así no es fácil dejar esa historia por escrito. Como ya han pasado décadas, uno se pregunta si todavía tiene sentido, y como el liderazgo y hasta el nombre de la empresa cambiaron, también se pregunta qué queda de aquello. Por eso en mi blog tengo un dead-man's switch para publicar automáticamente varias cosas desagradables de distintas empresas, pero dudo que, aunque alguien lo viera, cambiara algo. Probablemente solo daría rabia o no serviría de nada. Aun así, yo mismo soy de los que siempre andan diciendo en HN que revelen los nombres reales, así que al final también soy contradictorio
Por desgracia, están en la UE, donde al parecer la libertad de expresión no se valora tanto ni legal ni culturalmente
Esta persona realmente parece trabajar en un entorno tipo "campo minado". Cada paso hace explotar un problema y enfrente hay enemigos poderosos enlace relacionado
Puede que esté confundiendo la línea de tiempo o a las partes involucradas, pero cuando dice que "esta empresa propuso una versión autoadministrada y un producto con funciones propias", me pregunto si eso realmente sigue siendo open source
Hay muchos proyectos así. Por ejemplo, Gitlab tiene una Community Edition open source, y también las ediciones Premium y Ultimate de pago
Este es un caso de "cumplir solo con la letra de la ley". En Europa, y sobre todo en las leyes nacionales europeas, muchas veces es obligatorio usar open source en el sector público por razones como garantizar la interoperabilidad, evitar el vendor lock-in, mantener la soberanía digital y el principio de "fondos públicos = código público". Si usas open source en el servidor de otro, técnicamente cumples con la obligación, pero si piensas en la razón real para adoptar open source, especialmente evitar el vendor lock-in, la situación resulta bastante ridícula
Los detalles del contrato siempre deben leerse con mucho cuidado antes de firmar. Eso aplica a contratos de consumo en general, pero en contratos empresariales es indispensable
Tampoco los contratos pequeños de negocio son la excepción. En una organización sin fines de lucro donde formo parte de la junta, el personal evaluó fotocopiadoras multifunción para la oficina y trajo un contrato. Me dijeron que ya estaba todo revisado y que solo firmara, pero las cláusulas eran realmente impactantes. Por ejemplo, decía que, si cancelábamos por cualquier motivo —incluso si la otra parte incumplía el contrato—, teníamos que pagar de inmediato todo el monto restante del contrato. Como era una estructura de arrendamiento, el costo total del equipo ya estaba incluido en las cuotas mensuales, pero la propiedad del equipo seguía siendo de la empresa proveedora. Al final, aunque canceláramos, el equipo seguía siendo suyo y nosotros pagábamos todo igual. Incluso si había una disputa legal, nosotros asumíamos todos los honorarios de abogados. Yo dije que jamás aceptaría eso, y el personal estuvo molesto conmigo durante casi un año porque "en todos lados firman eso"
El consejo es leer bien hasta la letra chica, pero en realidad el texto muestra que a veces ni eso sirve. Cada vez hay más casos donde los términos del contrato cambian "unilateralmente" y ni siquiera se notifica a la otra parte. En la industria de TI esto ya es casi cotidiano. Da igual cuánto revises la letra chica de un contrato ya firmado si después la cambian. Hoy en día, si al menos te llega un correo avisando que cambiaron los términos, ya tuviste suerte. La actitud es básicamente "¿y qué vas a hacer si no aceptas?". Si no fueras abogado dirías que eso es ilegal, pero como los courts nunca lo sancionan de verdad, se sigue repitiendo
Hay que considerar como parte del costo el tiempo y esfuerzo de interpretar y revisar un contrato, así como el riesgo de entenderlo mal. Si piensas en eso, a veces es mejor simplemente no celebrar ciertos contratos
Me da curiosidad cómo funciona en la práctica una "cláusula de modificación unilateral". Si no te gusta la letra chica, ¿entonces tienes que avisar con 6 meses de anticipación y cancelar de inmediato?
Me impactó leer el contrato de registro de ID.me. Te piden renunciar "voluntariamente" a la ciudadanía. Por eso no quiero usarlo. Pero no hay otra forma de iniciar sesión en IRS.gov. Para ver YouTube necesitas una cuenta de Google. Para participar en el grupo de padres del chat necesitas aceptar los términos de Meta en WhatsApp. Casos así no se terminan nunca
No soy un experto legal, pero creo que el propio objetivo de leer los correos y actuar en función de ello es claramente ilegal, así que el contrato mismo debería considerarse nulo
Especialmente si esto fuera un organismo gubernamental, sería realmente impactante. ¿Qué pasaría si un proveedor externo instalara en secreto una puerta trasera en el servidor de correo y vigilara en secreto los emails? Podría ser cualquier cosa, desde corrupción hasta actividades de inteligencia extranjera. Si esto hubiera pasado en Estados Unidos, el FBI o la CIA ya habrían intervenido para limpiar por completo un problema de proveedor así
Exacto. El problema es que, si decides rescindir, tienes que enfrentarte en tribunales a una contraparte extremadamente hostil, y ellos harán todo lo posible para obligarte a pagar más. Algunas organizaciones priorizan la seguridad por encima de la ética y simplemente asumen el costo adicional. Por otro lado, sin duda existen empresas que sí pelean para acabar con demandas injustas de patentes o cláusulas contractuales absurdas. Esta organización claramente no era de esas
No es asesoría legal, pero creo que este tipo de cosas hay que denunciarlas con nombres reales para advertir a los demás
Creo que mucha gente en HN habrá pasado por situaciones parecidas. Hace tiempo estábamos apagando un sistema de manera confidencial, y nuestra empresa compartía el codebase con una empresa socia. Uno de nuestros desarrolladores dejó en un commit algo como "Reversing Migration Script" y, menos de una hora después, se armó una pelea enorme entre los CEOs de ambas empresas. Después nos enteramos de que la otra empresa monitoreaba en tiempo real palabras como esa dentro del código, y en cuanto detectó señales de que nos íbamos a separar, actuó de inmediato. En realidad estábamos terminando la relación legalmente al vencimiento del contrato, así que tampoco había nada especialmente raro. Cuando más tarde supimos que existía esa vigilancia, dentro de la empresa incluso hubo una cacería de brujas buscando quién era el "espía". Fue una experiencia realmente dura. Ahora parece que vivimos en un mundo donde este tipo de conductas casi psicopáticas ya se volvió normal. Yo soy el único que parece trabajar de forma ingenua, como alguien de otra época, así que es lógico que haya tantas empresas que solo quieran contratar veinteañeros /medio en broma
Estaría bueno que compartieras específicamente cómo monitoreaban eso. Quisiera aprender de casos así
Conviene poner nombres de variables que se disparen con facilidad en lugares que puedan estar siendo vigilados. Como esos chistes de antes sobre la NSA
Dice que es una "historia de terror basada en hechos reales", pero me pregunto si de verdad lo es. Sería más interesante si los detalles fueran ciertos