For faster navigation, this Iframe is preloading the Wikiwand page for La catedral y el bazar.

La catedral y el bazar

La catedral y el bazar
de Eric S. Raymond
Género No ficción Ver y modificar los datos en Wikidata
Subgénero Ensayo Ver y modificar los datos en Wikidata
Tema(s) software libre
Edición original en inglés Ver y modificar los datos en Wikidata
Título original The Cathedral & the Bazaar
Editorial O'Reilly Media Ver y modificar los datos en Wikidata
País Estados Unidos Ver y modificar los datos en Wikidata
Fecha de publicación
  • 1997
  • 1999 Ver y modificar los datos en Wikidata
Páginas 241 Ver y modificar los datos en Wikidata
Edición traducida al español
Traducido por José Soto Pérez
Fecha de publicación 1997
Serie
Una breve historia de los hackers
La catedral y el bazar

La catedral y el bazar es un ensayo sobre el software de código abierto escrito por el hacktivista Eric S. Raymond en 1997. Ha tenido dos secuelas tituladas Colonizando la noosfera y El caldero mágico.

Temática

El ensayo analiza dos modelos de producción de software bien diferenciados. Por un lado, la catedral, que representa el modelo de desarrollo más hermético y vertical característico del Software propietario; y por el otro el bazar, con su dinámica horizontal y "bulliciosa", que caracterizó al desarrollo del kernel Linux y otros proyectos de software libre que se potenciaron con el trabajo comunitario a través de Internet del código abierto.

Publicación

El texto está incluido en el libro The Cathedral & the Bazaar publicado por O'Reilly en 2001.[1]

Dicha editorial mantiene en exclusividad los derechos de explotación comercial del libro en versión impresa. Sin embargo, se puede descargar gratuitamente en versión electrónica desde la web del autor (incluye traducciones a varios idiomas, entre ellos español)[2]

Lecciones enumeradas en La catedral y el bazar

El libro recopila una serie de lecciones aprendidas a partir de la experiencia que el autor comparte en el texto, en concreto:

  1. Todo buen trabajo de software comienza a partir de las necesidades personales del programador (todo buen trabajo empieza cuando uno tiene que rascarse su propia comezón).
  2. Los buenos programadores saben qué escribir. Los mejores, qué reescribir (y reutilizar).
  3. "Considere desecharlo; de todos modos tendrá que hacerlo." (Fred Brooks, The Mythical Man-Month, Capítulo 11)
  4. Si tienes la actitud adecuada, problemas interesantes te encontrarán.
  5. Cuando pierdes el interés en un programa, debes darlo en herencia a un sucesor competente.
  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.
  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. O, dicho de manera menos formal, "con muchas miradas, todos los errores saltarán a la vista". A esto lo he bautizado como la Ley de Linus.
  9. Las estructuras de datos inteligentes y el código burdo funcionan mucho mejor que en 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.
  11. Lo mejor después de tener buenas ideas es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor.
  12. Con frecuencia, 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 nada que quitar."
  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. Cuándo se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precaución de alterar el flujo de datos lo menos posible, y ¡*nunca* eliminar información a menos que los receptores obliguen a hacerlo!
  16. Cuando su lenguaje está lejos de un Turing completo, entonces el azúcar sintáctico puede ser su amigo.
  17. Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias.
  18. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.
  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.

Véase también

  • En el número 190 de la revista Novática (que está bajo licencia libre) se encuentra un estudio de Andrea Capiluppi y Martin Michlmayr (traducido al español) sobre los ciclos de vida de los proyectos basados en comunidades de voluntarios, en el que se hace una comparación del éxito de proyectos desarrollados con el modelo "catedral" y "bazar"[3]

Referencias

  1. The Cathedral & the Bazaar
  2. La catedral y el bazaar en la web personal de Eric S. Raymond
  3. Novática número 190
{{bottomLinkPreText}} {{bottomLinkText}}
La catedral y el bazar
Listen to this article

This browser is not supported by Wikiwand :(
Wikiwand requires a browser with modern capabilities in order to provide you with the best reading experience.
Please download and use one of the following browsers:

This article was just edited, click to reload
This article has been deleted on Wikipedia (Why?)

Back to homepage

Please click Add in the dialog above
Please click Allow in the top-left corner,
then click Install Now in the dialog
Please click Open in the download dialog,
then click Install
Please click the "Downloads" icon in the Safari toolbar, open the first download in the list,
then click Install
{{::$root.activation.text}}

Install Wikiwand

Install on Chrome Install on Firefox
Don't forget to rate us

Tell your friends about Wikiwand!

Gmail Facebook Twitter Link

Enjoying Wikiwand?

Tell your friends and spread the love:
Share on Gmail Share on Facebook Share on Twitter Share on Buffer

Our magic isn't perfect

You can help our automatic cover photo selection by reporting an unsuitable photo.

This photo is visually disturbing This photo is not a good choice

Thank you for helping!


Your input will affect cover photo selection, along with input from other users.

X

Get ready for Wikiwand 2.0 🎉! the new version arrives on September 1st! Don't want to wait?