Hola comunidad, ayer encontré en la Web este libro y me lo he comenzado a
leer y me parece muy interesante para esta comunidad, más abajo les pongo el
resumen del libro así como el índice de contenido para que se motiven.
Si alguien quiere que se lo haga llegar me lo dicen por pv.
La catedral y el bazar
Eric S. Raymond
Traducción: José Soto Pérez
js...@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
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
