La Ley de Linus fue  formulada por Eric Raymond, en su clásico ensayo La Catedral y el Bazar, de esta manera:

«Dado un número suficientemente elevado de ojos, todos los errores se convierten en obvios»

Parte de la idea de que todo problema deberá ser transparente para alguien. Las personas que entienden y las que resuelven un problema pueden no ser necesariamente las mismas:

«Alguien encuentra el problema y otro lo resuelve».

Estas dos afirmaciones que se han denominado “Ley de Linus“, en referencia a declaraciones realizadas por Linus Torvalds, ingeniero de software finlandés, creador de Linux. La primera de ellas hace referencia a la capacidad de encontrar errores al abrir el código fuente de un programa a la comunidad, y la segunda a la motivación para el desarrollo de código libre.

Algunos estudios han analizado y criticado la ley de Linus. Los expertos en desarrollo de software Robert Glass, Michael Howard y David LeBlanc han determinado que la aplicación de la ley de Linus puede generar problemas en el mantenimiento y la seguridad del software, para lo cual citan el número relativamente bajo de contribuciones hechas a los proyectos open-source por parte de «externos»: donde se entiende por «externos» a los contribuyentes que no pertenecen al pequeño núcleo de desarrolladores que trabajan en el proyecto.

Esto es el resultado directo de la atención necesaria que los desarrolladores deben tener al construir un entorno y comprender una porción de código antes de poder contribuir efectivamente en él. Algunos proyectos tienden a desconfiar de las contribuciones externas, con el temor de que traten de generar errores de código difíciles de encontrar o huecos de seguridad y, por lo tanto, esos proyectos crean un inconveniente proceso de revisión que puede desalentar el desarrollo externo.

Linus Torvalds también habla sobre la ley de Linus en el prólogo del libro La ética del hacker. La ley de Linus dice:

Todas nuestras motivaciones caen en tres categorías básicas. Y lo que es aún más importante, el progreso consiste en ir pasando de una categoría a otra, como «fases» de un proceso de evolución. Las categorías, en orden, son: «supervivencia», «vida social» y «entretenimiento».

Esta idea es similar a la pirámide de necesidades, que desarrolló el psicólogo humanista norteamericano Abraham Maslow.

Aquí un fragmento de La Catedral y el Bazar de Eric Raymond:

“Dada una base suficiente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado rápidamente, y su solución ser obvia al menos para alguien.

O, dicho de manera menos formal, “con muchas miradas, todos los errores saltarán a la vista”. A esto lo he bautizado como la Ley de Linus.

Mi formulación original rezaba que todo problema deberá ser transparente para alguien. Linus descubrió que la personas que entendían y la que resolvían un problema no eran necesariamente las mismas, ni siquiera en la mayoría de los casos. Decía que “alguien encuentra el problema y otro lo resuelve”. Pero el punto está en que ambas cosas suelen suceder con gran rapidez.

Aquí, pienso, subyace una diferencia esencial entre el estilo del bazar y el de la catedral. En el enfoque estilo catedral de la programación, los errores y problemas de desarrollo son fenómenos truculentos, insidiosos y profundos. Generalmente toma meses de revisión exhaustiva para unos cuantos el alcanzar la seguridad de que han sido eliminados del todo. Por eso se dan los intervalos tan largos entre cada versión que se libera, y la inevitable desmoralización cuando estas versiones, largamente esperadas, no resultan perfectas.

En el enfoque de programación estilo bazar, por otro lado, se asume que los errores son fenómenos relativamente evidentes o, por lo menos, que pueden volverse relativamente evidentes cuando se exhiben a miles de entusiastas desarrolladores asistentes que colaboran al parejo sobre cada una de las versiones. En consecuencia, se libera con frecuencia para poder obtener una mayor cantidad de correcciones, logrando como efecto colateral benéfico el perder menos cuando un eventual obstáculo se atraviesa.

Y eso es todo. Con eso basta. Si la Ley de Linus fuera falsa, entonces cualquier sistema suficientemente complejo como el kernel de Linux, que está siendo manipulado por tantos, debería haberse colapsado en un punto bajo el peso de ciertas interacciones imprevistas y errores “muy profundos” inadvertidos. Pero si es cierta, bastaría para explicar la relativa ausencia de errores en el código de Linux.

Despu&aecute;s de todo, esto no debí parecernos tan sorpresivo. Hace algunos años los sociólogos descubrieron que la opinión promedio de un numero grande de observadores igualmente expertos (o igualmente ignorantes) es más confiable de predecir que la de uno de los observadores seleccionado al azar. A esto se le conoce como el efecto Delphi. Al parecer, lo que Linus ha demostrado es que esto también es valedero en el ámbito de la depuración de un sistema operativo: que el efecto Delphi puede abatir la complejidad implícita en el desarrollo, incluso al nivel de la involucrada en el desarrollo del núcleo de un OS.

Estoy en deuda con Jeff Dutky, quien me sugirió que la Ley de Linus puede replantearse diciendo que “la depuración puede hacerse en paralelo”. Jeff señala que a pesar de que la depuración requiere que los participantes se comuniquen con un programador que coordina el trabajo, no demana ninguna coordinación significativa entre ellos. Por lo tanto, no cae víctima de la asombrosa complejidad cuadr&acaute;tica y los costos de maniobra que ocasionan que la incorporación de desarrolladores resulte problemática.

En la práctica, la pérdida teórica de eficiencia debido a la duplicación del trabajo por parte de los programadores casi nunca es un tema que revista importancia en el mundo Linux. Un efecto de la “política de liberar rápido y a menudo” es que esta clase de duplicidades se minimizan al propagarse las correcciones rápidamente.

Brooks hizo una observación relacionada con la de Jeff: “El costo total del mantenimiento de un programa muy usado es típicamente alrededor del 40 por ciento o más del costo del desarrollo. Sorpresivamente, este costo está fuertemente influenciado por el número de usuarios. Más usuarios detectan una mayor cantidad de errores.” (El subrayado es mío).

Una mayor cantidad de usuarios detecta más errores debido a que tienen diferentes maneras de evaluar el programa. Este efecto se incrementa cuando los usuarios son desarrolladores asaitentes. Cada uno enfoca la tarea de la caracterización de los errores con un bagaje conceptual e instrumentos analíticos distintos, desde un ángulo diferente. El efecto Delphi parece funcionar precisamente debido a estas diferencias. En el contexto específico de la depuración, dichas diferencias también tienden a reducir la duplicación del trabajo.

Por lo tanto, el agregar más beta-testers podría no contribuir a reducir la complejidad del “más profundo” de los errores actuales, desde el punto de vista del desarrollador, pero aumenta la probabilidad de que la caja de herramientas de alguno de ellos se equipare al problema, de tal suerte que esa persona vea claramente el error.

Linus también dobla sus apuestas. En el caso de que realmente existan errores serios, las versiones del kernel de Linux son enumeradas de tal manera que los usuarios potenciales puedan escoger la última versión considerada como “estable” o ponerse al filo de la navaja y arriesgarse a los errores con tal de aprovechar las nuevas características. Esta táctica no ha sido formalmente imitada por la mayoría de los hackers de Linux, pero quizá debían hacerlo. El hecho de contar con ambas opciones, lo vuelve aún más atractivo.”

Este blog: http://www.lnds.net/blog/2008/05/la-ley-de-linus.html contiene una reflexión sobre la Ley y sus posibles refutaciones.