La Catedral y el Bazar

Cathedral-and-the-BazaarA continuación se presenta un resumen de “La Catedral y el Bazar”, escrito por Eric Raymond.

Introducción

En líneas generales Raymond analiza el surgimiento del proyecto GNU/Linux y del Movimiento de Software Libre a través de una simple metáfora, comparando la construcción de software propietario con la construcción de una catedral, y la construcción del software libre con el funcionamiento de un Bazar o Mercado. A pesar de haber sido escrita en 1997, fue publicada en el año 2001, en inglés, por la Editorial O’Reilly (ISBN 10: 0-596-00108-8). Se puede conseguir en Internet de manera libre, e inclusive se puede descargar desde la página del autor.

La Catedral y el Bazar (libro electrónico)

Contenido

bazar y catedral

El autor plantea su punto de vista acerca de la Ingeniería de Software, contraponiendo un modelo de fabricación de software comercial  (software propietario) a un modelo de fabricación de software libre, como se dijo en el párrafo anterior, comparándolos con el modelo “Catedral” y “Bazar” respectivamente. Y la idea nace de su experiencia durante el desarrollo del proyecto “Fetch Mail”.

La Catedral y el Bazar

El autor señala su experiencia en el desarrollo de software libre, desde los inicios de la creación del movimiento, habiéndose iniciado, como muchos de sus miembros, en plataforma UNIX. De hecho, cuando se libera el Sistema Operativo Linux,  se empiezan a romper los modelos y paradigmas que se habían establecido en la comunidad desde los inicios.

Y es que el modelo que se venía aplicando en el Movimiento del Software Libre no podía ser otro sino el mismo aplicado en el mundo del Software Comercial: con un enfoque planificado, centralizado, con rigurosos cronogramas de trabajo, y hechos por “genios” encerrados en su cónclave hasta que terminaran la versión final. Y eso lo compara Raymond con un modelo de “Catedral”.  Claro, para poder construir una Catedral, o cualquier edificio monumental, se requiere de ese modelo.

Al contrario, la comunidad Linux llegó con otro modelo de desarrollo, más informal, pero sin caer en la ineficacia. Era un pensamiento común en la comunidad de Linux naciente  “libere rápido y a menudo, delegue todo lo que pueda, sea abierto hasta el punto de la promiscuidad”. Y se vieron los frutos rápidamente. Al igual que en un Bazar, o Mercado, todos los vendedores se reúnen, aparentemente sin orden ni jefe, a vender los productos que requieren sus clientes. Y éste consigue tal variedad y una gama de precios, que le incita a regresar a comprar al Bazar, donde conseguirá todo lo que busca a precios razonables.

Pero para poder comprobar ese modelo de “Bazar”, Raymond inicia un proyecto, denominado “FetchMail”.

El Correo tenía que llegar

Estando encargado Raymond de un ISP en West Chester, Pennsylvania, llamado “Chester County Interlink” (CCIL), requirió de un POP3 para manejar de manera más eficiente su correo.

Y señala que muchas veces es preferible modificar código ya existente, que empezar a escribir desde cero.  Tal cual como Linus Torvalds hizo reescribiendo Minix para poder generar Linux.

Pues en vez de crear un POP3, buscó en la red uno que pudiese servirle para sus necesidades, aprovechando uno de los preceptos de la Comunidad de Software Libre, de compartir código, para luego reutilizarlo. De los nueve candidatos, al final seleccionó el “PopClient” de Carl Harris. Como encontró varias “oportunidades de mejora”, le escribió a Harris para discutirlo, y se encontró con que Harris ya había perdido interés en la aplicación. Vista la circunstancia, tomó Raymond las riendas del mantenimiento de la aplicación.

La Importancia de contar con usuarios

Cuando Raymond asume el compromiso de liderar el proyecto “PopClient”, Harris le “hereda” su base de usuarios, muchos de los cuales eran programadores, y pudieron, de manera sinérgica, colaborar en el desarrollo de una aplicación más eficiente y robusta. Copió el modelo de desarrollo colaborativo usado por Linus Torvalds, para poder desarrollar su proyecto.

