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

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

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.