Otro de los puntos fuertes de la tradición Unix, y de nuevo uno que Linux lleva hasta un feliz extremo, es que muchos usuarios son a la vez 'hackers'. -- y puesto que el código fuente está disponible pueden ser 'hackers' productivos. Esto puede resultar enormemente eficaz para reducir el tiempo necesario para la depuración. Con un poco de motivación, tus usuarios diagnosticarán problemas, sugerirán correcciones, y ayudarán a mejorar el código mucho más rápidamente de lo que tú serías capaz de lograr sin ayuda.
6. Tratar a tus usuarios como colaboradores es el camino menos complicado para mejorar con rapidez y depurar eficazmente un programa.
Resulta fácil subestimar la potencia de este efecto. En realidad, muchos de los que estamos involucrados en el desarrollo de software abierto infravalorábamos drásticamente lo bien que puede aumentarse de escala sin más que recurrir a un número aún mayor de usuarios y contribuir a reducir la complejidad del sistema, hasta que Linus demostró lo contrario.
Llego a creer que el logro más brillante y trascendental de Linus no fue la construcción del núcleo de Linux en sí mismo, sino más bien la invención del modelo de desarrollo Linux. Una vez que me atreví a decir tal cosa en su presencia, se limitó a sonreir y repitió en voz baja algo que ha dicho a menudo: "Soy básicamente una persona muy perezosa a la que le gusta recibir los laureles de lo que otros han hecho". Perezoso como un zorro. O, como diría Robert Heinlein, demasiado perezoso como para equivocarse.
Mirando hacia atrás, puede verse un claro precedente de los métodos y el éxito de Linux en el desarrollo de la librería Lisp de GNU Emacs y en los archivos de código Lisp. Al contrario de lo ocurrido con el desarrollo en plan construcción de catedrales del núcleo en C de Emacs y de la mayor parte de las herramientas de la FSF (Free Software Fundation), la evolución del depósito de código en Lisp fué fluida y estuvo sumamente orientada al usuario final. Las ideas y los modos adicionales en desarrollo se escribieron a menudo tres o cuatro veces antes de alcanzar un estado final estable. Y fueron frecuentes las colaboraciones ocasionales mediante Internet, en plan Linux.
Sin ir más lejos, el desarrollo concreto de mayor éxito que yo había realizado antes de 'fetchmail' fue probablemente el modo VC de Emacs, una colaboración en la línea de Linux con otras tres personas a través de e-mail, de las cuales sólo he llegado a conocer hasta el momento a una de ellas (Richard Stallman). Se trataba de un interfase de acceso a SCCS, RCS y posteriormente CVS desde Emacs que permitía llevar a cabo operaciones de control de versiones de manera directa. El punto de partida fue un minúsculo y bastante crudo sccs.el.mode que algún otro había escrito. Y el desarrollo de VC tuvo éxito debido a que, al contrario que el mismo Emacs, los programas en Lisp de Emacs permitían llevar a cabo ciclos de lanzamiento/prueba/mejora muy rápidamente.
(Un efecto colateral inesperado de la política de la FSF de mantener legalmente el código bajo la licencia GPL consiste en que su gestión dificulta la utilización del modelo bazar, ya que creen que deben conseguir una transferencia del copyright para cada contribución que supera las veinte líneas de código con el fin de blindar el código bajo esta licencia de cualquier amenaza proveniente de las leyes de propiedad intelectual. Aquellos que recurren a licencias del tipo BSD o del consorcio MIT X no sufren este problema por cuanto no tratan de reservar unos derechos que difícilmente alguien pudiera tener interés en poner en peligro).