Lo esencial
- Un profesor de sistemas operativos acertó en casi todas sus críticas técnicas y aun así erró en el pronóstico.
- El sistema que criticó ya existía, cualquiera podía usarlo y mejoró más rápido de lo que se esperaba.
- Para decidir una tecnología, pregunta cuánto puede mejorar cada opción, no solo cuáles son sus defectos hoy.
Hace más de tres décadas, un especialista en sistemas operativos escribió que Linux estaba obsoleto y pronto desaparecería. Hoy corre en la mayoría de los sitios web cuyo sistema se puede identificar, en celulares con Android y en las supercomputadoras. Sus críticas eran sólidas. Su pronóstico, no.
Te comparto por qué creo que esa historia importa a quien dirige una empresa técnica: cada vez que compras un sistema, una máquina o una plataforma, estás repitiendo ese debate en pequeño.
Qué discutían
Tanenbaum defendía una arquitectura de núcleo pequeño, con los demás servicios en procesos separados. Su ventaja: si algo falla, el resto sigue en pie. Linux, en cambio, concentraba casi todo adentro del núcleo, y nació para un solo tipo de procesador.
Torvalds reconoció que la idea del otro podía ser más elegante sobre el papel. Pero tenía algo que su crítico no: un sistema que ya funcionaba. La alternativa que se proponía todavía no estaba lista.
62.5%
de los sitios web cuyo sistema operativo se puede identificar usan Linux. Lo que se llamó obsoleto es hoy el estándar de hecho.
Lo que cambió el resultado
La disponibilidad. Como cualquiera podía descargarlo, modificarlo, añadirle controladores y llevarlo a nuevo hardware, Linux mejoró a gran velocidad. Llegó a otras arquitecturas, y lo que parecía su gran defecto, depender de un solo procesador, se corrigió con el tiempo.
Esta es la parte que más me interesa: el defecto que justificaba la predicción dejó de existir. Quien juzgó solo el estado del día, juzgó mal el estado del año.
Cómo se ordena
- Inicio: Un sistema para un solo procesador, sin portabilidad.
- Después: Versiones para otras arquitecturas; el defecto se vuelve ventaja.
- Con los años: Un diseño modular que carga componentes sin recompilar todo.
- Hoy: Servidores, celulares y supercomputadoras.
Cómo aplicarlo a una compra técnica
- Disponibilidad: ¿puedo ponerlo a trabajar esta temporada, o dependo de una promesa de entrega?
- Capacidad de mejora: ¿quién corrige las fallas y con qué rapidez?
- Ecosistema: ¿cuántos proveedores, técnicos y refacciones existen más allá de quien lo fabrica?
- Costo de salida: si me equivoco, ¿cuánto me cuesta cambiar?
Ninguna de estas preguntas mide qué tan bonito es el diseño. Miden margen de maniobra. Y en una compra técnica, el margen de maniobra es lo que te permite corregir sin parar la operación.
Haz el ejercicio con una decisión real y por escrito. Cuando una opción solo gana en elegancia, lo normal es que el equipo lo note al explicarla y no al defenderla.
Mi lectura: en una empresa industrial, la tentación es comprar lo más sofisticado porque suena a rigor. A veces es lo correcto, sobre todo donde un fallo es carísimo; ahí el aislamiento y la fiabilidad que defendía Tanenbaum siguen teniendo mucho peso. Pero la sofisticación que nadie puede mantener a tiempo no ayuda. Prefiero la opción imperfecta que mi equipo puede operar y corregir que la ideal que depende de una sola persona.
Errores que conviene evitar
- Comparar solo los defectos de hoy y no cuánto pueden mejorar.
- Elegir por elegancia técnica sin preguntar quién la va a mantener.
- Depender de un proveedor único sin un plan de salida.
- Descartar una opción imperfecta que ya funciona por una promesa de algo mejor que aún no existe.
- Ignorar el costo de equivocarse: si cambiar sale carísimo, la decisión pide más cuidado.
Y en México
muchas plantas conviven con equipos de generaciones distintas, y la pregunta de si cambiar o seguir con lo que funciona aparece cada año. La respuesta rara vez es ideológica. Se resuelve con datos de tu operación: cuánto cuesta una hora de paro, qué refacciones hay en la región y quién en tu equipo puede intervenir.
Preguntas frecuentes
¿Quién tenía razón en el debate sobre Linux?
Los dos en parte. El crítico describió limitaciones reales; el creador apostó por lo que ya existía y podía mejorar con ayuda de otros.
¿Qué conviene priorizar al comprar tecnología para una empresa?
Que funcione ya, que se pueda mejorar con rapidez y que existan personas capaces de mantenerla. La elegancia importa, pero después de esas tres cosas.
¿Cuándo sí se justifica la opción más sofisticada?
Cuando el costo de una falla es muy alto y tienes quién sostenerla. Ahí la fiabilidad pesa más que la rapidez de adopción.
Checklist para aplicarlo
- Escribí qué decisión técnica tengo pendiente.
- Respondí las cuatro preguntas para cada opción que estoy comparando.
- Identifiqué quién en mi equipo puede mantener cada alternativa.
- Calculé cuánto me costaría salirme de la opción elegida si me equivoco.
Para aplicar hoy
Toma la decisión técnica que tienes pendiente y escribe, para cada opción, cuánto puede mejorar en un año y quién la mejoraría. Esa respuesta suele pesar más que el defecto de hoy.
Juan Pablo Ayala
Consultor de marca. Diagnostico dónde se está rompiendo el crecimiento de una empresa, defino la estrategia y sostengo la ruta. También dirijo Mixen, mi agencia, por si el plan necesita manos.
