• Categories
• Ingeniería de software
• Software
• Informática
• Tecnología
• Informática y tecnología de la información

Citation preview

Resumen artículo: La Catedral y el Bazar Luisa María Valderrama Castaño Diego Fernando Echeverry Ingeniería de Sistemas y Computación

1094952380 1097038001 Administración de sistemas operativos GNU/Linux

En el articulo el autor Eric S. Raymond cuenta inicialmente cómo Linux y el paradigma de desarrollo de Linus Torvals lo llevan a plantear dos modelos para la creación de software, la Catedral que hace referencia al software comercial en el que se tiene un grupo selecto conformado por programadores los cuales desarrollan, identifican y corrigen errores del código fuente así como también se encargan de cualquier modificación en él, al ser un grupo tan limitado, en éste enfoque según el autor, la evolución del software es lenta y menos segura ya que no tiene la posibilidad de estar expuesto a la vista de más personas que puedan contribuir en esos aspectos. Por otro lado está el modelo Bazar el cual consiste en que todo el que quiera ver y analizar el código fuente del software, podrá hacerlo, además de modificarlo, identificar y corregir errores; en contraste con el enfoque Catedral, el Bazar al dejar expuesto el código fuente a la vista de todo el que quiera verlo entonces éste será más rápido en el proceso de corregir errores y por tanto más rápido contribuirá en la evolución del desarrollo del software El autor expresa la necesidad de un programa para manejar el correo electrónico y se dispone a desarrollarlo teniendo en cuenta como lo hizo Torvals al construir Linux, comenzando desde algo ya construido que le pueda servir como plataforma inicial. Raymond en el proceso por construir el software adecuado hizo una búsqueda para encontrar dicha plataforma que le sirviera como base y después de analizar cuál sería la indicada se decidió por popclient escrito por Carls Harris el cual heredaría posteriormente. Se enfatiza la gran importancia que tienen los usuarios en el desarrollo de software libre ya que éstos contribuirían en la mejora de los programas en un tiempo más rápido con el cual, el tiempo de depuración se reduciría, diagnosticando y sugiriendo correcciones diferente a que este proceso solo se hiciera por un grupo selecto. Se hace referencia a la ley Linus, bautizada por Reymond en la que explica que “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.” de otro modo quiere decir que entre más personas estén observando el código, los errores serán más evidentes y en consecuencia se liberará con mayor frecuencia el software para poder obtener una mayor cantidad de correcciones. Siguendo el objetivo principal del articulo propuesto por el autor en la que pone a prueba la teoría de lo que Linus Torvals había hecho bien con linux, Reymond se dispone a utilizar sistemáticamente los pasos de Linus en su proyecto los cuales fueron:  Liberar rápido y a menudo (casi nunca dejó de hacerlo en menos de diez días; durante los períodos de desarrollo intenso, una vez diaria).

  

2. Ampliar la lista de analistas de versiones beta, incorporando a todo el que lo contactara para saber sobre fetchmail. 3. Efectuaba anuncios espectaculares a esta lista de analistas cada vez que liberaba una nueva versión,estimulando a la gente a participar. 4. Escuchar a los analistas asistentes, consultándole decisiones referentes al diseño y tomándolos en cuenta cuando estos mandaban sus mejoras y la consecuente retroalimentación.

Con la utilización de estos pasos y el método Bazar, Reymond obtuvo grandes repuestas y avances al implementarlos, tanto así que llegó a la siguiente conclusión: “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.” El éxito de esto lo pudo evidenciar cuando la lista de analistas aumentó y más aún cuando después de un tiempo la lista disminuyó lo que corresponde al ciclo de vida normal de un proyecto maduro con el método Bazar. Para el autor el hecho de tener que replantear el problema en cuanto a los cambios que se debían agregar y quitar en el proyecto fueron muy beneficiosos, lo cual nos lleva a analizar si las soluciones que damos a la hora de responder a un problema son efectivamente son soluciones para ese problema y no para otro. En cuanto al desarrollo del proyecto, desprendiéndose de características que no impliquen la pérdida de efectividad en éste, es como se va mejorando la simplicidad del código y se va mejorando el desarrollo del software, Para éste punto ya popclient se había convertido en fetchmail. Con una serie de mejoras y modificaciones tales como: 1. “multidrop support” o soporte multipunto, el cual fue una gran decisión de diseño con la cual concluyó: “Toda herramienta es útil empleándose de la forma prevista, pero una verdadera y grandiosa herramienta es la que se presta a ser utilizada de la manera menos esperada”. 2. El fijar el lenguaje que determinaba correcto para su software, el autor afirma que “ es más importante para un lenguaje el ser conveniente para los humanos que ser económico en términos de recursos computacionales.” Se pudo obtener más experiencia en el método de Bazar y llegar una conclusión más cuando se trata de la exigencia de los usuarios, en cuanto a la seguridad de fetchmail, la cual consistía en cambiar el software para guardar la contraseñas encriptadas en un archivo rc y que los hackers no pudieran verlas. Dicha exigencia no produciría ninguna protección adicional ya que se podría acceder a el archivo rc, correrlo en fetchmail y obtener el decodificador necesario para obtener la contraseña, ésta exigencia no se llevó a cabo como tampoco la falsa sensación de seguridad para ciertas personas que no tienen que ver mucho con estos procesos, lo que si dejó claro fue la siguiente regla general: “Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias.” Entre otros aspectos esenciales Reymond ve como punto crítico y esencial:  la capacidad que tiene un coordinador de proyecto de software el reconocer las buenas ideas de diseño por parte de los demas, mas que originarlas él.



La habilidad y capacidad que se posee para tratar a las personas y comunicarse con ellas de forma adecuada muchas veces es tan necesaria como las habilidades técnicas ya que éstas no lo son todo cuando se trata de formar una comunidad y ahí en donde se deben tener en cuenta las relaciones sociales.

En cuanto a los desarrolladores en el articulo el autor expresa que un gran programador enfocado en un solo proyecto se está quedando atrás en comparación de uno que trabaja en un contexto abierto y evolutivo en el que la búsqueda de errores y mejoras es realizado por comunidades enteras y ésto “El esfuerzo serio de muchas voluntades convergentes” es lo que todo proyecto tipo Linux necesita. Para ir finalizando con lo expuesto es importante resaltar cuando el autor expresa que: “el futuro del software libre será cada vez más de la gente que sabe cómo jugar el juego de Linus, la gente que deja atrás la catedral y abraza el bazar. Lo cual no quiere decir que la visión y la brillantez individuales ya no importen; al contrario, creo que en la vanguardia del software libre estarán quienes comiencen con visión y brillantez individual, y luego las enriquezcan construyendo positivamente comunidades voluntarias de interés. Lo cual nos lleva a su ultima conclusión en el articulo: “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.” El talento que pueden reunir comunidades como las de Linux y Fetchmail son indispensables para el futuro del desarrollo de software libre las cuales se han acogido al mencionando método Bazar.