Libere rápido y a menudo

Si se toma en cuenta que  los usuarios quieren ver el menor número de errores posibles en las aplicaciones, se reafirma la tesis de emplear el modelo “catedral”, y así liberar los productos al menos cada seis (6) meses para ofrecer estabilidad y robustez.

Pero la política desarrollada por la comunidad de Linux probó lo contrario.

Con desarrolladores motivados trabajando a diario, se lograron actualizaciones casi diarias de las aplicaciones y se resolvieron problemas y “bugs” en corto tiempo, sin necesidad de esperar los seis (6) meses para liberar versiones finales probadas y robustas.

En el modelo “Catedral” los errores se atacan y se resuelven para cuando se libere la siguiente versión.

En el modelo “Bazar” los errores se atacan y se resuelven de una vez. Y a pesar que se podría pensar que ello traería duplicación de trabajo, en la realidad se vió que no fue así.

Una mayor cantidad de usuarios-programadores hace que los errores sean detectados de manera más rápida y que sean corregidos de igual manera. Y ello debido al efecto sinérgico, donde cada quien desde su punto de vista puede aportar soluciones a los problemas encontrados.

¿Cuando una rosa no es una rosa?

Tomando en cuenta lo señalado, Raymond procede a reorganizar el proyecto de Harris, y a reestructurar sus componentes.

Para poder comprobar la eficacia del modelo desarrollado por Linus Torvalds, Raymond emprendió las siguientes acciones:

  1. Liberaba 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. Ampliaba mi lista de analistas de versiones beta, incorporando a todo el que me contactara para saber sobre fetchmail.
  3. Efectuaba anuncios espectaculares a esta lista cada vez que liberaba una nueva versión, estimulando a la gente a participar.
  4. Y escuchaba a mis analistas asistentes, consultándolos decisiones referentes al diseño y tomándolos en cuenta cuando me mandaban sus mejoras y la consecuente retroalimentación

De inmediato, el proyecto empezó a funcionar de la manera esperada. El número de usuarios programadores aumentaba cada día, y la aplicación alcanzó niveles de operación bajo altos estándares.

PopClient se convierte en FetchMail

fetch-mail

Gracias a los aportes de la comunidad de usuarios programadores, la aplicación fue evolucionando cada día más.

Una enseñanza importante, y que cito textualmente es la siguiente:

Cuando usted se topa con un muro durante el desarrollo −cuando la encuentra difícil como para pensar mas allá de la corrección que sigue− es, a menudo, la hora de preguntarse no si usted realmente tiene la respuesta correcta, sino si se está planteando la pregunta correcta. Quizás el problema requiere ser replanteado. (Raymond, 1997. Página 11).

 Y una vez que la nueva aplicación empezó a tomar forma propia, Raymond oficializa el cambio de nombre de “Popclient” a “FetchMail”.

El crecimiento de Fetchmail

Ahora que el Fetchmail hacía todo lo que Raymond quería que hiciera, podían averiguar cuáles eran otros requerimientos de los usuarios. Y más allá de satisfacer sus propias necesidades, Raymond se vio empujado a satisfacer las necesidades de esos usuarios, y ampliar los canales de soporte para la aplicación.

Algunas lecciones más extraídas de FetchMail

Es preferible usar lenguajes restrictivos para el control de la aplicación. Usar un mínimo de comandos para evitar confusiones y ofrecer simplicidad.

La seguridad no se debe establecer en el código abierto, ya que puede ser rápidamente vulnerada.

