mod01 catedralybazar

La catedral y el bazar
Eric S. Raymond
Traducción: José Soto Pérez
jsoto@labpar.fcfm.buap.mx
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 desoftware 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 decontenido
La catedral y el bazar ...........................................................................................................................................
El correo tenía que llegar .....................................................................................................................................
1. Todo buen trabajo de software comienza a partir de las necesidadespersonales 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
MythicalMan-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 decontar 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 puedeser 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. Siusted 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...