PDF de programación - La Catedral y el Bazar

La catedral y el bazar

Eric S. Raymond

Traducción: José Soto Pérez
[email protected]

FCFM-BUAP

Copyright
Se permite copiar, distribuir y/o modificar este documento, bajo los términos de la Open Publication License,
versión 2.0.
Resumen

Analizo un exitoso proyecto de software libre (fetchmail), que fue realizado deliberadamente para
probar algunas sorprendentes ideas sobre la ingeniería de software sugeridas por la historia de
Linux. Discuto estas teorías en términos de dos estilos de desarrollo fundamentalmente opuestos: el
modelo catedral de la mayoría de los fabricantes de software comercial, contra el modelo bazar del
mundo Linux. Demuestro que estos modelos parten de puntos de vista contrapuestos acerca de la
naturaleza de la tarea de depuración del software. Posteriormente, hago una argumentación, a partir
de la experiencia de Linux, de la siguiente sentencia: “si se tienen las miradas suficientes, todas las
pulgas saltarán a la vista”. Al final, sugiero algunas fructíferas analogías con otros sistemas
autorregulados de agentes egoístas, y concluyo con una somera exploración de las implicaciones que
pude tener este enfoque en el futuro del software.

Índice de contenido
La catedral y el bazar ...........................................................................................................................................
El correo tenía que llegar .....................................................................................................................................
1. Todo buen trabajo de software comienza a partir de las necesidades personales del programador.
(cuando uno tiene que rascarse su propia comezón) ..........................................................................................
2. Los buenos programadores saben qué escribir. Los mejores, qué reescribir (y qué reutilizar). .....................
3. “Contemple la posibilidad de desecharlo, de todos modos tendrá que hacerlo.” (Fred Brooks, The
Mythical Man-Month, Capítulo 11) .......................................................................................................................
4. Si tienes la actitud adecuada, encontrarás problemas interesantes................................................................
5. Cuando se pierde el interés en un programa, el último deber es cederlo a un sucesor competente..............

La importancia de contar con usuarios.................................................................................................................
6. Tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más
efectiva de depurarlo............................................................................................................................................

Libere rápido y a menudo.....................................................................................................................................

7. Libere rápido y a menudo, y escuche a sus clientes. ......................................................................................
8. 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..................................................

¿Cuándo una rosa no es una rosa?.....................................................................................................................

9. Estructuras de datos inteligentes y código burdo funcionan mucho mejor que el caso inverso......................
10. Si usted trata a sus analistas (beta-testers) como si fueran su recurso más valioso, ellos le
responderán convirtiéndose en su recurso más valioso. .....................................................................................

Popclient se convierte en Fetchmail.....................................................................................................................
11. Lo más grande, después de tener buenas ideas, es reconocer las buenas ideas de sus usuarios.
Esto último es a veces lo mejor............................................................................................................................
12. Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la
concepción del problema era errónea..................................................................................................................
13. “La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay
algo que quitar.”....................................................................................................................................................

El crecimiento de Fetchmail .................................................................................................................................
14 Toda herramienta es útil empleándose de la forma prevista, pero una *gran* herramienta es la que se
presta a ser utilizada de la manera menos esperada. .........................................................................................
15. Cuando se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la
precaución de alterar lo menos posible el flujo de datos, y ¡*nunca* eliminar información a menos que los



receptores obliguen a hacerlo! .........................................................................................................................14

Más lecciones extraídas de Fetchmail .............................................................................................................14
16. Cuando su lenguaje está lejos de un Turing completo, entonces el azúcar sintáctico puede ser su
amigo................................................................................................................................................................15
17. Un sistema de seguridad es tan seguro como secreto. Pero cuídese de los secretos a medias..............15

Condiciones necesarias para el Estilo del Bazar .............................................................................................15
El contexto social del software libre .................................................................................................................16
18. Para resolver un problema interesante, comience por encontrar un problema que le resulte
interesante........................................................................................................................................................17
19. Si el coordinador de desarrollo tiene un medio al menos tan bueno como lo es internet, y sabe dirigir
sin coerción, muchas cabezas serán, inevitablemente, mejor que una...........................................................19

Reconocimientos ..............................................................................................................................................19
Otras lecturas ...................................................................................................................................................19
Epílogo: ¡Netscape adopta el bazar! ................................................................................................................20
Versión y actualizaciones: ................................................................................................................................21
La catedral y el bazar
Linux es subversivo. ¿Quién hubiera pensado hace apenas cinco años que un sistema operativo de talla
mundial surgiría, como por arte de magia, gracias a la actividad hacker desplegada en ratos libres por varios
miles de programadores diseminados en todo el planeta, conectados solamente por los tenues hilos de la
internet?
Lo que sí es seguro es que yo no. Cuando Linux apareció en mi camino, a principios de 1993, yo tenía
invertidos en UNIX y el desarrollo del software libre alrededor de diez años. Fui uno de los primeros en
contribuir con GNU a mediados de los 80 y he estado aportando una buena cantidad de software libre a la
red, desarrollando o colaborando en varios programas (NetHack, los modos VC y GUD de Emacs, xlife y
otros) que todavía son ampliamente usados. Creí que sabía cómo debían hacerse las cosas.
Linux vino a trastocar buena parte de lo que pensaba que sabía. Había estado predicando durante años el
evangelio UNIX de las herramientas pequeñas, de la creación rápida de prototipos y de la programación
evolutiva. Pero también creía que existía una determinada complejidad crítica, por encima de la cual se
requería un enfoque más planeado y centralizado. Yo pensaba que el software de mayor envergadura
(sistemas operativos y herramientas realmente grandes, tales como Emacs) requería construirse como las
catedrales, es decir, que debía ser cuidadosamente elaborado por genios o pequeñas bandas de magos
trabajando encerrados a piedra y lodo, sin liberar versiones beta antes de tiempo.
El estilo de desarrollo de Linus Torvalds (“libere rápido y a menudo, delegue todo lo que pueda, sea abierto
hasta el punto de la promiscuidad”) me cayó de sorpresa. No se trataba de ninguna forma reverente de
construir la catedral. Al contrario, la comunidad Linux se asemejaba más a un bullicioso bazar de Babel,
colmado de individuos con propósitos y enfoques dispares (fielmente representados por los repositorios de
archivos de Linux, que pueden aceptar aportaciones de quien sea), de donde surgiría un sistema estable y
coherente únicamente a partir de una serie de artilugios.
El hecho de que este estilo de ba