Condiciones necesarias para el estilo “Bazar”

  • No se puede comenzar un proyecto desde cero. Para poder aplicar este modelo, ya debe existir un prototipo, versión o aplicación sobre la cual se vaya a trabajar.
  • Se deben hacer promesas plausibles. Se debe motivar a los desarrolladores para que puedan generar productos excelentes. Pero como todo comienzo es duro, se debe hacer énfasis en que los resultados no se verán a corto plazo o de manera inmediata. Pero  se verán.
  • Linux y Fetchmail son dos aplicaciones realizadas bajo el modelo “Bazar”, y son prueba fehaciente de que el modelo funciona.
  • El coordinador no debe ser egoísta, y más bien debe ser visionario, y saber reconocer las buenas ideas de sus colaboradores.
  • De igual manera. El coordinador debe tener “Don de Gente” y tener buena comunicación, para tener altas probabilidades de éxito en el proyecto.
  • La labor del coordinador no es programar. Es hacer que se produzca la sinergia entre los miembros del equipo.

El Contexto Social del Software Libre

Tanto el proyecto de Linux como de Fetchmail, han demostrado que con el estímulo apropiado al ego de los usuarios programadores, y con herramientas basadas en Internet, los proyectos colaborativos son exitosos y eficientes.

Uno de los beneficios precisamente de los que participaron es ambos proyectos, fue la satisfacción del ego, y el tener un aumento en la “reputación” de sus miembros.

El futuro del Software Libre será de aquellos que dejen atrás el modelo “Catedral” y abracen el modelo “Bazar”.

Lecciones de Raymond

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)

Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).

Contemple desecharlo; de todos modos tendrá que hacerlo.

Si tienes la actitud adecuada, encontrarás problemas interesantes.

Cuando se pierde el interés en un programa, el último deber es heredarlo a un sucesor competente.

Tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más efectiva de depurarlo.

Libere rápido y a menudo, y escuche a sus clientes.

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.

Las estructuras de datos inteligentes y el código burdo funcionan mucho mejor que en el caso inverso.

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.

Lo más grande, después de tener buenas ideas, es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor

Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea

La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar

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.

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!

Cuando su lenguaje está lejos de un Turing completo, entonces el azúcar sintáctico puede ser su amigo.

Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias

Replanteo de la primera enseñanza:  Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante

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

Conclusiones

En pocas palabras, se puede concluir que el objetivo planteado al inicio fue cumplido sin otro contratiempo, que (valga el juego de palabras) el encontrar tiempo para su cumplimiento.

El modelo de “Catedral” lo aplica Raymond al desarrollo de software comercial, donde hay directrices definidas, tiempos establecidos, jerarquías, y muchas reglas.

El modelo de “Bazar” lo aplica Raymond al desarrollo en Software Libre, donde se construye un ambiente colaborativo y sinérgico, que busca cumplir los objetivos en corto plazo y con menor esfuerzo.

Al menos existe un par de proyectos exitosos (aunque me imagino que hay muchos más) como el Linux de Torvalds y el Fetchmail de Raymond, que así confirman que el modelo “Bazar” es eficiente, y que produce resultados.

Acerca de Eric Raymond

eric raymondEric Steven Raymond nació en Boston, Massachusetts en 1957, y es el autor del ensayo “La Catedral y el Bazar”, y es una figura importante del Movimiento del Código Abierto (Open Source).  En la película reconoce haber sido uno de los que contribuyeron a liberar el código fuente del browser Netscape Navigator, el cual luego devino en el proyecto Mozilla. Entre sus obras, adicional a la ya mencionada, están: Una breve historia de los Hackers, Colonizando la Noosfera, el Caldero Mágico, la Venganza de los Hackers y el Arte de Programar en Linux.

Fuente: Blog personal de Eric Raymond

Elaborado 2011. Revisado 2015.

licencia

Banner De todo un Poco (1) con URL

 

Acerca de Luis Castellanos

Luego de unos años en Maracaibo, de regreso en Caracas. Docente Universitario y Bloguero. Orgulloso padre de dos hijos. luiscastellanos @ yahoo.com | @lrcastellanos

Publicado el enero 31, 2007 en Software Libre y etiquetado en , , , , . Guarda el enlace permanente. 2 comentarios.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: