La Catedral y el Bazar, un ensayo a favor del software de código abierto que no deberías dejar de leer

Saludos a los lectores del Portal GUTL. Muchos de nosotros llevamos cierto tiempo usando e incluso promoviendo el uso de herramientas informáticas Libres y/o de Código Abierto pero no todos analizamos en profundidad la importancia que tiene este tipo de Software en cuanto al desarrollo social actual. Algunos de nosotros en ocasiones parecemos verdaderos gurúes que recitan de memoria cuantas líneas de comando existen pero en la práctica, pocos vamos a la raíz del asunto, a la esencia del Software de Código Abierto. Por suerte para nosotros y para todo el ecosistema FLOSS, han existido importantes personajes que si se han tomado el trabajo de analizar en detalle ciertos aspectos que nosotros solemos pasar por alto. Eric S. Raymond es uno de esos hackers pensadores que desde hace varias décadas se ha dedicado a escribir varios ensayos al respecto que incluyen entre otros un peculiar quinteto formado por los títulos: Una breve historia de los hackers; La catedral y el bazar; Colonizando la noosfera, El caldero mágico y La venganza de los hackers. Del segundo y tal vez más conocido de los cinco estaremos hablando hoy en GUTL.

La catedral y el bazar es un ensayo a favor del software de código abierto escrito por el hacker Eric S. Raymond en 1997. El escrito analiza dos modelos de producción de Software Libre: la catedral representa el modelo de desarrollo mas hermético y vertical característico del inicio del Proyecto GNU, Emacs y por otro lado 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.

Este ensayo recopila una serie de lecciones 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, encontrarás problemas interesantes.
  5. Cuando se pierde el interés en un programa, el último deber es 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.

Más allá de que muchos proyectos de código abierto se centren en uno u otro modelo de desarrollo (Catedral o Bazar), creo que es una lectura obligada para todos aquellos que nos identificamos con las Tecnologías Libres. A los interesados les dejamos el libro en formato PDF:

Haz clic sobre la imagen para descargar La Catedral y el Bazar

Haz clic sobre la imagen para descargar La Catedral y el Bazar

¿Te resultó interesante? Compártelo ...



Maikel Llamaret Heredia

Publicado por Maikel Llamaret Heredia

https://swlx.info » Facebook » Twitter » Google+ » Linkedin » Forma parte de GUTL desde el 6 diciembre, 2011. Parte de la familia GUTL. Usuario de Tecnologías Libres desde hace varios años. Fiel a GNU/Linux y las filosofías del Software Libre y el Código Abierto. Linux User # 587451. Creador y actual mantenedor del Proyecto SWL-X. Freelancer dedicado al Desarrollo / Diseño Web y Marketing Online. Creador de Web & Media Integrated Solutions

Este artículo tiene 2 comentarios

Los comentarios están cerrados.