sábado, 13 de junio de 2009

La catedral y el Bazar -- By Cesar ---

GURUS GURUS GURUS GURUS GURUS GURUS JAJAJAJAJAJAJAJAJAJAJAJAJA


La catedral y el bazar es un ensayo que escrito por el hacker Eric S. Raymond en 1997 a favor del software libre, en este ensayo comenta como fue y vivió el surgimiento GNU/LINUX y de software libre, este ultimo se creo con el fin de comprobar las diferencias teóricas entre los dos modelos de desarrollo, la catedral (Windows) que es la mayoría de software que no es libre y el bazar (LINUX) el código abierto.

El ensayo comienza describiendo la ironía de Linux. Ya que quién hubiera pensado que un sistema operativo de gran calidad pudiera concretarse partir del trabajo aficionado de varios miles de programadores esparcidos por todo el planeta y conectados tan solo utilizando internet y a tiempo parcial.

Eric S. Raymond fue uno de los que primero contribuyó al desarrollo de GNU a mediados de los ochenta, desde 1993 ya había estado ya involucrado en el desarrollo de Unix y de software abierto durante diez años, Raymond lanzó en la red una cantidad respetable de software abierto, desarrollando o co-desarrollando varios programas nethack, los modos VC y GUD de Emacs, xlife que hoy en día algunos de estos se siguen utilizando. Eric S. Raymond menciona que con la llegada de Linux derrumba todas las ideas que tenia de cómo realizar un software ya que creía que el software, los sistemas operativos o las herramientas realmente grandes necesitaban ser construidas al modo de las catedrales, ser cuidadosamente ensamblados por programadores o hackers trabajando en un espléndido aislamiento, además de que no hubiera lugar al lanzamiento de las versiones de prueba antes de que llegara el momento de sacarlas al mercado.

En el ensayo elogia a Linus Torvalds por el estilo de desarrollo que utilizo, ya que lanzó versiones de prueba enseguida y a menudo y trato de delegar lo mas rápido posible, además, trato de mantener el código lo mas abierto posible, admitió contribuciones de cualquiera. Hacer eso le dio auge y dinamismo a la consolidación de LINUX que no tenia nada que ver con la construcción de una catedral como lo es Windows, y lo mejor de todo esto es que fue posible que emergiera un sistema coherente y estable mediante una sucesión de milagros.

Eric S. Raymond narra como este estilo bazar podría funcionar, y funcionar bien, ya que mientras Eric trataba de entender y aprender como este sistema no solo no se desmoronaba en medio de su gran confusión, sino, era en caso contrario ya que parecía ir de logro en logro a una velocidad difícil de imaginar para los constructores de catedrales. A mediados de 1996 menciona que la casualidad le proporciono una forma perfecta de probar su proyecto de software abierto que condujo de la forma de un bazar y funciono de una forma perfecta; en pocas palabras este es el resumen de la catedral y el bazar.

Lecciones enumeradas en La Catedral y el Bazar de Eric S. Raymond

  1. Todos los trabajos buenos en software comienzan tratando de paliar un problema personal del que los programa.
  1. Los buenos programadores saben qué escribir. Los mejores, qué reescribir (y reutilizar).
  1. Piensa en desechar al menos uno: lo terminarás haciendo de todos modos.
  1. Si tienes la actitud adecuada, los problemas interesantes te encontrarán.
  1. Cuando un programa deja de interesarte, tu último deber es pasarlo a un sucesor competente.
  1. Tratar a tus usuarios como colaboradores es el camino menos complicado para mejorar con rapidez y depurar eficazmente un programa.
  1. Lánzalo pronto. Lánzalo a menudo. Y escucha a tus usuarios.
  1. Dada una base lo suficientemente amplia de probadores y colaboradores, casi todos los problemas se identificarán con rapidez y su solución será obvia para alguien.
  1. Estructuras de datos inteligentes asociadas a un código torpe funcionan mucho mejor que la alternativa opuesta.
  1. Si tratas a la gente que te ayuda a depurar un programa como si fueran tu recurso más valioso, responderán convirtiéndose en eso precisamente.
  1. La siguiente cosa mejor que tener buenas ideas consiste en reconocer las buenas ideas de tus usuarios. Y en ocasiones ésta última es la mejor en términos absolutos.
  1. A menudo, las soluciones más sorprendentes e innovadoras surgen al darte cuenta de que la idea que se tenía del problema estaba equivocada.
  1. La perfección (de un diseño) no se consigue cuando no queda nada por añadir, sino más bien cuando no resta nada por eliminar.
  1. Toda herramienta debe resultar útil en la forma prevista, pero una gran herramienta te lleva a usarla para realizar cosas jamás pensadas.
  1. Cuando escribas programas que actúen como pasarelas de datos (gateway software), ten cuidado de modificarlos lo menos posible; y nunca elimines información a menos que su destinatario te fuerce a hacerlo.
  1. Si el lenguaje de tu programa no es Turing-completo ni por asomo, puede venir bien endulzar su sintaxis.
  2. Un sistema es sólo tan seguro como su secreto. Cuidado con los falsos secretos.
  1. Para resolver un problema interesante, comienza por encontrar uno que lo sea para tí.
  1. Si el coordinador de un proyecto tiene a su disposición un medio de comunicación al menos tan potente como Internet, y sabe cómo conducir a la gente sin coaccionarla, muchas cabezas son inevitablemente mejor que una.


No hay comentarios:

Publicar un comentario