La Catedral y el Bazar
| ||
|---|---|---|
| Información general | ||
| Título Original | The Cathedral and the Bazaar | |
| Autor | Eric S. Raymond | |
| Idioma original | Inglés | |
| Publicación | 1997 | |
| ISBN | 1-565-92724-9 | |
| Última versión | [catedral y el bazar] | |
La Catedral y el Bazar (original:The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary) Es un libro escrito por Eric S. Raymond basado en sus experiencias administrando proyectos de software libre y sus observaciones sobre la administración del kernel de linux. En él, habla de la dificultad de aplicar procesos de desarrollo clásicos a los grupos de trabajo de software libre, normalmente diseminados y con niveles de compromiso dispares. El primer ensayo se publicó en 1997 en Alemania.
El libro se publico con licencia Open Publication License en 1999
"La Catedral y el Bazar"
El libro contrapone dos modelos de desarrollo:
- El modelo Catedral , en el que se publica código en el que se desarrollan ciclos completos de desarrollo en espiral completando capturas de requisitos, especificación, codificación, testeo y despliegue. Tradicionalmente asociado a grandes empresas de Software.
- El modelo Bazar, donde el código se desarrolla usando internet como sustrato de conexión entre los desarrolladores, permitiendo la colaboración a medida y la formación de equipos en distintas localizaciones y franjas horarias o incluso en los que los participantes entran y salen con poco aviso y planificación. El autor menciona a Linus Torvalds como inventor del proceso. También menciona su experiencia trabajando en proyectos similares
También crea una norma ampliamente aceptada en el mundo del software libre conocida como la Ley de Linus: Con suficientes ojos no hay bugs ocultos. Al publicar el software y su código como un bazar éste se encuentra disponible al escrutinio público, testeo, experimentación, y en poco tiempo de uso público los bugs aparecerán. Contrapone Los modelos de desarrollo como la cascada y la espiral, donde se destinan grandes presupuestos y tiempo al testeo del software. Donde unos pocos desarrolladores no serán capaces de encontrar los mismos bugs.
Lecciones para crear buen softwaree
Raymond indica 19 lecciones para desarrollar buen software, ligados a buenas prácticas. Éstos aparecen a lo largo de toda la obra como corolario a lo que está hablando en ese momento.
- Todo buen proyecto empieza con un desarrollador al que le pica.
- Un buen desarrolador sabe qué escribir, un gran desarrollador sabe qué reescribir (y reutilizar).
- Planifica tirar una versión, lo acabarás haciendo en cualquier lugar.
- Si tienes la actitud correcta, los problemas interesantes te encontrarán.
- Cuando pierdes interés en un programa, es mejor legarlo a un sucesor competente.
- Tratar a tus usuarios como co-desarrolladores es la ruta de mínimo esfuerzo a la mejora del código y el debugging.
- Publica pronto, publica mucho y escucha a tus clientes.
- Con un gran número de beta-testers y co-desarrolladores casi cualquier problema se identificará pronto y la solución será obvia para alguien.
- Estructuras de datos inteligentes y codigo idiota funciona mejor que al revés.
- Si tratas a tus beta-testers como el recurso mas valioso responderán siendo el recurso mas valioso.
- Lo siguiente mejor a tener buenas ideas es reconocer las buenas ideas de tus usuarios, a veces lo primero.
- Comunmente las soluciones mas radicales e innovadoras vienen de darse cuenta de que tu concepción del problema era erronea (Antoine de Saint-Exupéry).
- La perfección en el diseño no viene cuando no hay mas que añadir, sino cuando no hay mas que quitar.
- Cualquier herramienta es útil en la manera que se espera de ella, pero una buena herramienta lo es de maneras que no esperarías.
- Al escribir software de acceso es doloroso alterar los flujos de datos lo menos posible y no tirar información a no ser que el receptor te obligue a ello.
- Cuando tu lenguaje no es Turing Completo el azucar sintáctico es tu amigo.
- Un sistema de seguridad es tan seguro como su secreto. Ten cuidado de pseudo-secretos.
- Para resolver un problema interesante empieza por resolver un problema que te sea interesante.
- Si un coordinador tiene un medio de comunicación tan bueno como internet y sabe como liderar sin coacción, muchas cabezas son mejores que una.
Recepción e impacto cultural
En 1998 el ensayo motivó que se liberase el código fuente de Nestcape y comenzase el proyecto Mozilla. Muchos empleados tomaron el ensayo como una validación de sus ideas. La corporación Netscape reconoció oficialmente la influencia del libro.
Fue el primer libro publicado por O'Reilly bajo la Licencia Abierta de Publicación.
Raymond no coonsidera el libro como acabado sino como en constante desarrollo. Proporciona un enlace permanente al libro completo en su página web, de forma que cualquiera puede enlazar a la última versión. De la misma manera, las traducciones van fechadas para comprobar la versión con la que se tradujeron. Ninguna se considera oficial.
Es una de las obras mas recomendadas para aprender sobre la cultura y el desarrollo del Software Libre junto con su otra obra El caldero mágico
