Esta creencia reforzaba la adhesión generalizada al modelo de construcción de catedrales para el desarrollo de un programa. Si el objetivo prioritario consistía en exponer al usuario final al menor número posible de errores, no había razón para lanzar versiones de prueba en menos de seis meses (o incluso mucho menos a menudo) y tener que trabajar como un perro para depurarlas entre lanzamiento y lanzamiento. El núcleo en C de Emacs se desarrolló así. La librería en Lisp, sin embargo, no -- por cuanto existían depósitos activos de código en Lisp fuera del control de la FSF a los que se podía acudir para encontrar versiones nuevas y en desarrollo saltándose los ciclos de lanzamiento de Emacs.
El más importante de todos ellos, el depósito de 'elisp' de la Universidad Ohio State, anticipó el espíritu y muchas de las características de los grandes depósitos Linux de la actualidad. Pero pocos de nosotros prestamos atención a lo que estábamos haciendo, o a los problemas relacionados con el estilo de construcción de catedrales empleado por la FSF que la mera existencia de tales archivos implicaba. Hacia 1992, traté seriamente de incorporar formalmente una buena parte del código Ohio a la librería oficial de Emacs Lisp. Topé con problemas políticos y fue prácticamente un desastre...
Pero cosa de un año después, conforme Linux se hacía cada vez más visible, quedó claro que algo distinto y mucho más saludable estaba ocurriendo. La política de desarrollo abierto de Linus era justo lo contrario del estilo catedral. Los depósitos de 'sunsite' y 'tsx-11' estaban a rebosar, y aparecieron varias distribuciones. Y todo ello era el fruto de lanzamientos del núcleo del sistema a una frecuencia insólita.
Linus estaba tratando a sus usuarios como colaboradores de la forma más eficaz que imaginarse pueda:
7. Lánzalo pronto. Lánzalo a menudo. Y escucha a tus usuarios.
La innovación de Linus no consistió tanto en cómo hacer las cosas (algo parecido había sido ya tradición en el mundo Unix durante mucho tiempo), sino en llevarlo a una escala del mismo nivel que la complejidad del proyecto que estaba acometiendo. No era raro que en aquellos tiempos ¡lanzara más de una versión nueva del núcleo al día!. Y, debido a que cuidaba su base de colaboradores y usaba los recursos ofrecidos por Internet para la colaboración mejor que nadie, funcionó.
Pero ¿cómo funcionó?. ¿Era algo que yo pudiera reproducir o dependía de alguna extraña habilidad de Linus?.
No lo creía así. Por supuesto que Linus es un hacker condenadamente capaz (¿cuantos de nosotros seríamos capaces de construir el núcleo completo de un sistema operativo con calidad a nivel de producción?). Pero Linux no representaba ningún salto conceptual aterrador. Linus no es (o al menos no lo es todavía) un genio innovador del diseño a la manera en que lo son, por poner un par de ejemplos, Richard Stallman o James Gosling. Linus me parece más bien un genio de la ingeniería, con un sexto sentido para evitar errores y vías muertas en el desarrollo y una maravillosa capacidad para encontrar el camino de menor resistencia que conecta el punto A con el B. De hecho, el propio diseño de Linux respira esta cualidad y refleja esa aproximación conservadora y simplificadora tan propia de Linus.
Por tanto, si los lanzamientos rápidos y el empleo de Internet no eran accidentes sino partes integrales del genio ingenieril de Linus que le llevaba a localizar el camino de mínimo esfuerzo ¿qué era lo que estaba maximizando?. ¿Qué producía su maquinaria?.
Así planteada, la pregunta se contesta sola. Linus estaba manteniendo a sus colaboradores/usuarios en un continuo estímulo y una recompensa constante -- estimulados por la perspectiva de tener un trozo de la acción a su disposición para satisfacer su ego, y recompensados por la visión de una mejora continua (incluso diaria) de su trabajo.
Linus estaba intentando maximizar directamente el número de horas por persona dedicadas a la depuración y el desarrollo aún a costa de aumentar la inestabillidad del código y arriesgarse a quemar a su base de usuarios si algún error serio terminaba por ser imposible de solucionar. Linus se estaba comportando como si creyera algo parecido a esto:
8. Dada una base lo suficientemente amplia de probadores y colaboradores, casi todos los problemas se identificarán con rapidez y su solución será obvia para alguien.
O, expresado con menor formalidad, "Con un número de ojos suficiente, todos los errores son naderías". Yo lo llamo "La ley de Linus".
Al principio yo lo planteaba diciendo que todo problema "sería transparente para alguien". Linus observó que aquel que entiende y soluciona un problema no necesariamente, y ni siquiera habitualmente, es quien primero lo caracteriza. "Alguien encuentra un problema", dice, "y algún otro lo entiende. Y me atrevo a decir que la parte más difícil es encontrarlo". Pero lo importante es que ambas cosas tienden a ocurrir con rapidez.
Esta es, creo, la diferencia fundamental entre los estilos catedral y bazar. De acuerdo con la forma en que contempla la programación quien lo hace al modo en que se construye una catedral, los errores y los problemas de desarrollo son fenómenos insidiosos, profundos y retorcidos. Hacen falta meses de escrutinio por un pequeño número de gente dedicada a ello para poder confiar en que se hayan eliminado. De ahí los periodos largos requeridos para el lanzamiento de nuevas versiones, y el inevitable disgusto experimentado cuando las que tanto tiempo se han esperado no resultan perfectas.
A la luz del modelo bazar, en cambio, se supone que los errores son normalmente asuntos leves -- o, al menos, que se convertirán en tales con bastante rapidez en cuanto se expongan a los ojos ansiosos de algunos miles de colaboradores dedicados a poner del derecho y del revés cada nueva versión. Así que te dedicas a lanzar versiones con frecuencia para conseguir aún más correcciones, y como un beneficioso efecto colateral logras tener menos que perder si haces alguna chapuza de vez en cuando.
Y esto es todo. Y ya basta. Si la "ley de Linus" es falsa, entonces cualquier sistema tan complejo como el núcleo de Linux, producido artesanalmente y de manera aficionada, debería haberse colapsado en algún momento bajo el peso de interacciones perjudiciales no previstas y de errores profundos no descubiertos. Por otra parte, si es cierta, basta para explicar la relativa falta de defectos en Linux.
Y quizá no debiera haber sido una sorpresa. Hace algunos años que los sociólogos descubrieron que el promedio de las opiniones de un grupo de observadores igualmente experto (o igualmente ignorante) es un estimador bastante más fiable que el obtenido a partir de un grupo elegido aleatoriamente. Lo llaman "efecto Delphi". Parece que lo que Linus ha puesto de manifiesto es que lo anterior se aplica también a la depuración de un sistema operativo -- que el efecto Delphi puede mitigar la complejidad del desarrollo incluso al nivel de complejidad asociado al núcleo de un sistema operativo.
Tengo una deuda con Jeff Dutky <dutky@wam.umd.edu> por apuntar que la ley de Linus podía reformularse diciendo que "la depuración es paralelizable". Jeff hace notar que aunque la depuración requiere que los que la realizan se comuniquen a través de alguien que coordine el proceso, no precisa de una gran coordinación entre ellos. No está sujeta por tanto a ese aumento cuadrático de complejidad y costes que convierten en un problema la simple adición de programadores.
En la práctica, la pérdida teórica de eficacia debida a la duplicación del trabajo por los depuradores casi nunca parece ser un problema en el mundo Linux. Otro efecto de la política de lanzamientos tempranos y frecuentes consiste en minimizar tal redundancia de esfuerzos mediante la difusión rápida de correcciones ya realizadas.
Brooks incluso realizó una observación original relacionada con la de Jeff: ``El coste total de mantenimiento de un programa de uso generalizado viene a ser de un 40 por ciento o más del coste necesario para su desarrollo. Resulta sorprendente, sin embargo, que este coste depende fuertemente del número de usuarios. Más usuarios implica que se encuentran mas errores." (El énfasis es mío).
Un número mayor de usuarios encuentra más errores debido a que añade muchas más formas diferentes de forzar el programa. Este efecto se amplifica cuando los usuarios colaboran en el desarrollo. Cada uno enfoca la caracterización de los errores con un esquema de percepción y un conjunto de herramientas ligeramente distinto, mirando el problema desde otro punto de vista. El "efecto Delphi" parece funcionar precisamente por causa de esta diversidad. En el contexto de la depuración de un programa, esta variación tiende también a reducir la duplicación de esfuerzos.
En consecuencia, añadir más personas al ciclo de prueba y depuración puede no reducir la magnitud del error más profundo existente en un momento dado desde el punto de vista del que desarrolla el programa, pero aumenta la probabilidad de que las herramientas de alguien resulten adecuadas a su detección de tal manera que dicho error resulte una nadería para esa persona.
Linus toma también algunas precauciones adicionales. Si es probable que existan errores importantes, las versiones del núcleo se numeran de tal forma que los usuarios potenciales puedan elegir entre emplear la última versión etiquetada como "estable" o pasear por el filo de la navaja exponiéndose a errores si desean nuevas posibilidades. La mayoría de los 'hackers' del mundo Linux no imitan aún formalmente esta táctica, pero quizá debieran hacerlo pues el hecho de disponer de ambas opciones las hace más atractivas.