¿Alguna vez has detectado un error extraño en una aplicación de un teléfono que acababas de comprar y, tras avisar a la empresa desarrolladora, has recibido unos días después una respuesta en la que te decían que ya se habían acumulado avisos de cientos de personas con el mismo problema y que la versión corregida había salido al poco tiempo? Incluso los problemas cuya causa cuesta imaginar por cuenta propia suelen resolverse con sorprendente rapidez cuando varias personas los examinan juntas. La idea de que los errores salen a la luz con más facilidad cuantos más ojos los buscan se conoce como «ley de Linus» (Linus's Law).
En pocas palabras, la ley de Linus es una regla empírica según la cual «si hay suficientes ojos mirando, todos los errores quedan a la vista». Durante mucho tiempo se ha citado como una de las fórmulas más representativas para explicar por qué es eficaz el desarrollo de código abierto (Open Source), que consiste en publicar el código fuente para que cualquiera pueda examinarlo.
Veremos, por orden, cómo surgió esta ley y qué significa exactamente, por qué funciona cuando hay muchos ojos observando, qué casos han puesto de manifiesto sus límites y cómo aplicarla en la práctica.
Cómo ayudan muchos ojos a proteger el software y cuáles son los límites
¿Qué es la ley de Linus?
El programador estadounidense Eric S. Raymond formuló esta ley en el ensayo «La catedral y el bazar» (The Cathedral and the Bazaar), que presentó por primera vez en 1997 y publicó como libro en 1999. La ley toma su nombre del desarrollador finlandés Linus Torvalds, que creó la primera versión del núcleo de Linux en 1991. En Corea se suele usar una pronunciación del nombre de la ley que sigue la del inglés.
Raymond formuló la ley con mayor precisión de este modo: «Si hay suficientes personas probando las versiones beta y colaborando en el desarrollo, casi todos los problemas se identifican rápidamente y su solución le resulta evidente a alguien».
(1) Modelo de la catedral
Un grupo reducido de especialistas diseña el software minuciosamente a puerta cerrada y solo publica el resultado cuando ha alcanzado un alto grado de acabado. Este modelo parte de la idea de que los errores están muy ocultos y solo se pueden encontrar tras un largo periodo de pruebas.
(2) Modelo del bazar
El software se publica pronto y con frecuencia, y se permite que cualquiera aporte comentarios y proponga correcciones. Así se desarrolló Linux, y Raymond consideraba que los errores salían pronto a la luz gracias al gran número de participantes.
Cómo ayudan muchos ojos a detectar errores
La idea central de la ley de Linus es que distintas personas pueden repartirse la detección y la corrección de los errores. Aunque la primera persona que se topa con un problema desconozca su causa, a otra se le puede ocurrir de inmediato cómo resolverlo al ver los síntomas.
- Diversidad de entornos de uso (Diverse Environments): cada persona utiliza dispositivos distintos y los emplea para fines diferentes, por lo que surgen problemas en situaciones que el desarrollador no llegó a probar.
- Revisión por pares (Peer Review): otros desarrolladores leen el código y señalan errores que su autor pasó por alto.
- Depuración en paralelo (Parallel Debugging): varias personas investigan la causa al mismo tiempo y encuentran pistas más rápido que una persona trabajando sola.
(1) La persona que informa de los síntomas
Si el usuario que se topa con el error documenta con precisión cómo reproducirlo, se reduce considerablemente el tiempo necesario para acotar sus posibles causas.
(2) La persona que reconoce la causa
A un desarrollador que ya se ha enfrentado a un problema parecido, un error que otros ven como algo muy oculto puede parecerle fácil de localizar. A eso se refiere la ley cuando dice que los errores son «superficiales». Cuantas más personas participan, más probable es encontrar a alguien así.
Casos que mostraron los límites de la ley
[Caso 1] Heartbleed pasó inadvertido durante más de 2 años
El código que se incorporó tras una revisión a finales de 2011 en OpenSSL, un programa de código abierto muy utilizado para cifrar las comunicaciones por internet, contenía un defecto. El defecto se propagó a partir de la versión distribuida en el mes 3 de 2012, aunque solo se dio a conocer en el mes 4 de 2014 con el nombre de Heartbleed. Cuando se hizo público, se estimó que estaban en riesgo alrededor del 17 % de los servidores web que utilizaban certificados de seguridad de confianza, unos 50 grupos de diez mil servidores. En el mes 9 de ese mismo año también se descubrió Shellshock, un defecto en Bash, un intérprete de comandos muy utilizado en Linux y otros sistemas, que había pasado inadvertido durante unos 25 años desde 1989.
[Caso 2] Software esencial en manos de unos pocos
Cuando Heartbleed salió a la luz, el mantenimiento de OpenSSL estaba a cargo de unos pocos voluntarios, de los cuales solo uno se dedicaba al desarrollo a tiempo completo. El caso mostró que, incluso si el código está al alcance de todos, los errores pueden pasar inadvertidos durante mucho tiempo si nadie lo examina con detenimiento. Inmediatamente después del incidente, la Fundación Linux creó, junto con varias empresas importantes, un fondo para apoyar proyectos esenciales de código abierto.
Cómo aplicar la ley de Linus en la práctica
El ingeniero de software Robert Glass cuestionó esta ley. Señaló que aumentar el número de revisores no incrementa en la misma proporción la cantidad de errores detectados y citó investigaciones según las cuales en torno a dos, tres o cuatro revisores hacen aportaciones útiles. También hay análisis que han encontrado tasas más altas de corrección de errores en los proyectos de código abierto más populares, por lo que el debate continúa. En definitiva, importa más cuántas personas examinan realmente el código que cuántas tienen acceso a él.
(1) Incorporar la revisión del código al proceso de trabajo
Si al menos un colega lee y aprueba cada cambio antes de incorporarlo, es posible beneficiarse de que haya más ojos pendientes del código, sea este público o privado.
(2) Dedicar personal y recursos al código esencial
Cuantos más servicios dependan de un componente esencial, más necesario es asignarle responsables específicos y someterlo a auditorías de seguridad periódicas.
(3) Facilitar la notificación de errores
Si los usuarios pueden informar fácilmente de los problemas y seguir el estado de sus avisos, se suman de forma natural más personas ajenas al equipo.
(4) Cubrir los puntos ciegos con herramientas automatizadas
Las herramientas de pruebas automatizadas permiten comprobar repetidamente los errores en valores límite que suelen pasar inadvertidos en las revisiones manuales.
La ley de Linus expresa en una frase la convicción de que la colaboración abierta puede mejorar la calidad del software. Como recordó Heartbleed, publicar el código por sí solo resulta insuficiente. Para que la ley funcione, hace falta que haya personas que realmente lean y prueben ese código.
El primer paso para conseguir un software seguro es reunir a personas que examinen de verdad el código disponible.
